Git Workflow Basics

Re:Git Workflow Basics by stormbrew on Wednesday August 17, 2016 @10:10AM (#12304789)

> This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash

Until the original branch is deleted and the refs are garbage collected, anyways.

It seems strange to me to advocate for squash merging on a premise of not losing history. A squash merge is a rebase.

[ Parent | on HN ]

Re:Git Workflow Basics by steveklabnik on Wednesday August 17, 2016 @10:46AM (#12305085)

  > A squash merge is a rebase.

Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.

[ Parent | on HN ]

Re:Git Workflow Basics by stormbrew on Wednesday August 17, 2016 @10:53AM (#12305126)

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch.

But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.

[ Parent | on HN ]

Re:Git Workflow Basics by steveklabnik on Wednesday August 17, 2016 @11:06AM (#12305236)

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this:

    C -> D -> E
   /
  A -> B

then you "squash merge"

    S------
   /       \
  A -> B -> F

where S is C + D + E.

Whereas a rebase + (now fast-forward) merge would be

  A -> B -> C' -> D' -> E'

and, if squashed during rebase -i or by some other means

  A -> B -> S

It seems you're saying a "squash merge" is the last one, I thought it was the second one.

[ Parent | on HN ]

Re:Git Workflow Basics by tomstuart on Wednesday August 17, 2016 @11:27AM (#12305393)

That’s right. `git merge --squash` doesn’t even make a commit, it just updates the working tree and index to look like the post-merge contents — it’s then up to you to actually commit. So yeah, you don’t even end up with a merge commit.

[ Parent | on HN ]

Re:Git Workflow Basics by steveklabnik on Wednesday August 17, 2016 @11:35AM (#12305456)

Ah ha! TIL. Thank you!

(One thing I really love about git is that it's a tool I use extremely often (it's something like, 20% of the commands I run in my terminal), yet I learn something new and useful all the time.)

[ Parent | on HN ]

Re:Git Workflow Basics by stormbrew on Wednesday August 17, 2016 @11:26AM (#12305385)

I'm sure someone out there does it like that (the joy and pain of git being there's a million ways of doing things), but the name I think is derived from the idea that you're replacing a merge commit with a squash of the disjoint parent, rather than a merge of a squash.

Also it's entirely possible I'm wrong, I'm a fan of merge bubbles (sometimes rebased for clarity), and avoid large squashes in general, so maybe I just don't understand how people do it. I don't know why you'd bother to keep both a merge and squash commit around, though.

[ Parent | on HN ]

Re:Git Workflow Basics by steveklabnik on Wednesday August 17, 2016 @11:31AM (#12305423)

No, I think you're right; take a look at the graphs on https://github.com/blog/2141-squash-your-commits for example.

I don't know why you'd want to do it that way either! But I also don't understand why you'd want to "never rebase", so when it comes to git, I assume that someone has reasons for doing all kinds of things I don't understand.

[ Parent | on HN ]