Hot answers tagged

61

Some suggestions: There is nothing wrong in having a lot of feature or bugfix branches as long as the changes done in each branch are small enough you can still handle the resulting merge conflicts in an effective manner. That should be your criterion if your way of working is ok, not some MSDN article. Whenever a branch is merged into trunk, the trunk ...


18

Are we exhibiting the very anti-pattern that was described as the 'big bang merge'? Sounds like it. Are some of the problems we're seeing a result of this merge process? Definitely How can we improve this merge process without increasing the bottleneck on my boss? At my company, every dev has the ability to merge. We assign a Merge Request to ...


13

This is essentially how a lot of open source projects work, including most notably the Linux kernel, which has a lot more branches in flight than you do at any given time. The typical way to avoid big bang merges in these projects is to create another branch (or multiple branches) for continuous integration. This is the branch you use to make sure your ...


8

I agree with both Doc Brown but I also see another antipattern: My boss, the sole authority on the trunk repository, will actually defer all of the reviews of branches until a single point in time where he will perform reviews on as much as he can, some branches will be thrown back for enhancements/fixes, some branches will merge right into trunk, some ...


2

When you do feature work in separate branches, you can't easily do any integration testing until one of the branches is merged to trunk and pulled into the other feature branches. In my experience, this is the main problem with the Big Bang Merge anti-pattern. Ideally, you would do feature work, test it in the feature branch, merge it into trunk, and at ...


1

If you had to say one way which was 'standard' branching model for git it would be gitflow. Many people find its not for them, but don't try to invent a new model until you've tried it. Rebasing is bad, it deletes your commits and screws over anyone else using the branch. Never rebase. Especially never rebase if the only thing you don't like about merging ...


1

So you have 20 branches. Branch 1 is just merged. Then the developer of branch 2 has to merge branch 1 into their branch to be able to merge into main without conflict, then merges. Then the developer of branch 3 has to merge branch 1 and branch 2 into their branch to be able to merge into main without conflict, then merges. Exercise for the reader: Write ...


Only top voted, non community-wiki answers of a minimum length are eligible