Hot answers tagged

59

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 ...


17

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 ...


12

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 ...


7

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 ...


5

In semantic versioning every release should be tagged, every tag should increase exactly one of the numbers by one (and set the following numbers, if any, to zero), and tags should never be reused for any reason. Other than that you are free to release as often as you like. If you release very often you may want to include some code to easily increment the ...


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

How can we improve this merge process without increasing the bottleneck on my boss? Improving the merge process doesn't fix the problem; it will just be an attempt fight the symptoms. And it will be futile, even if you find a way to improve the merge process, if you can't fix your manager, the process will start failing again when you hire a few more ...


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 ...


1

This is the simple clarification to the question: DevOps is a term used to describe the coordination or relationship between Development(developing the program codes in development environment) and Operations(ensuring maximum up-time of production environment). Software Configuration Management is a means of achieving this coordination. SCM involved tools ...


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