3 ms·
To me, it sounds like the author is advocating for what we did when we used Subversion and merging was painful for non-trivial differences. In my opinion, the r
by manyxcxi 11y ago
To me, it sounds like the author is advocating for what we did when we used Subversion and merging was painful for non-trivial differences. In my opinion, the reason for switching from SVN to Git isn't that it's so distributed (you need to push centrally to get CI and share changes after all) it's that branching and merging are so much easier there's no excuse not to.
We create a branch for nearly every ticket and definitely for all features.
Master is essentially production ready or already in production while our development branch get run through CI/CD on every commit. The development branch is rarely broken and in almost all cases is where we branch our features/fixes from. It's up to the branch developer(s) to merge development back into their branch before bringing their branch back to dev- but since we're a small team and branches rarely live longer than a week merging back causes so few issues that we don't even flinch.
Gone are the days of SVN where you'd spend two weeks off commit and pray your integration went smooth.
- sytse 11y agoTotally agree, shared remote branches are a good idea to build new features. A remote branch allows you to leverage CI in advance of merging and to discuss a work in progress with a team member, for more details see http://doc.gitlab.com/ee/workflow/gitlab_flow.html http://doc.gitlab.com/ee/workflow/gitlab_flow.html