Git Feature Branch Workflow

git-workflow.md

We subscribe to the Git Featrue Branch workflow, briefly described in that link.

In practice, it works as follows:

FEATURE DEVELOPMENT

Steps to Follow:

1. Start with an updated local development branch -- by checking out the dev branch and pulling changes:
   git checkout development
git pull origin development

2. Create and checkout a feature branch:
   git checkout -b initials/fancy-branch-name
   Note: LP convention: Your branch name should start with your initials and then a description of your feature (as above).

3. Do work in your feature branch, committing early and often:
   git commit -m "Comment about the commit"

4. Rebase frequently to incorporate upstream changes:
   git fetch origin development
git rebase origin/development

• or -
  git checkout development
git pull
git checkout initials/fancy-branch-name
git rebase development

5. Optional: Perform an interactive rebase (squash) your commits before pushing the branch:
   git fetch origin development
git rebase -i origin/development

6. Once you have reviewed your changes, and verified formatting and intention, push your changes upstream to origin:
   git push -u origin initials/fancy-branch-name

Get Your Code Reviewed(by creating a Pull Request)!

Your code must be reviewed by 2 other developers, and receive +1s from each of them, in order to be eligible for Merge.

1. Create a Pull Request in github between your feature branch and development.
2. Standards for Code Review can be found here.
3. After your code passes Code Review, merge your code into Development Branch via the GitHub interface. Delete your branch after merging. Note: The Continuous Integration server will automatically build your new branch. If successful, it will deploy your changes to the staging server, if not it will email you to indicate a failure.

PRODUCTION HOTFIX

Steps to Follow:

1. Pull to update your local master branch:
   git checkout master
git pull origin master

2. Check out a hotfix branch. Note: The hotfix branch name should start with the issue number the work is related to and a brief description. For example: 1234-big-fix
   git checkout -b hotfix-branch-name

3. Do work in your hotfix branch, committing early and often:
   git commit -m "Comment about the commit"

4. VERY IMPORTANT: Interactive rebase (squash) your commits before merging with development:
   This provides a single commit on master with everything in the hotfix.
   git fetch origin master git rebase -i origin/master

5. See above for details on squashing during a rebase.

6. Push your changes upstream to get code reviewed
   git push -u origin hotfix-branch-name

7. Merge your changes with master
   git checkout master
git merge --no-ff hotfix-branch-name

8. Back-merge your changes with development
   git checkout development
git merge --no-ff hotfix-branch-name

9. Push your changes upstream
   git push origin master
git push origin development

PRODUCTION RELEASE

This includes everything on the development branch. If this is NOT what you want then you can cherry-pick features from the development branch. This is when having single commits per feature is very important.

1. Open a PR from origin/development to origin/master in GitHub
2. Document Rake tasks, Migrations, and changes in PR description
3. Get at least 1 more Dev to review this PR
4. When you have signoff from Dev, merge this PR
5. This will kickoff the master build, which can be monitored in CI.
6. From here, follow appropriate steps to complete the release.

References

Much of the above is shamelessly stolen from A Git Workflow for Agile Teams and A successful Git branching model.

It is duplicated here so that we can modify to our liking over time.