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
Person A is the one who decides when to incorporate new changes from master, so Person A will perform the merge. Person A should certainly attempt to resolve merge conflicts on their own, but if any questions arise then both Person A and Person B should sit together and resolve the conflicts together.
Remember that you work on a team. Teammates should help ...
Oh god yes.
I broke the build my first time. Made me so gun shy I was hiding versions in folders. Of course delaying my check ins just made things worse. I was in hell until I figured out what I needed.
I needed a safe place to play.
I created my own toy project so that I could deliberately cause merge conflicts. Learned how to fix them the hard way. Soon ...
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 ...
The longer a branch lives, the more it is able to diverge from the main branch and the messier and more complicated the resulting merge will be when it's finally finished. Ten small conflicts are easier to resolve than 1 massive conflict, and may actually prevent developers from duplicating or wasting effort. Given that, you should merge master into A and B ...
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 ...
Yes and no
In my experience, merge conflict are a result of not communicating. If you plan properly, you and your colleagues shouldn't have many merge conflict.
The reason people 'fear' them, is because it can be a puzzle to un-conflict them. Sometimes it's just 1 or 2 lines, but it could be a lot, multiple conflicts in one file, because you and a colleague ...
Extreme Programming is (partly) based on the idea that if things are "hard" or "scary", we simply aren't practicing them enough.
That's the thing: practice makes perfect.
So, the approach that Extreme Programming takes, is that things that are hard should not be pushed back as far as possible to avoid them. Instead, they should be ...
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 ...
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 ...
Practically speaking it is Person A, the branch owner.
In reality there will be branches C, D, E, and F that will now have conflicts with master, Person B won't be able to fix them all.
However, If you are working together merge conflicts should be easy to fix. After all you know what person B is attempting to do and will have discussed the needed changes ...
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 ...
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 &&...
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 ...
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 ...
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 ...
Assuming your intention is to eventually merge A, B back into master and maintain a single code base, it is never a good idea to deviate from master too far. Deviating from master for too long, especially when bug fixes and other development are merging to master as A, B are being developed, will certainly cause conflicts.
I would consider strategies ...