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

Git

2938 readers
1 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 2 years ago
MODERATORS
 

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] 1 points 2 years ago* (last edited 2 years ago)

I use rebase only to clean up some commit messages, squash commits, etc. - essentially to clean up feature branches I wrote. But never rebase to 'move' my branch as if it originated from a different commit, because I don't know necessarily know what changes have been introduced on the other branch (typically main/master), so rebasing on that would leave my commits in a state that they were never tested in, possibly broken / with unintended sideeffects. If I need changes from the other (main) branch in my feature branch (because of feature dependencies, or to fix merge conflicts), I merge it into my branch and can be sure that the commits created before that merge still behave the way they did before that merge - because they were not changed; this can't be said for rebasing.