DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Discussion on: Git Organized: A Better Git Flow

Collapse
jdhines profile image
orangehat

My first thought too was "why not rebase?" but, and maybe I'm just doing it wrong, I've always had trouble if I want to change a commit, or if I want to put only some of the changes from one commit into another. I like this reset approach as an option at least to get my commit history the way I want.

Collapse
pcjmfranken profile image
Peter Franken • Edited on

Absolutely do what works best for you. As long as your pushed changes fit the branching strategy you're golden. Well, and not waste too much time putting back together the history you *just fixed* of course πŸ˜‰

I'll try to get you an example sometime next week. You might not sell on it, but at least you'll know how it works!

Collapse
anniesexton profile image
Annie Sexton Author

Author here – hello! πŸ‘‹

I didn't mention it the article, but I also use rebasing quite often! Especially to keep my branch up to date. You can also use interactive rebasing to achieve the same goal, it really just comes down to what works for you. Using rebase -i is helpful if you know that at least some of your commits can be left in tact, or don't need as much modifying. In fact, once you get comfortable enough with it, using rebase -i can be even faster than doing a full reset, because you're not having to re-write as many commits. πŸ’ͺ

That said, staying focused on development while also thinking about "Wait - should this work be in a separate commit?" requires some mental task-switching, which can be taxing on your working memory if you have an overactive neurodivergent brain like I do. I've found that the method described in the article frees up so much mental bandwidth because I can hyperfocus on one goal at a time, be that writing code, or organizing my commits.

If the goal is ultimately to have a sequence of clear, concise commits that are easy to review (or revert), then it really doesn't matter which method you choose. :)

Collapse
jessekphillips profile image
Jesse Phillips

If you start modifying commits during a rebase (which you likely will), then you run into the potential for conflicts, especially if you are reordering.

If you get into such situations and don't understand

$ git rebase --abort

Take smaller steps during the rebase. Move one commit (only a few commits back). Make only one change. Then rebase again for more changes.

Thread Thread
pcjmfranken profile image
Peter Franken

Telling people what to do because I am right.

Your bio checks out, good advice to take an incremental approach here!

Using fixup and amend commits won't eliminate these situations completely, but they'll definitely help towards keeping track of the commits without having to dive into their individual diffs.