How to use git effectively in a software project
In this article I will talk about how to use my git in the past. The way I organize git branching for most of my projects. Of course it is not the way I think. That is just the way I read and is supported by SmartGit management software. Seeing it so effective, I shared it up here.
Awesome Git Branching Model
Why Git?
I used to use some source management systems like SVN or Hg . I still prefer to use Git . It has a lot of good points like scattering, no need to connect to the Central Repository when committing …
Git changed the programmer's way of merging and branching. It makes those tasks much easier, more pleasant and simpler. In books about SVN / CVS, often merging and branching will be introduced in the final chapters. That is for advanced users. As for Git, it was introduced very early, because it is Git's strong point. You will not be afraid of these easy conflicts. It is introduced in Chapter 3 of Pro Git
You can refer to the strengths and weaknesses of Git at two addresses below:
Git Website
Now we will go through the next part of the story, introducing Git Developing Model that I often use. I think it is a fun and interesting way for every team to apply to manage their team's software development process.
Decentralized but centralized
When you work with git, usually you will work with a Git Server like GitHub , Bitbucket , Google Code or manually setup a Git server (My company uses Gitlab ). About the nature of Git. This is not considered a server, because it is level with the local repository on your computer. I like to use the phrase Central Truth Repository * more. The central word here is an implicit concept because Git is a distributed management system. And this is also Git Repo containing branch origin * . A familiar name for all Git users.
Model Central Truth Repository
Every programmer pulls and pushes on origin. But besides the developers in the same team can pull changes together in the same subteam. This is useful for teams working together to develop some great features, and before pushing the complete code to the server, they can work together without needing to central repository. This is very simple, you just need to add remote pointing to the colleagues' repository.
The main branches
I used to work in a project that only uses a single branch as master. This is not wrong but it causes quite a lot of trouble. And the CI system is very well built.
Central Repo only needs to contain 2 unique branches during the project development process
1 | - master - develop |
Master branch is of course familiar with Git users already. It is the branch containing the stable code. Source code in HEAD commit always in production-ready state .
Develop branch is the branch containing the code in ready state for the next release. It is often referred to as "integration branch". Nightly Builds (Daily Build) are usually built from this branch.
Once the source code in the branch development reaches a stable state (At least to pass the Unit test cases), any changes on develop branch will be merged into master branch and tagged with a release number.
By combining with CI or git hook systems . You can fully automate all build and release tasks. The following example (I write in fake code)
If (master in orgin receives push) The system will run test If test result = OK Build If build OK Push on the CDN and ready for release If Build = False Email administrator If Test result = False Rollback code In the master branch on origin Notify the End End administrator
Similar to Develop branch. Each successful build will be pushed to the server containing Nightly Build
Supporting branches
Besides using two main branches as master and develop, there should be additional supporting branches running in parallel with the 2 main branches in the software development process. The purpose of this is to help the team developers easily manage the features, easily prepare for the releases or can quickly fix the system if there are errors in the development process.
Unlike 2 branch master and develop. These branches do not run throughout the project. That it will be opened and closed when needed.
There are three branchs that you should use including
1 | - Feature branches - Release branches - Hotfix branches |
Each group, according to its name, will have different functions according to the rules of the team that will open, close and merage at appropriate times.
In essence, these branches are also branch Git merely, but depending on the purpose of use it is named so.
Feature branches
Usually separating the branch from the main branch is develop, and when completed, merge it into develop
Naming: all names except master, develop, release- , or hotfix-
Should be set: feature- *
Feature branch is often used for the development of a software feature or function. It is often open to one or a group of developers to develop a new feature together.
The goal of this branch is to live in that feature development process that will eventually be merged into develop branch if that feature is completed or will be canceled if the feature is too bad.
A feature branch will be closed and merged into develop branch. Do not merge into master branch
Create a feature branch
When creating a branch. It will be separated from develop branch
1 | $ git checkout develop $ git checkout -b develop/myfeature # Switched to a new branch “my feature” |
Complete a feature branch during development
When a feature is completed, it will be merged into develop branch to be ready for release in the next version.
1 | $ git checkout develop # Switched to branch 'develop' $ git merge --no-ff myfeature # Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature # Deleted branch myfeature (was 05e9557). $ git push origin develop |
When using the flag —no-ff , git will create a Merge commit point. Otherwise, it will create a fast-forward. Using merge commit is better than fast-foward because it will help you not to lose the commits of a feature branch, and keep track of the development of a feature branch or confuse the commits on develop branch. Help members in the team easily work together.
Later, when you need to review the project commit process, you will see the history of commits very easily, see what you have done, rather than having to go back and forth commits, reviewing commit mesgage. Helping the team leader and programmers without a headache when needing to rollback or reset code. Very simply, just use the flag –no-ff. Although it may create some empty commits. But you will get more benefits than fast-foward commit.
Release branches
May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release- *
Release branches make it easier to prepare to release a new version. It allows you to fix minor software bugs, change the version numbers, build date or small app profiles for the next development. This makes develop branch look clean and neat and you will easily understand what your team has done.
Why is the release branch removed from develop branch and merge into master or develop.
The goal of this work is to enable two work and release functions and release releases that can be done by two different programmers that are parallel to each other. You can prepare to release and wait for other features to complete. Or if your team is ready for release, but still not released, it can be merged into develop branch and wait until the appropriate time can be merged into master branch.
Creating a release branch
Similar to opening a feature branch. When a version in develop branch has reached the ready release state, you can extract a release branch to prepare for the release process.
1 | $ git checkout -b release-1.2 develop Switched to a new branch "release-1.2" $ ./bump-version.sh 1.2 Files modified successfully, version bumped to 1.2. $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-) |
Following the above example, by creating a release branch and running the script for the preparation process.
The existence of a releash branch is usually very short. and it will be closed when that version is released. In the process it exists. You can fix the bug on this branch, but don't add great functionality on this branch.
Finishing a release branch
When a release branch is ready. It needs to be merged into the master for release. And you need to remember that every commit on master branch should be releases. It will make it easier for you to follow the development process. Finally, all changes on release branch and master branch need to be merage into develop branch to synchronize the code for the next pharse.
1 | $ git checkout master Switched to branch 'master' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) $ git tag -a 1.2 |
Tagging for the code should be easy to track the development process.
Then you merge into develop
1 | $ git checkout develop Switched to branch 'develop' $ git merge --no-ff release-1.2 Merge made by recursive. (Summary of changes) |
If there is conflicting, you can fix and commit.
And finally delete the releash branch.
1 | $ git branch -d release-1.2 Deleted branch release-1.2 (was ff452fe). |
Hotfix branches
Sewing branch off from: master
Must merge back into: develop and master
Naming branch convention: hotfix- *
The hotfix is very similar to release branches. because it is in the process of preparing for release but to fix errors that are not in the plan. When an application error is discovered and needs to be fixed immediately, Hotfix will make this easier. A branch hotfix will be extracted from a commit that carries the version tag on the master branch. Hotfix also makes it easier for team members to interact with the work because a developer will do a bug fix on the hotfix branch while every other member of the team develops features for the project. continue develop branch.
Creating the hotfix branch
The hotfix branch created from the master branch, for example version 1.2, is the current version, and has been found to have a bug. Meanwhile, the version on develop branch is still incomplete. We can then split a hotfix branch and start the error correction process.
1 | $ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ ./bump-version.sh 1.2.1 Files modified successfully, version bumped to 1.2.1. $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-) |
Don't forget to change the version number. Then commit the changes.
1 | $ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-) |
Finishing a branch hotfix
When completing the necessary fixes. The hotfix branch needs to be merged into the master, and also needs to be merged into develop branch to ensure that these bugfixes will also be included in the next release.
1 | $ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1 |
Later
1 | $ git checkout develop Switched to branch 'develop' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) |
There is an exception to this process if, when a bugfix release is completed and an release branch exists, the hotfix release needs to be merged into the release branch. Because the release branch will be merged into master and develop.
Finally, remove that branch hotfix:
1 | $ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6). |
summary
Perhaps through this article you will find that using an effective tool like Git in a more efficient way will yield productivity. I know a very good support tool developing this model is SmartGit. Will introduce it more thoroughly in another article.
The article is referenced from: http://nvie.com/posts/a-successful-git-branching-model/
Git-Flow introduction article on SmartGit: http://www.syntevo.com/smartgithg/whatsnew