Git Workflow Notes

Initialization

New Repository

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

Existing Repository

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

Branch

# 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

Implement

At this point you are within the feature branch and ready to make changes to files.

Commit

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

Merge

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 merging branch feature/kiriakos/1234/fix_something into develop.

New Release

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 by merging release-X.Y.Z back to develop.

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.