We utilize the Git Feature Branch workflow
In practice, it works as follows:
-
Start with an updated local development branch -- by checking out the dev branch and pulling changes:
git checkout development
git pull origin development
-
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). -
Do work in your feature branch, committing early and often, following the Seven rules of a great Git commit message:
git commit -m "Comment about the commit"
-
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
- or -
-
Optional: Perform an interactive rebase (squash) your commits before pushing the branch:
git fetch origin development
git rebase -i origin/development
-
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
Your code must be reviewed by at least one other developer, preferably two, and receive +1s from each of them, in order to be eligible for a Merge.
- Create a Pull Request in github between your feature branch and development.
- Standards for Code Review can be found here Code Review.
- After your code passes Code Review, merge your code into Development Branch via the GitHub interface. Delete your branch after merging.
-
Pull to update your local master branch:
git checkout master
git pull origin master
-
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
-
Do work in your hotfix branch, committing early and often:
git commit -m "Comment about the commit"
-
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
-
See above for details on squashing during a rebase.
-
Push your changes upstream to get code reviewed
git push -u origin hotfix-branch-name
-
Merge your changes with master
git checkout master
git merge --no-ff hotfix-branch-name
-
Back-merge your changes with development
git checkout development
git merge --no-ff hotfix-branch-name
-
Push your changes upstream
git push origin master
git push origin development
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.
- Open a PR from
origin/development
toorigin/master
in GitHub - Document Rake tasks, Migrations, and changes in PR description
- Get at least 1 more Dev to review this PR
- When you have sign off from Dev, merge this PR
- This will kickoff the master build, which can be monitored in CI.
- From here, follow appropriate steps to complete the release.
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
Much of the above is shamelessly stolen from A Git Workflow for Agile Teams and A successful Git branching model.
We have simplified it and adjusted it a bit more to our liking and needs.
Tagging information has been taken from https://git-scm.com/book/en/v2/Git-Basics-Tagging