git工作流程：维护功能提交的历史记录

Question

What is the best way to maintain a history of functioning versions of your git repository ?

It's so easy to branch and merge in git that we do it all the time. I've generally taken to using topic branches, only merging into master when a feature is complete. This works fine, but after several iterations the history of your master branch is a convoluted graph and it becomes very difficult to identify commits that represent a correctly functioning version of your application at any point in time.

I'm looking for advice on a workflow that enables me to easily retrieve a working (ie not in the middle of developing a feature) copy of my repo closest to a specified date. Another useful feature of this would be retrieving a list of commits that represent a functioning repository changing over time.

I realize this could be done manually ie examine the commit log and messages to find the last commit right before the next feature was started, or by running the test suite against each commit and filter by that. Those methods would be somewhat reliable, but I'm looking for a less haphazard way of doing it.

Answer 1

You can use git log --first-parent master to see a history of master, following only the first parent of each commit. This means that when a merge is encountered, only the first parent (which should be the previous commit on master) is followed, and the second parent (the last commit on the topic branch) is ignored. With your workflow, this will likely consist of mostly merges. The important point is, as long as any commit (or merge) made on master is considered a functioning version, then every single commit in this log is a functioning version.

Answer 2

I am super glad to hear you using feature branches - go you :)

After that, there are two ways to keep things tidy, and one thing that just helps your brain work better.

1) For each branch you are actively working on, make a local branch. You want to do this because you want to be able to rebase what everyone else is doing. Without the rebase you'll have a bunch of commits representing merges that really don't add anything to the history. You can rebase the branch which is remote, however this is discouraged as rebasing rewrites history, and should two people do it at the same time - it gets hairy and really hard to follow. Early on in projects I usually just work off master . So I create a master_local which does not track anything (git branch master_local). When people make changes I want or need (git pull), while having master_local checked out, just rebase (git rebase master).

And the tip to keep your brain working well - merge your local branch into the tracking/remote feature branch often. The longer you keep things separated the more you'll have to remember, the larger your merge will be, the more others will be complaining that you're not working, etc. ;)

2) If you have large features and many people, you'll have tons of commits per feature branch. Once these features are ready to get to master you just don't need to see all of it. And if you want to revert the feature out you don't want to revert several hundred patches. The answer to all of this is to squash your commits down to 1 single commit. This way master is a nice and short list of the features contained therein. (http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)

Answer 3

I think the best solution (long-term) would be to adapt your workflow, to keep your master branch clean of intermediate 'checkpoint' commits. Benjamin Sandofsky details a workflow that appears to stay closest to the way Git was designed.

The gist of the article:

Think of branches in two categories: public and private.

Public branches are the authoritative history of the project. In a public branch, every commit should be succinct, atomic, and have a well documented commit message. It should be as linear as possible. It should be immutable. Public branches include Master and release branches. A private branch is for yourself. It's your scratch paper while working out a problem.

The no-ff band-aid, broken bisect, and blame mysteries are all symptoms that you're using a screwdriver as a hammer.

You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up your branch with tools like reset, rebase, squash merges, and commit amending. If you treat your public history as pristine, fast-forward merges are not only safe but preferable. They keep revision history linear and easier to follow.

Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable.

The intended workflow is:

1. Create a private branch off a public branch.
2. Regularly commit your work to this private branch.
3. Once your code is perfect, clean up its history.
4. Merge the cleaned-up branch back into the public branch.