3 git commands you should better know

Almost all developers have used Git for project management. It is the most popular tool to organize and maintain a version control for our small and big projects. But most of the time, we only use certain commands that we learn from the documentation, our colleagues or the internet, such as the common sequence of commands to upload our changes:

git add .
git commit -m "message"
git push origin your-branch

Or the command to create a new branch:

git checkout -b your-new-branch

Mostly, these commands should be enough. But on the other hand, you also would like to know more than the utility of commands. For example, when you want to manage your project with a different branching workflow, or you need to apply some hotfix and you don’t want to commit your current changes; which is why you better go deeper into the git commands and learn what you can apply depending on the situation you want to solve. We are going to review some common commands that you may not know at all and others that probably you have never heard about.

Temporal backup

When you have been working in some branch for a while, but you need to change to another one to work on something else, you must commit your changes and then you can move to it. But what if we still don’t want to commit these changes? Probably because it is not a significant state or it might not be a clean commit at all. For this situation, you can git stash to save your current state temporarily. For example, imagine you are in branch 1 (B1), and you need to stop working on it because you need to fix something on branch 2 (B2), all you have to do is use git stash on B1, switch to B2, do whatever you need to do, and then come back to B1 and recover changes stashed.

In order to stash your changes, follow these steps:

1. Add or remove whatever you want to keep.

➜ Test git:(master) ✗ git add .

2. Use the command git stash in order to save everything you added, and then the branch will be at the initial state, before all your modifications. Besides, you can stash your changes with a custom message using the following command: git stash save “my custom message”.

➜ Test git:(master) ✗ git stash save "my first stash"
Saved working directory and index state On master: my first stash
HEAD is now at 796bfff My previous state
➜ Test git:(master)

3. Do whatever you need to do.

4. When you want to recover your stashed changes, you only need to type the command git stash apply@{#}, and replace the # symbol with your stash id number. You can see a list of all the stashes using the command git stash list. You only need to identify the number of your stash (the most recent stash is tagged with 0, and so on).

➜ Test git:(master) git stash apply stash@{0}
On branch master
Changes not staged for commit:
  (use "git add <file>..." To update what will be committed)
  (use "git checkout -- <file>…" to discard changes in working directory)
        modified:   foo.js
no changes added to commit (use "git add" and/or "git commit -a")
➜ Test git:(master) ✗

And that’s it! Your changes will come back and you can continue working, like nothing ever happened.

Pick-up what you want!

A good practice working with Git is to generate small commits, in order to have the changes at an atomic level, creating a cleaner history of changes.

If you usually work with small commits, then you better need to know about git cherry-pick. This command will give you another way to build your own branches, but selecting the specific commits you want to take from branches.

In order to use this command, we only need to know which commits we want to take. Use git log to display the list of commits made on branches in order, from newest to the oldest. Suppose we have the following commit list:

git log --pretty=format:"%h %s"

4966d38 refactor: Apply new structure
bf3d221 fix: Add missing conditional value
3ecb8d3 feat: Add login
68103b0 feat: Add CRUD for users
e97eea8 INITIAL COMMIT

And suddenly, we need to work on a new feature that needs to include some specific changes maybe by our colleagues. In that case, we can use the following commands:

git checkout -b new-feature
git cherry-pick e97eea8
git cherry-pick 68103b0
git cherry-pick 3ecb8d3
git cherry-pick bf3d221

Cool! Now we have a new branch with only the commits that we picked up. If there is any reason to revert the commit collection, we can use git cherry-pick –abort, and we will go back to the initial state. If there is a conflict while doing the process, we can resolve our conflicts, add our changes, commit them, and continue the process by picking more commits.

Master approach

You probably have heard about “Git Flow”, which is one of the most popular branching workflows for Git. But there is another branching workflow known as “One Flow”, which is a good option when your project has Continuous Delivery. The main idea is that every new release is based on the previous release.

To integrate your changes, you usually use git merge to combine the changes made in your work branch with the main one. The use of this command has a problem in “One flow” when we need to work with other people. While we merge multiple branches on the main one, we could have many conflicts. So, how can we deal with it? Git rebase will be our solution!

The main difference between rebasing and merging is that the merge process will maintain both commits on each branch. You can combine both the branches, creating a new commit. With rebase, you can have all the commits from the main branch on your own one, but with your new features. This implies that you are going to be on top of the main commits, which results in a single and unified branch.

Let’s make an example. When we develop a new feature, we usually create a new branch and work on it. Meanwhile, there could be more commits pushed to the main branch, and to integrate our work to the production branch, we use git merge to combine the branches, creating a new commit for the merging process. The alternative with git rebase, is that instead of combining our branch, we are going to take all commits from the main branch, and insert our commits, one by one, on top of it. Look at the image below to see how the git branches tree looks in both approaches.

(https://commons.wikimedia.org/wiki/File:Mergevsrebase.png)

To rebase your branch, you can use the following commands:

git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

If you need to resolve conflicts, add it when you finish with git add, then use git rebase –continue. If there is some process you want to discard, use git rebase –skip. If you need to decline the rebase, use git rebase –abort.

TL; DR

So, a quick recap:

git stash

• To save uncommitted changes and work in a different feature.

• Will help you to merge too many features in a different branch, and avoid side effects.

• If you need to save a specific state of your project.

git cherry-pick

• To create new branches by picking specific commits.

• Will help you with some merging processes.

• Useful when you need to track bugs.

git rebase

• Useful when your project is using the branching workflow “One flow”.

• Use it when you need to merge a branch with too many conflicts, so you can have more control over the process.

• Won’t create a new commit when rebasing.

As you can see, these 3 powerful git commands will give you an authority to solve issues and integrating changes to your codebase. It can be a painful process learning how to use them, but the new powers that you are going to have will definitely help you become a better developer!