Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Ideally the project would be so modular that there would be so few conflicts from different features that it's not a problem
-
@electrineer I can solve these conflicts when rebasing but what about doing hotfixes for these features in the future?
Should I revert merged feature branches then after applying hotfixes merge them again? -
@Marks7e Other feature branches are 10-20 commits ahead from develop bcs juniors work on them. Maybe if they would make branches from develop for their features and then just squash merge their stuff from old feature branches, then I would have all feature branches ready for mergint with only 1 commit and then work with chery pick?
-
nibor48775yMaybe merge up, so merge develop branch to feature 1, resolve conflicts, then merge feature 1 down to develop. Repeat for feature 2, etc.
Once branches are merged into develop, I like to delete those. Then for hotfixes create a new branch. -
Marks7e3275y@zemaitis That's a good approach.
But actually, you can "Cherry-pick" a range of commits. Try to "Cherry-pick" the range of commits from one jr's feature/hotfix branch and commit to development branch (or a clone of development branch, just in case). Then, repeate the process for each feature/hotfix branch you need.
Hope this post will help you: https://medium.com/@sinhanurag/... -
@nibor what is better, to merge most recent develop into feature and after resolving conflicts merge feature to develop, or is it better to just switch to most recent develop, pull all changes from feature and after resolving all conflicts merge them to feature and then just merge new feature to develop?
-
korrat6345yFor hotfixing, you can revert the merge commit introducing the bug in develop. Then branch of from develop and revert the revert. Then you fix the bug. Before merging, you rebase on develop, then you merge into develop
-
Something is really wrong with your workflow if you have multiple feature branches that are touching the same modules all the time. Even if git cleanly merged the work, would you be sure it worked as expected?
If I was working on the RARE case where two feature branches had conflicts, I would merge one, rebase the second, fix conflicts and then merge that one.
Not even sure what you mean by "hotfixes for previously merged branches". Hotfixes don't apply to branches, they apply to releases. Apply your hotfix to the release and be on your way. -
@zemaitis merge back in the features right away and after a merge to develop.
I personally always merge develop I to my branch after an commit. Last time I had a conflict was 3 months ago.
Related Rants
How do you deal with situation when u need to merge multiple feature branches to develop branch? All feature branches have develop branch as base. So as soon as one feature is merged to develop then there will be contlicts in other feature branches.
Should I merge first feature branch to develop, then rebase feature2 branch on most recent develop and then merge the rebased feature2 branch to most recent develop and continue like that?
What if later I need to do hotfixes for previously merged branches? Should I revert them then rebase them on most recent develop and once again merge it to develop? Or should I just make small commits for fixes.
rant
rants
question