4 ms·

Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase. Hint: “g

by hedora 3y ago

Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase. Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.

kingdomforgit 3y ago
> Most people start where you are I've used almost every source control system known to humans the past several decades and git for over a decade. I've heard the git rebase preachers. I tried to get onboard with rebase. All who read, avoid rebase at all costs at all times, always.
- mixmastamyk 3y ago
  A bit overstated but yes. Merge squash works every time. Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.
  - avgcorrection 3y ago
    > Merge squash works every time. Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).
  - turtles3 3y ago
    > Merge squash works every time. Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.) Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.
    - mixmastamyk 3y ago
      Never did that exactly. Think I've either, started a new branch from the waiting one or, started a new branch from the main and then pulled from the older feature branch. Have no recollection of any problems, but it is rare enough to not have tried it recently.
- avgcorrection 3y ago
  Merge can always be used and rebase is a good tool for certain circumstances. And some people argue for using only one over the other. Your preaching is contentless.
rizzaxc 3y ago
can you explain? to me SOP is feature branch, work there, commit occasionally, then when it's good review, squash and merge (99% of the times done on remote). the history is clean with the ticket ID attached to the final merge commit (as the feature branch is treated as atomic)

by hedora 3y ago

kingdomforgit 3y ago

> Most people start where you are I've used almost every source control system known to humans the past several decades and git for over a decade. I've heard the git rebase preachers. I tried to get onboard with rebase. All who read, avoid rebase at all costs at all times, always.

mixmastamyk 3y ago
A bit overstated but yes. Merge squash works every time. Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.
- avgcorrection 3y ago
  > Merge squash works every time. Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).
- turtles3 3y ago
  > Merge squash works every time. Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.) Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.
  - mixmastamyk 3y ago
    Never did that exactly. Think I've either, started a new branch from the waiting one or, started a new branch from the main and then pulled from the older feature branch. Have no recollection of any problems, but it is rare enough to not have tried it recently.
avgcorrection 3y ago
Merge can always be used and rebase is a good tool for certain circumstances. And some people argue for using only one over the other. Your preaching is contentless.

rizzaxc 3y ago

can you explain? to me SOP is feature branch, work there, commit occasionally, then when it's good review, squash and merge (99% of the times done on remote). the history is clean with the ticket ID attached to the final merge commit (as the feature branch is treated as atomic)