{"thread":{"id":"45562","subject":"Git Branching - Best Practices - Large project - long running branches","startedAt":"2017-03-31T11:55:49Z","lastAt":"2017-03-31T13:24:16Z","messageCount":3,"participants":["Mayne, Joe","Jakub Narębski","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"315880","messageId":"4bb4871d8a78402bbef91231134a613b@EX1-PRD.lsac.org","threadId":"45562","inReplyTo":null,"subject":"Git Branching - Best Practices - Large project - long running branches","fromName":"Mayne, Joe","fromEmail":"jmayne@lsac.org","sentAt":"2017-03-31T11:55:40Z","receivedAt":"2017-03-31T11:55:49Z","isPatch":false,"sender":{"key":"jmayne@lsac.org","avatar":null},"body":"Hello,\nI work on a team of 15+ developers. We are trying to determine best practices for branching because we have had code stepped on when a developer has a long running feature branch. \n\nWe have a Development branch. Developers are instructed to create a branch when they begin working on a feature. Sometimes a feature may take a week or two to complete. So a Developer1 creates a branch and works for a week or two. In the meantime, other developers have created feature branches from Development and merged them back into Development. \n\nAt this point we are not certain if Developer1 should: \n* Periodically merge the evolving Origin/Development into their Feature branch and when they are done work merge their feature branch into Origin/Development. \n\nOR \n\n* Stay on their pure feature branch and when they are done merge into Origin/Development. \n\nWe have had issues with developers stepping on code when they have long running branches. We are looking for a best practices. \n\nThank you,\nJoe Mayne\n\n"},{"id":"315883","messageId":"d336369a-3b1c-c311-2155-1e08ae669cdb@gmail.com","threadId":"45562","inReplyTo":"4bb4871d8a78402bbef91231134a613b@EX1-PRD.lsac.org","subject":"Re: Git Branching - Best Practices - Large project - long running branches","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2017-03-31T13:02:49Z","receivedAt":"2017-03-31T13:05:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 31.03.2017 o 13:55, Mayne, Joe pisze:\n\n> Hello, I work on a team of 15+ developers. We are trying to\n> determine best practices for branching because we have had code\n> stepped on when a developer has a long running feature branch.\n> \n> We have a Development branch. Developers are instructed to create a \n> branch when they begin working on a feature. Sometimes a feature may \n> take a week or two to complete. So a Developer1 creates a branch and \n> works for a week or two. In the meantime, other developers have \n> created feature branches from Development and merged them back into \n> Development.\n> \n> At this point we are not certain if Developer1 should:\n> \n> * Periodically merge the evolving Origin/Development into their\n> Feature branch and when they are done work merge their feature branch\n> into Origin/Development.\n\nThis is one possible solution.\n\nAnother variant of this would be to enable rerere feature (reuse\nrecorded resolution), and periodically do a trial merge from the\nOrigin/Development branch to prime the rerere mechanism (discarding\nthose merges after resolving them).\n\n> \n> OR\n> \n> * Stay on their pure feature branch and when they are done merge\n> into Origin/Development.\n> \n> We have had issues with developers stepping on code when they have \n> long running branches. We are looking for a best practices.\n\nThere is yet another solution:\n\nOR\n\n* Periodically _rebase_ pure feature branch on top of current version\nof Origin/Development, or do such rebase (perhaps an interactive one\nto clean-up feature development steps) before pull request, before\nthey are to merge feature branch into Origin/Development.\n\nYou can also try to use third-party git-imerge tool to help merging\nlong divergent branches.\n\nHTH,\n-- \nJakub Narębski\n\n"},{"id":"315885","messageId":"001801d2aa21$ca45cb20$5ed16160$@nexbridge.com","threadId":"45562","inReplyTo":"4bb4871d8a78402bbef91231134a613b@EX1-PRD.lsac.org","subject":"RE: Git Branching - Best Practices - Large project - long running branches","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-03-31T13:21:59Z","receivedAt":"2017-03-31T13:24:16Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"-----Original Message-----\n>On March 31, 2017 7:56 AM: Joe Mayne Wrote:\n>Subject: Git Branching - Best Practices - Large project - long running\nbranches\n>I work on a team of 15+ developers. We are trying to determine best\npractices for branching\n>because we have had code stepped on when a developer has a long running\nfeature branch. \n>We have a Development branch. Developers are instructed to create a branch\nwhen they begin\n>working on a feature. Sometimes a feature may take a week or two to\ncomplete. So a Developer1\n>creates a branch and works for a >week or two. In the meantime, other\ndevelopers have created\n>feature branches from Development and merged them back into Development. \n>At this point we are not certain if Developer1 should: \n>* Periodically merge the evolving Origin/Development into their Feature\nbranch and when they\n>are done work merge their feature branch into Origin/Development. \n>OR \n>* Stay on their pure feature branch and when they are done merge into\nOrigin/Development. \n>We have had issues with developers stepping on code when they have long\nrunning branches.\n>We are looking for a best practices.\n\nOne key thing that may help is standards on formatting. I know that sounds\nsilly, but many merge\nissues result from developers hitting the source format button and create\nmerge problems. If you\nkeep things to format standards, it will help merging in future. Even\nlengthening lines to 132 instead\nof 80 may reduce confusion - another silly suggestion, but I have seen it\nhelp in a couple of places.\n\nKeep your interface classes and base classes stable. If you are changing\nthose during development,\nyou are going to impact the larger world and probably should set up a\ndedicated feature branch\noff of Development and have all topic branches involved in the API change\nbranch off that one.\nFrequent merges into topic branches are common when API changes are ongoing\n(as are conflicts)\n- they should not be as much when the APIs are stable. If you can, get the\nAPI changes done first,\nthen create topic branches after the API is stable.\n\nFrom what I have seen, frequent conflicts are sometimes an indication of an\nunderlying\ndevelopment process problem - you should look into this and see whether\nthere are issues here.\nConflicts happen, but the \"why\" is important to understand.\n\nCheers,\nRandall\n\n\n"}]}