14 December 2015


In past, we were often confronted with two issues when dealing with non-trivial tasks (say, big features) since one and only one commit was allowed, and only at the time when the feature was accomplished.

  • Hard to track/backup our changes during development.

    Most of us would like to be able to make a check point as we made a little progress. That way, had there been anything wrong, we could rollback to previous check point easily. But, since there was only one commit allowed, people had to backup/restore code manually.

  • Hard to collaboration in terms of coding

    Usually, there were more than one people working on the task and hence the needs to sync changes among teammates. With SVN etc. they have to either share an account and work on the same copy of code or manually distribute and apply changes from each other.

Fortunately, with git, those two issues are no long issues at all. You simply

  1. Create a branch for the task you are working on.
  2. On that feature branch, commit as you want.
  3. Check out the branch into which your feature code should goes
  4. Then, run git merge --squash fid-A when the feature is done
  5. git commit.

Later on, whenever you make more modification in the feture branch, you shall redo the merge squash.

  1. Discard previous merge: git reset --hard HEAD^ on the release branch
  2. Redo merge squash: git merge --squash fid-A
  3. Redo commit: git commit If you are using gerrit for code inspection, you shall commit the change with previous commit ID.


  • Creating the feature branch on official repository would be the best as the official repository is usually regularly backed-up by IT and accessable by all team members. However, if you are not allowed to do that, you can create the branch locally and have your teammates clone your repository. Thanks to the distribute nature of git, you needn't do anything to setup your local repository for that.

Reference: Understanding the Git Workflow

blog comments powered by Disqus