I truly believe that to have one commit on one issue is a good practice. I'm sure I read it somewhere in an article like “Best practices”.

As such, my workflow has been the following:

For a new issue, I create a new local branch with git checkout -b new-issue.

Commit all changes into it. Sometimes this involves lots of commits.

When done, I squash the commits and rebase them into current thematic branch.

If something goes wrong, I can git revert the commit, find the bug, fix it, and commit new patch into the thematic branch. I won't change the remote repository’s history.

But today, I was surprised to hear the following workflow:

Create new branch for the new issue.

Commit everything into it.

Use merge --no-ff to merge the issue branch with thematic branch (so we’ll have “merge-commit” that we can revert).

If something goes wrong, we can use git bisect to find the bug.

According to the 1st approach, we’ll have a clean git history, and no idea about overhead branches used during development.

According to the 2nd approach, we’ll have a very messy history, with a lot of ugly, unnecessary merges and commits for just one issue. However, we can use git bisect to find bugs. (Perhaps this is better for refactoring?)

What pros and cons do you see for both approaches?

Which approach do you use, and why?

In practice, have you actually used git bisect to find bugs? (I haven't…)

2 Answers
2

In the end, it is largely a personal taste issue... can only explain my taste (and give a bit of justification for it).

I tend to keep the individual commits around, even when they are just "Fix dumb typos". Any "history rewriting" creates commits that never before existed, so are guaranteed never to have been tested. Besides, minimal commits make git bisect immensely useful when a bug surfaces later. Better to be able to narrow it down to a few changed lines than to a week's work, squashed together.

If a development branch gets a mess of a history, I clean it up (minimally, i.e., reverted commits just never happened, general fixes like whitespace or variable renamings might get applied earlier, some reordering to place related changes together). Commits still stay small, are rarely squashed. This cleanup I do incrementally mostly. Then I merge (or rebase) the cleaned up branch with the "official" one.

Have you ever used git bisect? Also, let's say I'm developing new module for one of the projects, I made a lot of commits and save them at history. When I will need this module on other prject, I will copy it and create only one commit.
– Viacheslav KondratiukMar 21 '13 at 20:35

1

@viakondratiuk, not often. But when I needed to find out what broke a perfectly fine build, it allowed me to do the job of finding the culprit in a few tries. I'd never even tried looking by hand.
– vonbrandMar 21 '13 at 20:38

You can still easily examine the entirety of changes made in a topic branch. For example, git diff 354b644^..354b644 will show you what was changed for topic #3.

But you get benefits that approach #1 can't give you:

The history is much easier to review: commits b45fbcf and 7dfc7e5 (for the topic3 branch) introduce a lot of noise but no actual logic changes. Someone trying to answer the question, "What logic changes were made for topic #3?" might have a hard time digging through the noise if all of those commits were squashed into one.

The merge commits nicely identify the context for the series of commits on the merged branch (e.g., this group of commits were made to address topic #3).

The finer granularity of commits makes it easier to figure out why a particular change was made, which can help distinguish accidental changes from intentional-but-subtle.

If multiple people collaborated on the branch, you can see who they all were and how much each person contributed.

The number of commits on the merged topic branch gives you a rough idea about how much was changed.

The time range of the commits can provide useful context.

You can easily cherry-pick a specific change made onto a different branch (e.g., cherry-pick the minimal change needed to fix a bug onto a release branch).

There is one disadvantage I can think of: It may be hard to configure your software development tools to only follow the first-parent path and ignore all of those intermediate commits. For example, there is no --first-parent argument to git bisect. Also, I'm not familiar enough with Jenkins to know how easy it is to configure it to prioritize building and testing the first-parent path over all the other commits.