gistfile1.md

I and my team are working off of master. We use a Pull Request flow: Feature branch, PR Review, Cleanup, Merge.

Feature Branch

I make branch 'feature' off of master.

---o---o---o---master
           |---feature

I make a number of commits to that branch. Meanwhile, the rest of my team works hard on master.

---o---o---o---o---o---o---master
           |-o---o---o---o-feature

I make a Pull Request into master.

We use this PR to code review. Additional fixes get tossed onto the feature branch as minor fixes.

---o---o---o---o---o---o---master
           |-o---o---o---o--o-o-ofeature
                            | | |
                          Minor Fixes

Once this has been approved by the team, we begin cleanup.

NOTE: These next two steps are often unifed by using git rebase -i master. I seperated them for ease of description.

First, we squash the feature into a single commit with an awesome message.

git rebase -i 1234

          sha: 12345
           | 
---o---o---o---o---o---o---master
           |---------------o "Implemented DeleteService....." 

Then, we Rebase off of master to fold in the changes done there.

git rebase master

---o---o---o---o---o---o---master
                       |---o "Implemented DeleteService....." 

The benefit to this is that the Feature Branch now looks exactly the same as master will after we fold the changes in. If our tests pass here, they will pass there.

Merge

Now all that we do is git checkout master, then git merge feature. Now, master looks like this:

---o---o---o---o---o---o---o
                           | 
               "Implemented DeleteService....." 

Additionally....

The order of this is not strict. A lot of people prefer to cleanup before the PR, for instance. The base agreement is that there is no intrinsic benefit to network trees or git merge commits.