When we work on our “task” branch that based on our primary branch, We may have overlapped commits when our team have update the primary branch.
Many people just use “merge” the primary branch into their “task” branch, but it will make extra commit that contains actually same changes, that may a project history not clean, and make hard to review (for example: in case we use merge or pull request). What we need to do is rebase instead. Actually, the merge should only happen when you need to apply your “task” branch into your primary branch.
Rebase will synchronize the commits and put our changes in top of commits. Let’s see what the process step by step. For example, you work with git flow, you’re now on “feature/xzy” against develop.
$ git flow feature start xzy # can be replaced with # git checkout -b feature/xzy develop
And we are working on a big task. On the middle of the day, someone or some people on the team make a hotfix that make a commit to master and develop, that make your branch is outdate, and has some conflict.
What you can do to synchronize is by using rebase with steps:
1. Checkout primary branch (at this case: develop), pull latest
$ git checkout develop $ git pull origin develop
2. Back to our feature branch and rebase
$ git checkout feature/xzy $ git rebase develop
From now on, if we see conflict, and get error:
You are currently rebasing. (fix conflicts and then run "git rebase --continue")
We need to see the files that contains conflicts that may contains:
, and fix them. After that, we can close the editor. Don’t make a commit after fixing conflicts in the files!
3. Add resolved files and you can continue
$ git add . $ git rebase --continue
4. Last, if we publish the “feature/xzy” branch into our origin/feature/xyz, we need to push –force because the commits has been rewritten:
$ git push --force origin feature/xzy
If everything ok, then we are now synchronized. That’s it 😉
If you’are working with pilot project that many feature are experiment conditions, you need this feature, You can remove commits that you don’t want to exist in your revisions log. This feature named rebase. You can find the whole commits lists on range by typing :
git rebase -i HEAD~5
that command will show you last 5 commit and show them in the editor like the following :
pick 5c22314 third commit pick 8de60b5 fourth commit pick 9d3556f fifth commit pick 434ddc3 sixth commit pick d9b917g seventh commit # Rebase d9b917f..8de60b5 onto d9b917f # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. # ~ ~
If you want to remove fifth and sixth commit, just remove these two lines and save the editor ( if you’re working with vim, type ‘dd’ in the line you want to delete, and type ‘:wq!’. After do that, check by typing command :
and you will get the result like the following ( fifth and sixth commit deleted ! )
commit d9b917g9d3556cfb0d0bbcd8ecd952cf4f358eea Author: Abdul Malik Ikhsan <firstname.lastname@example.org> Date: Wed Feb 20 15:47:13 2013 +0700 seventh commit commit 8de60b59d3556cd8eeafb0d0bbcd8ec952cf4f35 Author: Abdul Malik Ikhsan <email@example.com> Date: Wed Feb 20 15:47:13 2013 +0700 fourth commit commit 5c223149d3556cd952cf4f358eeafb0d0bbcd8ec Author: Abdul Malik Ikhsan <firstname.lastname@example.org> Date: Wed Feb 20 15:47:13 2013 +0700 third commit commit 5c2231434ddc3bac911ab38a22d2b47f5736f7d4 Author: Abdul Malik Ikhsan <email@example.com> Date: Wed Feb 20 15:46:50 2013 +0700 second commit commit d9b917f6a48eb9c0c415772f70b7c66adf3de0b5 Author: Abdul Malik Ikhsan <firstname.lastname@example.org> Date: Wed Feb 20 15:45:26 2013 +0700 first commit
With rebase, you can combine commits to/from other branch or squash commits with commands list while you get the list of commit via rebase -i command.
GIT version control got one feature that I really like, named hooks. With hooks, we can configure what GIT do after metadata pushed to the remote server. It can ease our development because we don’t need to upload file manually, just say : git push remoteserver, so the file in our online web will be replaced.