DEV Community

Discussion on: Git Organized: A Better Git Flow

Collapse
zalithka profile image
Andre Greeff

nice write up, it is a lot of reading though... lol. I follow a very similar process myself, adhering to the traditional "commit small, commit often" concept as closely as possible.

if I end up resolving unrelated bugs while working on a feature branch, I normally do the following (assuming a "single main branch" workflow, using a "fast-forward merge only" strategy with no merge commits):

  1. branch general-fixes from master
  2. cherry-pick "general fix" commits from feature-x
  3. rebase feature-x onto general-fixes to verify things
  4. merge general-fixes into master
  5. continue with feature-x..

quite often this happens multiple times a day, so it doesn't take long for it to become habitual.


..and I apologise ahead of time, but I just need to rant a little bit here: I really, really, really wish I could work with people that understand and appreciate Git. :(

one of my work colleagues is of the opinion that rebasing branches after cherry picking commits actually creates duplicate commits.. but he also manually synchronises entire folders of code between multiple projects, and refuses to use any code formatting tools.. so, meh. :insert_epic_facepalm:

Collapse
elisboa profile image
Eduardo Lisboa

I really understand your rant, since I always went through this. But I try to advocate for git and better git flows as much as possible.
I love to commit often, too. I am a branch addict and create sub branches for branches I'm working on, only to (try to) better organize my job. But this git reset approach really seems to work for me. Can't wait to try this soon!

As a branch addict, I always create WIP branches only to check them out later, some specific file that worked and so on. Again, with this git reset approach I believe this will not be necessary anymore.