Hacker News Reader

Comment by Buttons840 | Hacker News Reader

> If you pursue gitflow, you’re gonna have to give up rebasing. Remember, rebasing does away with the merge commit — the point where you can see two branches coming together.

I disagree with this. You can rebase your branch and then do a "no fast forward" merge. You'll end up with something like:

    * Merge commit
    |\
    | * My branch commit 3
    | * My branch commit 2
    | * My branch commit 1
    |/
    * Base

Notice I have not "done away with the merge commit".

When you rebase your branch on top of "Base", and then try to merge, git will by default do a fast-forward merge, but you can prevent it from doing so.

It is as though you created your branch, did your work, and then merged it back in so quickly that no other branches were created in the meantime, and if we ignore what I personally did on only my own computer, then I am still following Gitflow.

View on HN

I dont even get why people rebase for a merge. I never did this and I get the entire history not a distorted version of it. On top of which I can go back between commits and even revert a very specific commit.

Reality is everyone prefers to organize code differently I prefer to have all the commit history. It is more meaningful to see all the files involved in a single stage of a commit than potentially multiple changes in one PR all blended together.

> I dont even get why people rebase for a merge. I never did this and I get the entire history not a distorted version of it.

Except that the history is disorganized and is not organized into distinct patches that only do one thing where each patch has a well written commit message.

People seem to want to treat the VCS as a back up system rather than a system to keep track of changes. Technically you could get the former by configuring your editor/IDE to generate a commit every time you save the file, but that in itself would lead to a very large history that wouldn't be useful (meaning commands like git blame would be next to useless).

> Except that the history is disorganized and is not organized into distinct patches that only do one thing where each patch has a well written commit message.

This seems like a separate problem... I know where commits come from cause the first thing I write on mine is the JIRA / Trac or other related ticket number / code. It is pretty obvious where a commit originated from if you do this. The rest is useful meaningful information. If somebody writes useless commit messages, that's on them and the rest of the team for letting them do so.

I hate rebases because they create multiple hashes for the same logical commit. It confuses the crap out of me sometimes. Also, they tend to involve more manual processing, and thus human error, then merges.

> I hate rebases because they create multiple hashes for the same logical commit

Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases.

> Also, they tend to involve more manual processing, and thus human error, then merges.

Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example:

  git diff @{u}..

And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch.

[1] https://git-scm.com/docs/git-range-diff

This. I've had to spend time fixing history after a Jr engineer did a bad rebase. After a few episodes of that I decided I had to either stop hiring Jr engineers, have them always supervised by a Sr engineer, or stop rebasing.

I stopped rebasing.

You'd be better off blaming the force push rather than the rebase. A rebase I do on my computer will not affect you unless I force push.

I think it's completely reasonable to ask all developers to get a second opinion before force pushing.

> I've had to spend time fixing history after a Jr engineer did a bad rebase.

I tell people to run git log -p --reverse origin/master.. on the rebased branch and check that everything works before they push up their branch to the remote. I also tell them to run git rebase --exec "linting-command" --exec "unit-test-command" --exec "integration-test-command" and make sure that tests pass for every single commit. If they don't, then they spend time fixing it until they do.

Yeah, this is exactly right. I put up something on Github awhile back that compares different approaches in more detail, if anyone's interested: https://github.com/jiaweihli/git-workflow-strategies-example

Reply on news.ycombinator.com