Hacker News new | ask | show | jobs
by TeamMCS 4795 days ago
I'm not a fan of rebasing as it makes for a confusing git history when you are working with Gitflow. I find it much nicer to see the merge bubbles which indicate how features were introduced into a release. Flattening the history makes it tricky to get a clean overview and pick precisely when certain actions were performed.

-imo
2 comments
mzl 4795 days ago
When merging a rebased feature branch, make sure to use merge --no-ff so that a merge commit is introduced even though fast forwarding could be done.
link
frou_dh 4795 days ago
Yeah. I like that and the approach is outlined in this short guide I found:

http://williamdurand.fr/2012/01/17/my-git-branching-model/

i.e. before merging a feature branch, always rebase it on the tip of the integration branch, then merge it in with --no-ff to record an explicit merge commit on the integration branch, even though a fast-forward is possible. This gets you the temporal straightforwardness of rebase while preserving the fact that there WERE feature branches and their commits are partitioned in history.

link
khasinski 4794 days ago
You nailed it. Commit history is for people to read.

Check out git flow, you might like it. It could add even more structure and readability to your codebase history.

link
frou_dh 4794 days ago
Do you agree with my edit? I'm no git pro, so still trying to get things straight in my mind.
link
khasinski 4794 days ago
Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this branch or remove the entire feature.
link
lotyrin 4794 days ago
In this debate I am a strong rebase advocate (though more than that I'm for very carefuly and actively avoiding there being remote head contention - for instance by having feature branches with clear owners, or having a PR and code-review based integration style), but when merging features in these should definitely be (--no-ff) merges.

It's not a dichotomy, it's about clear semantics - what a feature branch is (clearly defined linear progress off of an upstream) what a merge means (integrating that progress and vetting the result).

I feel like this echoes the tables vs divs debate: use a table for tabular data and position containers for layout.

In both cases, there are some fringes who argue that you should do one or the other for both use cases - semantics be damned. Git is newer so the fringes are just bigger.

link