this post was submitted on 25 Jun 2023
31 points (100.0% liked)

Git

2632 readers
14 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
31
What's your opinion on git rebase vs git merge? (lemmy.sdf.org)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
27 comments fedilink hide all child comments
 

I basically only use git merge like Theo from T3 stack. git rebase rewrites your commit history, so I feel there's too much risk to rewriting something you didn't intend to. With merge, every commit is a real state the code was in.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 16 points 1 year ago (2 children)

It's correct that rebase rewrites history, but it's important to identify when it's not acceptable. If you are working on a branch that is shared by others (typically main), you should never use rebase. But it's an acceptable practice when used properly. I use rebase on my feature branches whenever necessary. If it fell behind the main branch I do git fetch followed by git rebase origin/main, resolve the merge conflicts and keep coding. I also use interactive rebase when I need to tidy things up before merging the feature branch to main.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago)

That’s what I do as well. Where I work, it’s common to have branches that take long to be ready for merge (because of bureaucracy), but because of many teams working on the same app, the upstream branch changes quite often.

I see some coworkers make just a few changes and a lot of times reverting stuff so the diff might be 1 line in the end, but the commit history is a mess of 30 commits of merges, triggering pipelines and undone stuff that was discarded later.

Then sometimes they have to find where they changed something they broke their feature and it’s a hell time to find what commit actually has any relevance for the final result.

[–] [email protected] 4 points 1 year ago

Rebasing is fine for any unpushed commits including ones on shared branches.