Git Workflow Notesa2cudGVjaA==bW9ja2JpdGVzLmNvbQ==
These notes are meant as a supplement to the successful git branching model and a guide to its correct implementation. If you are new to git I suggest you spent quality time understanding the branching model and following these notes closely until you are comfortable with the workflow.
If you just created a new 'test' repository on github/bitbucket then you need to:
mkdir test cd test echo "# test" >> README.md git init git add README.md git commit -m "first commit" git remote add origin https://github.com/KiriakosGeorgiou/test.git git push -u origin master git checkout -b develop master git push -u origin develop
In all likelyhood you are dealing with an existing repository, in which case you can just clone it. This should only be done once.
# clone the repository git clone https://github.com/KiriakosGeorgiou/test.git # setup remote tracking branch for develop git branch --track develop origin/develop
Implementing a New Feature
# make sure our develop is current git checkout develop git pull # create a feature branch from the develop branch; 1234 is a ticket number (eg JIRA ticket) git checkout -b feature/kiriakos/1234/fix_something develop
At this point you are within the feature branch and ready to make changes to files.
git status # optional; if you have new files, add them to your local git index git add <new files> # add JIRA ticket number(s) in the commit comments as well git commit -a # if you want to share your work with others or you want to save your work to origin just in case, # or you plan to do a pull request later: git push -u origin feature/kiriakos/1234/fix_something # now you can keep commiting to the feature branch and continuously pushing to origin with just: git push
Confirm There are no Merge Conflicts
When ready for the merge, to avoid surprises first confirm there are no merge conflicts.
# make sure our develop is current git checkout develop git pull git checkout feature/kiriakos/1234/fix_something git merge --no-commit --no-ff develop git merge --abort # if there are conflicts do: git merge develop # to see the files with conflicts: git diff --name-only --diff-filter=U # resolve the conflicts; the failed merge puts relevant info inside # the files that have conflicts; then do: git commit -a # if you had to fix some conflicts, you may want to repeat the steps above to confirm you have resolved them # finally, confirm nothing to commit and working directory is clean git status # optionally, if you pushed the feature branch to origin earlier, and you fixed some conflicts: git push
If you have access to merge directly to develop:
git checkout develop git pull git merge --no-ff feature/kiriakos/1234/fix_something git push origin develop
If you do not have access to merge directly to develop, you
must do a pull request. Initiate the pull request via the bitbucket/github interface for
feature/kiriakos/1234/fix_something into develop.
Starting a New Release Branch
When getting close to deployment of a new release, you should start a new release branch. Only bug fixes should be merged into the release branch.
# make sure our develop is current git checkout develop git pull # start new release branch git checkout -b release-X.Y.Z develop # push it to origin and setup remote tracking branch git push -u origin release-X.Y.Z # developers now can setup a remote tracking branch for origin/release-X.Y.Z with: # git branch --track release-X.Y.Z origin/release-X.Y.Z # don't forget to eventually merge release-X.Y.Z back to develop
Note that bug-fixes merged to
release-X.Y.Z should eventually be merged back to develop
release-X.Y.Z back to
Deploying a New Release
When a new release has passed testing, validation, and is ready for deployment:
# make sure our release-X.Y.Z is current git checkout release-X.Y.Z git pull # merge release release-X.Y.Z into master git checkout master git pull git merge --no-ff release-X.Y.Z # tag master for release release-X.Y.Z git tag -a X.Y.Z # push tag to remote git push origin X.Y.Z # push local master to remote git push origin master
Implementing a Hotfix
When you discover that production has a serious bug that can not wait for the next release and must be fixed ASAP, you must implement a hotfix, much the same way a feature is implemented, but hotfixes branch off master and merge back to master and develop.
# make sure our master is current git checkout master git pull # Assuming X.Y.Z is the version production is running (check tags) # and NNNN is the JIRA ticket for this hotfix git checkout -b hotfix-X.Y.Z-NNNN master # implement the hotfix and commit git commit -a # merge hotfix hotfix-X.Y.Z-NNNN into master git checkout master git pull git merge --no-ff hotfix-X.Y.Z-NNNN # tag master by bumping the release version up # eg: if prior to the hotfix master was at 6.1.0, X.Y.Zb below should be 6.1.1 git tag -a X.Y.Zb # push tag to remote git push origin X.Y.Zb # push local master to remote git push origin master # don't forget to also merge hotfix-X.Y.Z-NNNN to develop
Note that hotfixes should also be merged back to develop.