Git Workflow Best Practices

git_workflow_best_practices.md

Git Branch Merging Best Practices

1. After you've selected a feature to work on, create a branch in your local repo to build it in.
   • $ git checkout -b calaway/short_description_of_feature
2. Implement the requested feature, make sure all tests are passing, and commit all changes in the new branch.
3. Checkout the master branch locally.
   • $ git checkout master
4. Pull down the master branch from GitHub to get the most up to date changes from others. If you practice git workflow as described here you should never have a merge conflict at this step.
   • $ git pull origin master
5. Make sure all tests are passing on master and then checkout your new branch.
   • $ git checkout calaway/short_description_of_feature
6. From your new branch, merge in your local master branch.
   • $ git merge master
7. Resolve any merge conflicts, make sure all tests are passing on the new branch, and then commit all changes from the merge.
   • $ git add .
   • $ git commit -m "Merge in master."
8. Push the feature branch to the remote repo.
   • git push --set-upstream origin calaway/short_description_of_feature
9. Submit a pull request on GitHub asking to merge the branch into master.
10. A teammate reviews the code for quality and functionality.
11. The teammate merges the pull request and deletes your branch from GitHub.

Git Commit Message Best Practices

From the Pro Git book:

Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. [...] It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of “I added tests for” or “Adding tests for,” use “Add tests for.”

This is awesome! For number 6, does git rebase master accomplish the same thing or do they serve different purposes?

You can do the same thing, but works different, creates copy of your commits and adds them to the end of your target and looks like a unique branch do not create additional merge branch, so be careful and don't use it when those commits are public and shared because it will create problems.

I've been looking to organize my workflow better. A project I created to practice with Unity3D is starting to look a bit messy (not helped by some branches that are probably due to be scrapped), and I think this will help. Thank you!

So now , your feature branch is synced master that contain other college's changes. Then how do you merge in to release branch ? if you just merge your feature branch to release branch , then your merge will also contain other's commits... is it good or is there a way to only include the changes made by yourself ?