When multiple developers contribute to a project, keeping on top of the constant flow changes can be a challenge. The following simple review workflow assumes a shared git-repository with a fairly linear commit-history, that is, not having too many merge-commits.
So, assuming a fairly linear history of commits from multiple developers, how do you easily keep track of what you have already read through and reviewed? Easy, use a local branch as a bookmark. This tiny script makes it trivial to add or update such a branch:
Save this as a new file called
Usage is extremely simple:
Running one of these commands will mark the given treeish as reviewed, and when you look at your commit-history in a visual tool such as
reviewedbranch visually indicates how far you have gotten. Note how both commit-IDs, branch names, tags, and relative commit-IDs can be used as argument.
You can also utilize this review bookmark from the commandline. The following shows you all commits added to master since your last review:
git log reviewed..master --reverse
You can add a
--patchto that command to see the full diff for each change. Adding
--format=onelinejust shows you the commit-IDs and first line of the commit-message.
Once you’ve read all the latest commits on master, simply do a
and you’re done.
Why not use a tag?
I find it convenient to be able to do a push of all tags to the central repository with
git push --tags
and this would share such a private review-tag. As this is my private reminder of how far in the commit-history I have reviewed, sharing it is just confusing to other developers.
Notice: Any commits which are added only to the
reviewedbranch are unreferenced when you mark a new treeish as reviewed. Just something to keep in mind.
How do you keep track of the flow of changes?
I use git as my primary version control tool for all internal development, configuration files, and collaborative development. As branches are virtually free with git, it makes a lot of sense to create short-lived feature-branches for each new thing you start working on. This does mean a bit of shuffling back and forth to integrate changes from others in your local work, but this “pull changes and rebase my work” workflow can be greatly eased by these small scripts.
For more than a year I’ve been using two small shell-scripts called
shipto manage local feature-branches. Hat-tip goes to ReinH for the original version of these. Notice these shortcuts are only usable when you work on a feature branch based on master, not remote branches in general.
hackpulls down the latest changes from the central
origin/masterbranch, and rebases your local feature-branch on this new
master. The end result is all the latest changes are integrated, and you will be able to push your commits without adding an unnecessary merge-commit to the shared history.
shipis a quick way to merge your current branch to
master, and push the result to the central repository branch called
Usually when a feature is completed, I run
hack, run all code-tests for the project, the run
ship. Taken together, the process is automated and looks like this:
hack && rake && ship
rakeruns all relevant tests, and exits with a non-zero error-code. If one or more tests fail, the changes are not shipped (due to the nature of
&&between the commands), and a fix can be committed before sharing the changes with other developers.
What is your process for managing feature branches in git?
Update: See also the chop script.
subscribe via RSS