Re: [tlug] Great Git resources

[Josh Glover <jmglov@example.com>]

On 4 February 2011 04:17, Edward Middleton

> We use git in mostly the same way you would use subversion (i.e.
> centralized master server).  The benefits that stand out to me are.
>
> - being able to pulling changes from multiple sources
> - being able to store locally a set of changes before pushing to the master.
> - history rewriting to cleanup a set of changes before pushing them.

I'm in a similar situation to Edward. In addition to the benefits he
listed, I like being able to create a private local branch to work on
so that I can commit as much as I want without overwhelming my
teammates with commit emails. I commit *really* often, though not as
often as Steve, who apparently has an XEmacs hook that commits every
time he saves. :) I try to ensure that I have only one thing per
commit, and I like to commit my broken tests *before* committing the
code that makes them pass.

So git lets me have the following workflow.

1. Pull a feature sticky off the kanban board
2. git checkout master  # tracking origin/master, our centralised repo's trunk
3. git pull  # svn up
4. git checkout -b new-project  # create a local new-project and switch to it
5. Write a functional, integration, or acceptance test that fails
6. git commit -a  # the -a saves me from having to manually git add files first
7. Write a unit test that fails
8. Implement enough to make the unit test pass
9. git commit -a
10. Repeat steps 7-9 until my big test from step 5 passes
11. post-review --guess-description  # submits a code review request
to our Review Board server [1]
12. Publish code review request
13. Get CR feedback
14. Process feedback (usually another 7-9 loop)
15. git checkout master
16. git pull  # grab the latest changes to trunk before merging my stuff
17. git merge --squash new-project  # takes all of my changes and
squashes them into a single commit; does not actually commit anything
18. git commit  # I basically enter what it says on the feature sticky
as my commit message
19. git push  # hooray!

I still have all of my local history in my private branch, so when a
bug is found in my code (note that I did not say "if a bug is found"),
I can easily look at individual commits to see where I may have
introduced the bug, do things like "git revert", etc.

Also, I recently started working on a larger project with another
engineer (most of our projects are small enough to just have one guy
at a time working on them), so we set up a private repo and set our
shared branch to track that. We could share code easily without
overwhelming the rest of the team with commit emails. :)

Cheers,
Josh

[1] http://www.reviewboard.org/