Git Tutorial – Part 1: Simple git commands explained with example workflow.

Git is a well-known source code versioning system widely used by software organizations. But many of the developers who have not yet worked with a team could be unaware of how this works and what is the relevance.

I was given the task of explaining git basics to newbies for getting them onboarded. It was created as a sample use case in a presentation. I have included the same below as google slides link. You could go through it and get a basic understanding with some examples of a use case in a small team. The commands used are explained in the below section with details.

You can also view the video version of the same in youtube

Commands used in the slide

The following are the basic commands used in the slides. We will see the structure and what they are used for in the use cases.

git clone

This is the first command used for starting up with a git repository. Your team leads or the organization IT will provide you access to the repository using a user name/password. Now to bring the code repository to your local, you will use the command as :

git clone <repository url>

This will bring all the source code changes and will set your local repository position to the master branch ( This is usually the production / stable branch containing the tested and production code ).

git branch

Each developer is required to create a branch ( called feature branch ) before you start with the changes to the code. A branch refers to a snapshot of the current repository where your changes are tracked separately. So any change you make in your branch does not affect the main branch and will be made part of main branch only after it is reviewed by some lead developer or by automated CI/CD systems.

git branch <feature or branch name>

Local git will create a new branch with all the changes from the parent branch ( if you were at master branch, your new branch will contain the master changes). Please note that this will only create the branch. You are still in the master branch and need to execute the command below to move to the new branch.

git checkout

To move to a branch you created, we need to use the checkout command. Following is the construct for the command.

git checkout <feature or branch name>

This will allow you to move to the branch name specified. The specified branch name should be existing in your local. You can also combine the creation of the branch and moving to it using below command:

git branch -b <feature or branch name>

This will create the branch and also check out to the new branch so that you can start working on the changes.

git commands for adding, committing and pushing changes

Once you are on your feature branch, you can start making your changes and these will be only visible and affecting the files on your current branch. The original branch from which you checked out ( eg: master ) will be clear of your changes.

Once you are done with the changes to the files, you need to tell git for adding the files for committing. A commit will record the changes you did for the file and track them w.r.t the remote repo.

git add

You can add individual files to be marked for committing using the following command

git add <filepath>

This will mark the file specified by the <filepath> for commit. If you are on the local repository root level, the path can be relative. If you are outside the repo folder, specify the absolute path. You may also specify the folder or package path to add all the files under that for commit.

If you have many files changed and all of them are to be marked for commit, then you could do so by using the below command.

git add -u

This will mark all the changed files ( that were already in the repository ) for commit. NOTE: If you have added any new files, it will be untracked and you need to add it using git add <filepath>

git commit

Once the changed files are marked for commit, we can commit the changes. This will create a snapshot of your changes that can be made part of the main repository by merging. We will use the below command for commit.

git commit -m "message"

Every commit needs a message and you can specify it using -m flag. If you have more details to specify, you can just execute “git commit” and it will open your default text editor for editing. Once you save and close the editor, the changes will be committed.

git push

The changes that you have done and committed are currently in your local only. For this to be visible to someone else from the team, we need to push it to the remote repository ( from where it was cloned ). We will use the below command for pushing your branch to the remote ( organization ) repository.

git push origin <feature or branch name>

Here, origin refers to the repository from where you cloned the changes. By default, git will record this in its local configuration file when you clone a repository.

The above command will create your <feature or branch name> on the repository with the changes you made. At this point, anyone with access to the repository can view the changes by going to your branch.

git fetch

if you want to bring all the new branches that were created in the remote repository after your initial clone, you can use the following command.

git fetch

This will fetch all the newly created branches in the remote and you can move to a remote repository from local using git checkout <branchname>. You can use this anytime you want to get the new branches since the last git fetch.

git merge

This command is used to merge the changes from a different branch to the current branch. For eg: A lead will do git fetch to get your pushed branch/feature. After he/she reviews the changes, they can merge it to the master branch to make them part of the main repository branch or prepare for production. If you want to merge your feature1 branch to master, you will issue the following commands.

# Move to the master branch
git checkout master

#Merge the feature1 branch
git merge feature1

This is where the git magic works and it will try to identify the changes line by line from feature1 and patch it to the master branch. Once the merge is successful, there will be a new commit created on the master branch with changes from the feature1 branch.

If there are changes that it can’t auto-merge ( like files or sections where there are conflicting changes ), then it will report those files and will need to be fixed manually and created as a commit.

Footnotes

We have only seen the basic commands of Git. But the above ones are the most commonly used day-to-day commands and will equip you to handle the first days of being in a team that uses Git for version control.

I will be extending this to a new post which will cover the advanced workflows like the creation of pull requests and merging.