StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The second approach doesn't have to have a lot of ugly and unnecessary merges and commits. This is what I prefer to do:</p> <ol> <li>create a new topic branch</li> <li>make a bunch of commits</li> <li>just before merging back to the parent branch, clean up the commits: <ul> <li>rebase onto the latest version of the parent branch</li> <li>squash typo fix commits</li> <li>split commits doing multiple things at once into separate commits</li> <li>reorder the commits to make it easier for a reviewer to understand the sequence of changes</li> <li>etc.</li> </ul></li> <li>merge with <code>--no-ff</code> into the parent branch</li> </ol> <p>The above steps result in a history that looks like this:</p> <pre><code>* 354b644 Merge branch 'topic3' |\ | * 54527e0 remove foo now that it is no longer used | * 1ef3dad stop linking against foo | * 7dfc7e5 wrap lines longer than 80 characters, no other changes | * b45fbcf delete end-of-line whitespace, fix indendataion |/ * db13612 Merge branch 'topic2' |\ | * 961eebf unbreak build by adding a missing semicolon |/ * a5b6b16 Merge branch 'topic1' |\ ... (more history not shown) </code></pre> <p>The above graph has all the same advantages of approach #1:</p> <ul> <li><p>You can use the <code>--first-parent</code> argument to <code>git log</code> to get a concise summary that resembles what you would get with approach #1:</p> <pre><code>* 354b644 Merge branch 'topic3' * db13612 Merge branch 'topic2' * a5b6b16 Merge branch 'topic1' ... (more history not shown) </code></pre></li> <li>You can still easily examine the entirety of changes made in a topic branch. For example, <code>git diff 354b644^..354b644</code> will show you what was changed for topic #3.</li> </ul> <p>But you get benefits that approach #1 can't give you:</p> <ul> <li>The history is <strong>much</strong> easier to review: commits <code>b45fbcf</code> and <code>7dfc7e5</code> (for the <code>topic3</code> 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.</li> <li>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).</li> <li>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.</li> <li>If multiple people collaborated on the branch, you can see who they all were and how much each person contributed.</li> <li>The number of commits on the merged topic branch gives you a rough idea about how much was changed.</li> <li>The time range of the commits can provide useful context.</li> <li>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).</li> </ul> <p>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, <a href="https://stackoverflow.com/q/5638211/712605">there is no <code>--first-parent</code> argument to <code>git bisect</code></a>. 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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload