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

Git

2875 readers
15 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]
2
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]
4 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] 0 points 1 year ago (1 children)

I rebase my dev branches on main to get rid of garbage commit messages due to me being lazy.

Squash and merge PRs into main, no merge commits allowed.

I think there are reasonable arguments for allowing rebase and merge to main, but it often doesn't apply for me.

Merge commits in main will break a lot of out of the box GitOps tools.

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

I'm okay with squashing consecutive silly commits before a merge, but having worked on a codebase that used the policy described above for a decade before I got there, I really, really hate it. Git blame and other history inspection tools are nearly totally useless. I'll have access to commit messages, but when things have been shuffled around feature branches for a while, they end up concatenated into mega commits with little hope of figuring out why anyone did anything or what they were thinking when they did it. Some of this might be mitigated if stale branches weren't deleted, but people don't like stale branches.

If there are genuinely Git tools that can't handle merge commits in <current year>, I'd be surprised if they didn't have Fisher Price or Hasbro written on the side.