You can display version history on github in Insights/Network.
tl;dr
I don't agree with fast-forward merges aka rebase with no merge. For me, a branch is a separated idea and master is a collection of references to those ideas.
long
I understand that a flat (rebase) git-flow with history manipulation makes sense for usage with git in bash where the commit history is displayed in a linear fashion. However, I don't agree that this approach is better, compared to a two dimensional (merge) git-flow in a visual git. Also changing the Feature's commit history even slightly makes it difficult, for a reviewer, to understand your mind flow and reasoning.
I was on a project, where everyone squashed their branches to a single commit before rebasing onto a master and I can tell you, you don't want to review this.
Compare with this (BTW, you can always use --first-parent to hide branch commits.)
Another issue is fast-foward merging. Many people are afraid of merge commits, and without a good visualization merge commits just complicate things, so they do fast-forward merges. Yeah, it gets rid of the merge commits, but since branches are usually separate ideas, the merge commits are like the separation of paragraphs. Yeah, you could write a book without paragraphs, but it will suck. Don't do that to your repositories, or they will suck too.
Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
Excellent points! I am actually in favor of merge commits, but my teams current workflow does not use them. It's something that I would like to try and get added into our git workflow, but we'll see ¯_(ツ)_/¯
The quote from etcwilde is a great example! Also thanks for pointing out where the visualization was at on gitub, just kinda wish it had a great commit range on it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You can display version history on github in Insights/Network.
tl;dr
I don't agree with fast-forward merges aka rebase with no merge. For me, a branch is a separated idea and master is a collection of references to those ideas.
long
I understand that a flat (rebase) git-flow with history manipulation makes sense for usage with git in bash where the commit history is displayed in a linear fashion. However, I don't agree that this approach is better, compared to a two dimensional (merge) git-flow in a visual git. Also changing the Feature's commit history even slightly makes it difficult, for a reviewer, to understand your mind flow and reasoning.
I was on a project, where everyone squashed their branches to a single commit before rebasing onto a master and I can tell you, you don't want to review this.
Compare with this
(BTW, you can always use
--first-parentto hide branch commits.)An excellent quote from etcwilde
Excellent points! I am actually in favor of merge commits, but my teams current workflow does not use them. It's something that I would like to try and get added into our git workflow, but we'll see ¯_(ツ)_/¯
The quote from etcwilde is a great example! Also thanks for pointing out where the visualization was at on gitub, just kinda wish it had a great commit range on it.