I'm a big fan of github flow. Which basically states that you should create a branch for each feature, then merge it into master only when it's ready to push to production. However, github flow is a bit ambiguous about how to resolve conflicts between your feature branch and master. What follows is a method of dealing with that problem.
- Anything in the master branch is deployable
- To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
-
a really good addition: how to merge into master. Here's why
git checkout master && git pull --rebase git checkout yourBranch # cleanup your history to merge any WIP commits with `git rebase -i HEAD~<number of commits in your branch>` git rebase -i master git rebase master # if that is too messy, git rebase -i HEAD~100 (where 100 is aproximately how many commits you've made on this branch) # fix any errors in the rebase git push origin yourBranch
-
create a PR for your branch and have someone else code review it
- Once it is merged and pushed to ‘master’, you can and should deploy immediately