7 ms·
> but you don't throw away the feature branch history Once a feature is merged, how is the history of a feature branch helpful? Since I do not see/understand
by tapan_k 10y ago
> but you don't throw away the feature branch history
Once a feature is merged, how is the history of a feature branch helpful?
Since I do not see/understand the benefits of retaining feature branch history, my preference is to squash commit and merge. Perhaps, this is a result of my habits that I carry from the ClearCase days, but would love to hear the downsides of this approach.
- JimDabell 10y agoWell given that we're talking specifically about reverting the merge when something goes awry, firstly you want that history preserved so that you can re-start work on it, potentially without pulling in all of the changes in one go; and secondly so that you can determine the precise point at which the problem happened. Consider the difference between: * Well we need to revert this because it's causing problems, but now we've got one massive chunk of several day's work to pick through. …vs: * Well we need to revert this, but we can see that the problem was specifically commit xzy, so let's yank that, do it a different way, and merge the result. Aside from that, it can be very useful to see the individual steps in implementing a feature for a variety of reasons. Given that a --no-ff merge achieves everything you are aiming for with the squash, why wouldn't you pick the more flexible approach?
- 32bitkid 10y ago`git blame` and `git biscet`