4 ms·
The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branc
by brown9-2 13y ago
The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branch in a state to be deployed? are your changes done?".
- sidcool 13y agoYou are right, that would be the opposite extreme. What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production. This saves us some merging.
- brown9-2 13y agoIs merging painful enough for you team that it's worth avoiding?
- sidcool 13y agoIt can't be avoided, but we do tend to try and minimize it.
- fishtoaster 13y agoMy experience has been that maximizing merges works best. If you're constantly merging, hardly any of your merges have any friction. The longer you're separate from the master branch, the more likely you are to get painful merges with conflicts and subtle bugs.
- erichurkman 13y agoElsewhere in the thread, you'll see that 'sidcool is on SVN, where merging is not a fun experience — which explains his team's aversion to merges.