4 ms·

I was guilty of merge hell until I learned about rebase. I think it's a natural instinct to want to protect your production environment so I'm sure others have

I was guilty of merge hell until I learned about rebase. I think it's a natural instinct to want to protect your production environment so I'm sure others have made the same mistake as I did. Main is my default branch, I don't want anything pushed into the default branch to result in a deployment to production. So naturally I create a new branch called production. The relationship makes sense to me because we develop in main, might even deploy to staging from main, but it's not until we feel we're ready that we merge main with production. And to a user of git this requires a manual step where you explicitly specify the word production, git checkout production. But that resulted in merge hell until I learned I could just rebase main onto production. And the command structure is even exactly the same, standing in production branch I either do git merge main, or git rebase main. This comment was a message to my younger self.

01HNNWZ0MV43FF 2y ago
Your comment says 6 minutes ago but when I go to reply it says three days... And I do remember reading it three days ago Does hacker News fudge timestamps on comments when it boosts a post?
Uvix 2y ago
Production shouldn't have its own branch - it shouldn't even be a new build at all. The same binaries that were deployed to staging should be redeployed to production once you approved. Otherwise, your "staging" environment has the wrong name... and the testing there doesn't represent what goes to production.
- toast0 2y ago
  In a system with production branches and staging, you build for staging from the production branch. When you're in the release process, the branch won't match what's currently deployed, but that's ok. The point of a production branch is not to indicate what is on production at this instant, but to be a record of what was deployed to production or at least was intended to be, for changes that get canceled before deployment.
  - Uvix 2y ago
    Building for staging from the production branch would be fine. Grandparent explicitly said they build for staging from the dev branch, though.
    - toast0 2y ago
      Oh yeah. I missed that. Sounds like they use their staging for dev work too then. Which is like ok, but confusing.
- jakjak123 2y ago
  Good point. That is my conclusion as well, its been a while since I worked on deployments, but that is how we set up. Deploying is just a different pipeline on main branch that runs same exact artifact build in production
- hiddew 2y ago
  Why not? A branch is a pointer to a commit, so the commit built for staging can be the same binary that will be deployed to production, if the production branch is updated to point to the same commit as staging was pointing to. No rebuild necessary because it is the same commit.
  - Uvix 2y ago
    If you have fully reproducible builds, and if it's from the same commit, then it's probably okay. With multiple branches in play, and staging built from a different branch than production, the latter doesn't hold.
jakjak123 2y ago
Its not a hill im dying on, but when you rebase the default branch, its gonna create conflicts for every single other team member. Its annoying to cause so much noise for every team member. Now I run with auto.rebase set, but that is not the default. Ymmv.
pandemic_region 2y ago
> But that resulted in merge hell until I learned I could just rebase main onto production. Did you mean rebase production onto main rather? Or do I have my branches and trees mixed up.
- dools 2y ago
  I think the commands are: git checkout production git rebase main that gets everything from main into production.
  - jakjak123 2y ago
    This would rewrite the history for production. Not what you want to do
    - LegionMammal978 2y ago
      The point, as I understand it, is that production has no meaningful history separate from main's history: it acts as a bare pointer, and rebasing it just fast-forwards it to later points in main's history.
  - pandemic_region 2y ago
    Yes, but rebase is like rebranch. So you take a branch from a tree, and plant it on top of a new tree. So, you rebranch (rebase) production branch on top of the main branch. git rebase (current branch onto) main
GrantMoyer 2y ago
In my experience, if there are no conflicts to resolve, then merge and rebase have near equivalent UX. Just a single command and git handles the rest. However, if there are conflicts, I've always found them to be far easier to resolve during a merge than a rebase. That's not to say it's always easy, but at least with merge you only need to resolve them once. With rebase, you resolve the conflict, then have to resolve it again when git tries to apply the next change, and so on. Sometimes you even need to resolve conflicts bacwards if you're reordering commits. Much of this can be mitigated with git rerere, but if you're averse to merge, you probably don't want to learn about rerere either.
- m4lvin 2y ago
  Thanks for making me look up rerere which I first thought would be a typo but actually seems like a really useful thing :-) https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
