You need to have 2 implementation of bug fixing. As soon as you start changing the feature, it's highly unlikely the bug fix for old code could be applied also to the branch. This is only true in very simple example, or where bug needs fixing in very obscure part of the code, untouched in the feature branch. Just don't forget to run "Update submodules" after switching What's good in submodules - you can always jump to any previous state including all deps and it will be buildable. I also came to a rule to commit changes in submodules into separate commits (without changes to parent project) just to separate things. This requires some self-discipline especially if you periodically modify these libs right from a parent project - this results in lots of fun when you have N different updates inside N different projects and got to merge them all into main repo and then update all these N submodules. * When a feature is ready, I rebase onto current HEAD and do clean merge. More frequently I utilize cherry-picking which is very nice tool of distributing commits. * Merge commits from master to feature branch (this is what all should do but I find multiple merges too confusing in history so I try to avoid them). * If a branch lasts for a while, sometimes I rebase it onto current HEAD - or. * If they are finished quickly (no commits to master happen after starting feature branch), I merge into master without fast-forward to get nice-looking curve in history. Somewhat big features (requiring significant changes in multiple files) go to feature branches. Small changes fitting into single commit go directly to master I'm the only dev of my projects so I adopted some kind of Git workflow:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |