git flow with rebasing

gitflowrebasing.md

Git Flow (with rebasing)

See http://nvie.com/posts/a-successful-git-branching-model/

Features

A feature is based off the master branch and merged back into a release or master branch.

Working Locally

# checkout master, fetch the latest changes and pull them from remote into local
git checkout master
git fetch
git pull origin master

# create a feature branch that is based off master
git checkout -b jt/lyn-123/some-description

# do your work
git add something
git commit -m "first commit"
git add another
git commit -m "second commit"

# rebase against master to pull in any changes that have been made
# since you started your feature branch.
git fetch
git rebase origin/master

# push your local changes up to the remote
git push

# if you've already pushed changes and have rebased, your history has changed
# so you will need to force the push
git fetch
git rebase origin/master
git push --force-with-lease

GitHub workflow

Identitify task type

• Hotfix, bug, refactors ** things that do not change functionality

  • Open a Pull Request against master

• Features that add or change funtionality

  • Open a Pull Request against release

• When the Pull Request has been approved, merge using rebase and merge, adding the ticket number and a brief description: ie, MQ-330 enable users to order a pizza from the dashboard.

If you are unable to rebase because of conflicts, you need to rebase against master again:

# in your feature branch
git fetch
git rebase origin/master
git push --force-with-lease

Releases

A release takes the changes in release and applies them to master. Releases are tagged with the release version

Working locally

# create a release branch from master
git checkout master
git fetch
git pull origin master
git checkout -b release/3.2.1

# finalise the change log, local build, etc
git add CHANGELOG.md
git commit -m "Changelog"

# rebase against master, which we're going to merge into
git fetch
git rebase origin/master
git push --force-with-lease

Usually at this point you will want to deploy the release branch to the staging server for final QA. If there are any issues, fixes should be committed to the release branch.

Github workflow

• Open a Pull Request against master
• When the PR is approved and the staging deploy has been verified by QA, merge using rebase and merge.
• DO NOT SQUASH MERGE. We don't want a single commit for the release, we want to maintain the feature commits in the history.
• Repeat the steps above against master (may need to rebase first).
• Tag a release on master. Use the version number and put the changelog in the description.

Hotfixes

A hotfix is a patch that needs to go directly into master without going through the regular release process. The most common use case is to patch a bug that's on production when release contains code that isn't yet ready for release.

Working locally

# create a hotfix branch based on master, because master is what will be deployed to production
git checkout master
git fetch
git pull origin master
git checkout -b hotfix/describe-the-problem

git add patch.fix
git commit -m "fix the problem"
git push

Github workflow

• Open a Pull Request against master
• When the PR's approved and the code is tested, squash and merge to squash your commits into a single commit.
• Open a Pull Request against develop (may need to rebase first).
• Tag a release on master. Describe the issue in the name, feel free to put details in the description.