I assume you're using git. If so, make use of git rebase -i (the -i means interactive). Make it a daily task (even more frequently, if necessary) to rebase your branch against the develop branch. This brings in the changes incrementally every day (at least) to keep your feature branch up-to-date. If there are conflicts during your daily rebase, you need ...
This might be a sign of bad software engineering on the company's part. Too many inter dependencies, different issues with overlapping features, attempting to tackle issues in the wrong order etc. can cause the situation you are describing. I suggest regularly merging develop into your branch during development
The accepted answers I think are more of a technical "how to use Git better" nature, I think this is more of a team problem than an engineering or tooling problem.
If you're encountering a lot of merge conflicts it means that you and someone else on the team are stepping on each others toes.
You or they should aim to develop personal space while coding and ...
People want to avoid merge commits because it makes the log prettier. Seriously. It looks like the centralized logs they grew up with, and locally they can do all their development in a single branch. There are no benefits aside from those aesthetics, and several drawbacks in addition to those you mentioned, like making it conflict-prone to pull directly ...
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 ...
In two words: git bisect
A linear history allows you to pinpoint the actual source of a bug.
An example. This is our initial code:
Branch 1 does some refactoring such that arg is no longer valid:
Branch 2 has a new feature that needs to use arg:
if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)
And therein lies the source of your confusion and the whole problem in general.
You say that merging branches is "fundamentally wrong and silly". Well, ...
There would have been a simple way which had kept your new development separate from the main branch without bringing you into this unfortunate situation: any change from the trunk should have been merged into your dev branch on a daily basis. (Was your client really so shortsighted that he could not anticipate that your branch needs to be remerged back ...
The most important thing about merging is that the longer you wait, the more painful it gets. And the problem grows more than linear. Three times as many conflicts are nine times as much work. There are some strategies:
Merge with the development branch whenever it changes, so you are always close to it, and never have a huge number of conflicts.
If you ...
It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.
I don't follow svn very closely, but my understanding is ...
Pull requests provide for checks and balances, even if anyone can push to master.
The biggest advantage is that they provide an opportunity for code review. The person that is responsible for performing the pull can look at the code and tests and make sure that they meet any kind of guidelines that the organization or team has. There are also other reasons ...
There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy
What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".
From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...
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?
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 ...
In short, because merging is often another place for something to go wrong, and it only needs to go wrong once to make people very afraid of dealing with it again (once bitten twice shy, if you will).
So, let's say we're working on an new Account Management Screen, and it turns out there is a bug discovered in the New Account workflow. OK, we take two ...
It works fine if you stick to the simple cases, but there are some complex ones that don't.
The limitations I can think of:
It can only find the most recent ancestor if it is on one of the branches involved. So if you create branches/this and branches/that both from trunk and then try to merge branches/this to branches/that, it will not know what to do. ...
By the time I'm ready to merge my branch back into develop (emphasis mine)
Handling conflicts in git merge is often simpler than in git rebase. In Git merge you can see the whole list of files that have been modified at once. No matter how many commits have been done by other coworkers, you will have to merge once. With rebase workflow, you may end up ...
At that stage of merge I would say that automated merging may only over complicate the process. I have had similar issues with branches that have diverged for over a year and the most effective method I have is to do the following:
Take a copy of the original unmerged state
Diff between the unmerged and latest
Break down any common elements
For example, do ...
Assuming that this snippet of code
x+=1 if foo
x+=1 if bar
has been changed in one branch into this
x+=1 if foo && xyzzy
x+=1 if bar
and in another branch into this
x+=1 if foo
x+=1 if bar && xyzzy
then I would not want git to merge it into this
x+=1 if foo && xyzzy
x+=1 if bar &&...
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 ...
Is this git-only behavior?
After discussion with a colleague, I just tried, and SVN handles it without problem: you get the 2 lines modified.
The merge capabilities of several VCS are tested here for bazaar, darcs, git and mercurial: https://github.com/mndrix/merge-this
It seems only darcs successfully merge the "adjacent lines" case.
Applying adjacent ...
Using git merge feature while on master merges the branch feature to master and produces a merge-commit (if the branch cannot be fast-forwarded) in the git history. To force a merge-commit being made, use the --no-ff option with merge.
Merge Pull Request mechanism:
When we start a Pull Request on GitHub, it creates a GitHub Issue where ...
What concerns me here is that you make it sound like anyone checking in code has to blindly check it in to multiple branches. That is wrong. Branches should exist for a reason. The event of checking in code should happen once and flow from there. Who gets it flowing isn't as important as that branches are kept meaningful and useful in each step.
I think it all depends on how the branches are structured.
1. Branch A and branch B are independent
branch A +---------+-------------
/ \ merge 1
\ \ merge 2
branch B +-------------+------
As you can see here, I would merge from branch A to trunk, then ...
A few years back we had a client with the same requirements of keeping branches separate. So we did.
We never merged their branch back. They had there own unique version. We charged them extra for changes since essentially we had two major trunks instead of 1 main trunk and branches.
We attempted to merge back to trunk but after 2 weeks we decided to ...
In the situation you describe, you are not getting any benefit from having multiple repositories, but you do have a cost: you can't roll back to an older version of a repository, and have any confidence that your system will continue to work. This is because your code is tightly coupled across repositories. As confidence in the ability to roll back is one of ...
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 ...
It generated a dozen conflicts, which I resolved mostly by accepting the working copy of the trunk.
Well, this seemed to be one cause of the problem. Check merge conflicts very carefully and make sure you resolve them by manual editing, not by (perhaps blindly?) accepting them.
Especially with SVN (but I guess even with DVCS) when doing structural changes ...
You have answered your own question:
Another answer is: "Have the devs get together and hash out how to manually merge some stuff."
That's the only way to resolve this sort of merge conflict. Assuming you don't have rogue developers forking your project, as a team you will have to agree what is the correct result of merging independent work.
There is no ...
The good schedule is to merge only stable code (or "likely to be stable" code).
If you merge half-way just to begin tests, and you know that some of the features you're currently coding are not finished, you surely will get some testing feedback about these features.
The question you have to ask is "Am I confident with the completeness of what I already ...