5 GIT tips that you can use with GIT branches

Table of content

• Wrong branch name?
• Cherry-pick – in case you just want friends to commit to your branch
• Take advantage of Git Rebase
  
• Getting rid of quick-fix commits
• Summary

Being a front-end developer involves getting into numerous arguments with the back-end guys, usually over whose technology is better. Clearly, one side has little in common with the other side, but there is one thing that bridges the two realms. A single technology to rule them all, and reign above all the differences: GIT, the beloved version control system.

All of us know GIT and we are always ready to use it. For example, in case of emergency of fire the expected behavior would be:

1. git add
2. git commit
3. git push
4. and then we are finally allowed to leave the building

At the core of our work with GIT are branches. But do you know all their features? This article will show you some tips, tricks and functions that you should know to fully use the potential of GIT.

Wrong branch name?

At some point, every IT company realizes the need to standardize working with GIT. This involves, for example, creating a task acceptance process and branch naming policy.

So we create our feature branch, name it according to the company policy, develop it on this branch… only to find out there is a spelling error in the branch name… There are a couple of ways to fix it (after all we are programmers, and solving problems is what we do) but we can do it using the git branch function.

git branch -m wrong correct

# Rename branch locally

git push origin :wrong

# Delete the wrong branch

git push --set-upstream origin correct

# Push the new branch and set local branch to track the correct remote

That way we can rename the branch locally and erase the evidence of any mistakes from the remote source.

What to do if I forgot to change branch

These things happen. How many times have you been in such a situation: your project manager standing next to you, urging you to make a small change – “it will only take a second” (I just hope you didn’t have to deal with it too often) – and you accidentally commit to the wrong branch. A fix to this involves using GIT and does not require making the same change twice.

git branch correctbranch

git reset --hard HEAD~1

# Go back to previous commit

# (but remove all uncommitted work)

git checkout correctbranch

1. Create a new branch from the branch that you committed before.
2. Git reset to restore the state of the commit to the previous commit (you can go back any number of commits if you want)
3. Switch to the new branch

Then you can do whatever you want – merge it or work further on the correct branch.

Cherry-pick – in case you just want friends to commit to your branch

Git branches were designed to allow working simultaneously on different features within the application without resolving all the conflicts at the same time. But parallel work sometimes results in working on the same files, and may require applying the same change to two separate branches. How to deal with it?

Let’s assume that we have two branches dev and rel_2.3. On the dev branch a colleague has added an additional field in the object model and you want to use that field too.

Image from https://i.stack.imgur.com/R4nfN.png

git cherry-pick dev~2

This will apply a change made on the branch rel_2.3 the second from the head commit

Image from https://i.stack.imgur.com/23fCh.png

If needed, we can provide an exact hash of the commit to apply the changes to our branch.

git cherry-pick <commit_id>

Take advantage of Git Rebase

But what if you want to apply all the committed changes to the original branch from which my branch was created?

Suppose that we have such a situation in our repository:

Image from https://hackernoon.com/hn-images/1*fLmkwjjWawGJ8a-XSac7yw.png

We have two branches developing features on their own. And we want to apply all the new changes from master to our feature branch. What can we do? Probably, you will say that we can merge them. But this will create a new commit which will remove the whole history of the commit.

Image from https://hackernoon.com/hn-images/1*IN9828OlYl78n1eydimeHw.png

But what if it is not the end of our work on the feature and all we want to do in update all the changes deployed on master to our feature branch? You can use git rebase.

git checkout feature

git rebase master

What will happen? GIT will change the point in the repository from which feature branch was created and tries to apply all the changes (i.e. the commits) that were created on the feature branch.

So we’ve rewritten the whole history of the feature branch and that way we can maintain the linear commit history of our project.

The main advantages of git rebase are:

1. You work on your local repository and can synchronize with the head of the branch without interfering with others’ work.
2. Commits are applied one by one (not all of them like in git merge) so you can resolve conflicts on commit level.

One thing to remember: The golden rule of rebasing is to never use it on public branches. Because reverting git rebase in much harder that reverting git merge.

Getting rid of quick-fix commits

Let the programmer who never forgets to add a file to the commit cast the first stone. These things happen – and usually lead to a fix commit. We can always use amend to rewrite the last commit and add missing files or changes.

git commit --amend

But what if we’ve already deployed the changes to a remote repository? How to hide a history of ten following commits on a feature branch that only have the fix message, before we upload the change to the main branch? We can use git merge:

git merge --squash feature_branch

git commit -m “New correct name of our changes”

Now we are creating a completely new commit with changes – one that doesn’t show all our work in progress and various quick fix commits.

Summary

I hope that after reading this article you will find yourself better with working on the branches. But remember – there is still much to discover in GIT.