pjc50 2y ago
As a promoter of the rebase faction .. that's one case where I think "merge" is correct. Since you're not changing production without going through main (I hope), every merge should just go straight through ("fast forward"?) git checkout production git pull --ff-only main production git push (at which point CI auto-deploys 'production') (edit: have you got "rebase main onto production" the wrong way round?)
- GrantMoyer 2y ago
  I think they must have been cherry picking changes into production. Git merge might choke on the duplicate changes, but git rebase will usually see the change from each cherry pick is already applied and skip it.

01HNNWZ0MV43FF 2y ago

Your comment says 6 minutes ago but when I go to reply it says three days... And I do remember reading it three days ago Does hacker News fudge timestamps on comments when it boosts a post?

Uvix 2y ago

Production shouldn't have its own branch - it shouldn't even be a new build at all. The same binaries that were deployed to staging should be redeployed to production once you approved. Otherwise, your "staging" environment has the wrong name... and the testing there doesn't represent what goes to production.

toast0 2y ago
In a system with production branches and staging, you build for staging from the production branch. When you're in the release process, the branch won't match what's currently deployed, but that's ok. The point of a production branch is not to indicate what is on production at this instant, but to be a record of what was deployed to production or at least was intended to be, for changes that get canceled before deployment.
- Uvix 2y ago
  Building for staging from the production branch would be fine. Grandparent explicitly said they build for staging from the dev branch, though.
  - toast0 2y ago
    Oh yeah. I missed that. Sounds like they use their staging for dev work too then. Which is like ok, but confusing.
jakjak123 2y ago
Good point. That is my conclusion as well, its been a while since I worked on deployments, but that is how we set up. Deploying is just a different pipeline on main branch that runs same exact artifact build in production
hiddew 2y ago
Why not? A branch is a pointer to a commit, so the commit built for staging can be the same binary that will be deployed to production, if the production branch is updated to point to the same commit as staging was pointing to. No rebuild necessary because it is the same commit.
- Uvix 2y ago
  If you have fully reproducible builds, and if it's from the same commit, then it's probably okay. With multiple branches in play, and staging built from a different branch than production, the latter doesn't hold.

jakjak123 2y ago

Its not a hill im dying on, but when you rebase the default branch, its gonna create conflicts for every single other team member. Its annoying to cause so much noise for every team member. Now I run with auto.rebase set, but that is not the default. Ymmv.

pandemic_region 2y ago

> But that resulted in merge hell until I learned I could just rebase main onto production. Did you mean rebase production onto main rather? Or do I have my branches and trees mixed up.

dools 2y ago
I think the commands are: git checkout production git rebase main that gets everything from main into production.
- jakjak123 2y ago
  This would rewrite the history for production. Not what you want to do
  - LegionMammal978 2y ago
    The point, as I understand it, is that production has no meaningful history separate from main's history: it acts as a bare pointer, and rebasing it just fast-forwards it to later points in main's history.
- pandemic_region 2y ago
  Yes, but rebase is like rebranch. So you take a branch from a tree, and plant it on top of a new tree. So, you rebranch (rebase) production branch on top of the main branch. git rebase (current branch onto) main

GrantMoyer 2y ago

In my experience, if there are no conflicts to resolve, then merge and rebase have near equivalent UX. Just a single command and git handles the rest. However, if there are conflicts, I've always found them to be far easier to resolve during a merge than a rebase. That's not to say it's always easy, but at least with merge you only need to resolve them once. With rebase, you resolve the conflict, then have to resolve it again when git tries to apply the next change, and so on. Sometimes you even need to resolve conflicts bacwards if you're reordering commits. Much of this can be mitigated with git rerere, but if you're averse to merge, you probably don't want to learn about rerere either.

m4lvin 2y ago
Thanks for making me look up rerere which I first thought would be a typo but actually seems like a really useful thing :-) https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere

pjc50 2y ago

As a promoter of the rebase faction .. that's one case where I think "merge" is correct. Since you're not changing production without going through main (I hope), every merge should just go straight through ("fast forward"?) git checkout production git pull --ff-only main production git push (at which point CI auto-deploys 'production') (edit: have you got "rebase main onto production" the wrong way round?)

GrantMoyer 2y ago
I think they must have been cherry picking changes into production. Git merge might choke on the duplicate changes, but git rebase will usually see the change from each cherry pick is already applied and skip it.