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

Git

3278 readers
4 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
Ategon@programming.dev
jnovinger@programming.dev
canpolat@programming.dev
25
What's your opinion on git rebase vs git merge? (lemmy.sdf.org)
submitted 2 years ago* (last edited 2 years ago) by provisional@lemmy.sdf.org to c/git@programming.dev
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
[–] spartanatreyu@programming.dev 26 points 2 years ago (3 children)

It's not rebase vs merge, it's rebase AND merge.

Commit your changes into logical commits as you go.

Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.

Use rebase to:

  • Swap commits so that related changes are together
  • Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
  • Drop any useless commits that you just end up reverting later
  • Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.

Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.

[–] epchris@programming.dev 6 points 2 years ago

love this approach and it's what I usually use. I also don't rebase after opening a PR (GitHub) because force pushing ruins reviewer context in the GH UI. so after the PR is open I merge main/master in instead of rebasing.

load more comments (2 replies)