this post was submitted on 01 Mar 2024
19 points (100.0% liked)

Git

2860 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 1 year ago
MODERATORS
Ategon
canpolat
jnovinger
19
Git Battle: YOLO Mode vs. Clean History (hankadev.com)
submitted 7 months ago by canpolat to c/git
11 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] RonSijm 1 points 7 months ago (2 children)

I've never really needed to use rebase, but my workflow is probably kinda weird:

  • I just start programming from the dev branch
  • At some point once I have stuff to commit, I do git checkout -b new_feature_branch, and so move my changes to a different branch
  • I commit a bunch of stuff into that branch, usually just with commit messages of "working on new_feature"
  • Once I'm done, and I have - lets say - 10 commits in that branch:
  • I do git reset head~10 meaning all 10 commits are reverted into staged changes
  • I now do 1 new commit of all the changes, with a decent commit message to explain the new feature
  • I git push -f the new commit back to origin (of feature branch)
  • I PR the feature branch to dev, and merge it

It works pretty well for me, but I was told its weird, and I should rebase instead

[–] zygo_histo_morpheus 1 points 7 months ago

The benefit with rebase is if you want to have maybe 4 commits insteadd of 10. When reviewing a large pr, I find that it's helpfull if it's broken up into a couple of coherent commits so that I can review it commit by commit. It's easier to follow the logic of why something is being changed if it's associated with a specific commit.

Sometimes squashing the entire commit is the right choice, in which case you can do what you're doing or use some built in feature to do that.

[–] Piatro 1 points 7 months ago

You do you. People generally discourage rebase because it rewrites history but that's what you're doing anyway. You can achieve the same result with revase --interactive and following the instructions to squash all your in progress commits into a single commit. That way you don't have to figure out how many commits between your in progress and dev(for your reset command) as the rebase will handle it for you.