![]() ![]() With merges, you are sure that all the commits has been reported to the 'dev' branch.GIT Tutorial By KnowledgeHut 1. That could work for 1 or 2 commits but is not viable in all situations. When you do cherrypicking, it's hard to find if each commits are in the 2 branches. Because if you do the development in 'dev' that could have changed a lot since 'release' was done, you could have merge conflicts that risks of introducing a bug. So you should either create a branch to do the fix from the 'release' branch (and merge it in 'release' and 'dev') or fix in 'release' directly and merge in 'dev'. You should fix in the branch that as moved the less and which is the more like the production commit. And, more important, for a given commit/fix, you could see easily which branches contains it. You could better understand the history seeing the graph. To track fixes, that's a lot more efficient to do merges rather than cherrypicking. My question is, are there more compelling reasons to use a get branching strategy? I've searched quite a bit for "Cherry Picking branching strategy" and other variants and haven't come up with anyone suggesting it, so I'm hoping I'm missing something major here. however, having made the transition from TFS to GIT myself years ago, I can see how complex things look and that there will be many mistakes before it becomes second nature to everyone. Also, I like Git, though I'm no expert, but the git branching strategy makes sense to me. but I can see how others it might especially at higher risk of forgetting something in a Hotfix branch by not merging it back into Master. Fundamentally the idea of not being 100% positive the code going to prod is what you tested in dev irks me to no end. Problem is, I don't have a response to that. So, another developer on the team agrees that the Cherry-pick branching strategy has a few issues but argues it's simplicity should mean that changes not making it back to dev should almost never happen and commit history alone isn't worth the effort of the git strategy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |