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):
branch general-fixes from master
cherry-pick "general fix" commits from feature-x
rebase feature-x onto general-fixes to verify things
merge general-fixes into master
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:
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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):
general-fixesfrommasterfeature-xfeature-xontogeneral-fixesto verify thingsgeneral-fixesintomasterfeature-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:
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 resetapproach 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 resetapproach I believe this will not be necessary anymore.