The world’s leading publication for data science, AI, and ML professionals.

An easy way to understand GIT

Intermediate git commands and their meanings explained

I have been using GIT for versioning my work repositories as many programmers and I wanted to make a review for the most used commands and their logic to have a deeper understanding. Here is a collection that I have made after some online tutorials and classes that I would like to share with you!

  1. Create a new branch
  • Git branch new_branch_name git checkout new_branch_name (or git switch new_branch_name) or
  • git checkout -b new_branch_name or
  • git switch -c new_branch_name
  1. Create a new branch with an old commit to continue working from there
git log  (to check the commit id)
git checkout id (to pass related commit)
git checkout -b new_branch_name commit_id (create a new branch with that commit) 
  1. Stage mechanism

You have files that you staged already (that are in your track zone), and you have some changes in these files that you didn’t stage and you wanna delete.

  • git restore filename or
  • git checkout filename to delete the changes in a specific file

and

  • git restore . or
  • git checkout . to delete all the changes in this situation.

You have files that you didn’t stage, and you want to go back from these changes where you added the files

  • git clean -dn (to check which files you are going to delete) git clean -df (to delete these files)

You want to unstage some files that you have already staged, to tell git not to track them

  • git restore --staged filename or git reset filename

Check which files are in your staged area

  • git ls-files
  1. Delete commits
  • git reset HEAD~n or git reset --SOFT HEAD~nto go back n commit back (to delete n commits), by having changes not deleted

  • git reset --HARD HEAD~n to delete n commits by deleting the changes from your work repository also.
  1. Stash Mechanism

You have some changes that you staged, but didn’t commit since it’s not ready to commit. You wanna change your branch but you don’t want that these staged changes come into the branch you just passed to. You have to stash these changes to save them in the internal memory to not lose them, to not carry them to the other branch, and to be able to keep them back when you want.

  • git stash to save them in memory and make them disappear for now
  • git stash apply to take the changes back
  • git stash apply n to take only the changes with id n in stash memory
  • git stash pop to take the changes back and delete them from the stash memory (also n parameter is applicable like in apply)
  • git stash list to see what you have in your stash area
  • git stash clear to delete all your stash memory
  • git stash drop n to delete the stash with id n (you can check the ids with the "git stash list" command as mentioned!!)
  1. Bring lost data

You want to bring back a deleted commit or branch:

  • git reflog to see all the events made in the last 30 days with their hash ids. So in comparison with the git log command, here we don’t see only the commit history but every step we made like switching branches, staging, stashing, deleting a commit or a branch, etc.
  • git reset --hard hash_id to bring back a deleted commit
  • git checkout hash_id git checkout -b new_branch_name to bring back a deleted branch
  1. Merge Types

There are two main types of merge operations: Fast-forward and Non-Fast-Forward with 1 and 4 different ways to apply them. **** In this tutorial, I will only mention the fast-forward merge and the recursive one for the non-fast-forward category.

Fast forward: After you created a new branch for your new features (let’s call it the feature branch), you commit to this branch, and meanwhile, nothing is changed in the master branch. In this case, the merge process is very easy to apply, without any conflict and we call this case fast forward merge.

Fast forward doesn’t add any additional commit mentioning this merge operation, it’s just about placing the commits from the new branch to the master branch.

To apply this merge,

  • git checkout master git merge new_branch

Now when you check your commit history in the master branch, you will see the commits from the feature branch are listed also.

Recursive Non-Fast Forward: After you created a new branch for your new features (let’s call it the feature branch), you commit to this branch, and meanwhile, some new commits are made in the master branch also. In this situation, we are talking about the Non-Fast-Forward merge. When these two branches are merged, the commits are ordered by their date. In contrary to fast forward merge, a commit for the merge operation is made and added as the last commit of the master branch in a non-fast-forward case.

The command to apply a non-fast-forward merge is the same as fast-forward merge, it’s git understanding that the fast-forward merge is not possible and leads to a non-fast-forward merge.

In a non-fast-forward merge, it is possible to have some conflicts to fix since there are some changes in both branches. If you changed a file in the feature branch and it is changed at the same time in the master branch, you have to decide which change to accept (or both) to solve the conflict and complete the merge. On the other hand, if only different files are changed in these two branches, there will be no conflict during the merge.

To fix the merge I suggest you use the Visual Studio Code interface as it makes you see the differences and decide what to do easier:

  1. Rebase Mechanism

I mentioned that in the non-fast-forward merge since different commits are made in both branches, the commits are aligned by their date. For example in the image above, it’s not sure if the order of the commits in master will be m1 → m2 → m3 → f1 → f2 or m1 → m2 → f1 → f2 → m3 or m1 → m2 → f1 → m3 → f2.

If you want to align these commits in master branch commits → feature branch commits order, you can use rebase mechanism to change the base of the feature branch with the latest version of the master, and add the feature branch commits after this new base. This process also allows you to apply to fast-forward merge since in this reorganized case we have all the commits made in master placed in the feature branch which means there is nothing changed in master when we merge them.

To apply to rebase:

git checkout feature
git rebase master (rebase feature branch using the master branch)
git checkout master
git merge feature (merge the master branch with feature branch via fast forward) 
  1. Cherry-Pick

Sometimes, you may want to pick some commits to add to the master branch but not every commit made in the feature branch. In this case, cherry-pick command is the one you are looking for!

git checkout feature
git log (check the ids of commits you wanna apply to the master)
git checkout master
git cherry-pick commit_id

Cherry-pick operation adds only 1 commit on your master branch as a zip version of the commits you picked.

This tutorial is about the important git commands and their logic. Don’t forget that Git is to control the workflow on your local computer and if you want to carry this repository on the cloud and communicate between these local-cloud repositories, you have to open an account on Github. Some basic commands between Git and GitHub are given below:

  • git remote add origin URL to connect a GitHub cloud repository to your local work repository
  • git push origin master to load the files from your local repository to the cloud, and update the changes (merge) if it’s not your first push!

Basic Vocabulary:

  • Staging means adding the changes into the git tracking area with the following command git add filename (or) git add .

  • Commit means to save the staged changes as an updated version of your project with the following command git commit -m "commit message"

  • Branch means an additional working directory created from your main directory. The main goal is to work on new features on an additional branch without affecting the main repository and add these new features by merging your branch with your master branch when the features are tested and ready to use in real time.
  • Master branch means the default main branch comes with git initialization for your work repository. Main is another common name that some people prefer to use and you can change your main branch name with git branch -M branch_namecommand

Thanks for your interest in this tutorial and I hope that it was helpful! After learning Git commands and their usage, I suggest you take a look at GitHub commands to control your Versioning between cloud and local repositories better. Its always a good idea to be familiar with GitHub since when working in a collaboration, cloud repositories are the most common way rather than local ones. 💥


Related Articles