@Pascal: “Pull requests” are a good point. The times I refer to in the article, were times where we did not work with pull requests. Now we use github so this may improve.

@Karin: Good point ;-)

@Marco: I agree, frequently merge your code avoids most of merge conflicts

@Reza:
To clarify things, I am not accusing GIT or Linus for making me fix merge conflicts.
Furthermore I am aware of merge workflows very well ;-)
My intention was more to investigate whether merge conflicts can point to organisational issues or can be avoided at all.
But I got your point “maybe there is a problem with what I do”. Thats missing in the article itself. Thanks also for the links.

Your article is factually wrong. The whole concept your describing here is absolutely way off what merge algorithms were actually built and intended for. It’s like using a fruit knife to explain the ability to cut wood for a chainsaw.

Let me explain: “CVS, SVN or GIT, merging is a daily task.”
If you told that to Linus or the author of any other first or second generation DVCS theyd rip you apart.
First of all merging and CVS is, well, hehe … SVN was set out to fix that but still has other conceptual flaws.

Now lets go to GIT, GIT was made to merge 1000s(or maybe it was hundreds) of patches each day from peers. The whole concept is trust. Linus trusts that the peers hes merging from only merged stuff from trusted peers or checked the code themselves or built it themselves.

Already you see a conceptual conflict here. How does that guy manage to merge tens of thousands of lines of code without conflict from people he doesn’t talk to? Already you should be asking yourself maybe there is a problem with what I do.

But ok, you got a conflict. Git developers have spent hours and hours on how to make the process less painful.

If you keep having problems with conflicts on your codebase, the solution is not talking more to product managers, testers, management etc. The solution is to rethink the way you work. Because it sounds broken. You need to talk less and get more done.

Here are 2 reads on that topic
http://scottchacon.com/2011/08/31/github-flow.html
http://iwata.github.com/blog/2011/11/21/git-royale/

i agree with you, that talking to colleagues is very important.
however in your post you imply that talking to the whole company is neccessary to prevent merge conflicts.

i don’t see why you expect from a project or product manager to have enough technical expertise that they can see that 2 different stories affect same parts of the source code?

in my opinion the first and simplest thing to avoid merge conflicts is to commit (and even more important) update your local code as often as possible with the changes your colleagues commited. the chance for merge conflicts decreases on every update you do. if a conflict occurs it is often so small that it takes me a minute to solve it.

nevertheless your solutions are good and be worth discussed e.g. in a retrospective. but i see that taking only as an additive not as the main solution.

I would like to add something: Sometimes, your team’s and/or the other team’s agile tester may know about it, so:

Talk to your tester

And that’s exactly the Point. Using SVN And making a Lot of Meetings because of Many different Communication Problems, is in my opinion Not the right Approach for a certain Solution.

There are a few buzzwords for how to avoid all these Problems wirh Communication And conflicts while using a VCS:

- Git
- working asynchronously
- no Meetings
- Not pulling developers Out Off the Flow

Let me dig into These points. If you’re using Git you don’t Ever have These Kind of suicide Feelings when trying to Merge a Branch back to Trunk. Branching, merging, all This stuff which is a pain in the Ass when working with SVN, is damn Easy to do in Git. Merging in Git is a very powerful Thing that you have to use if you wanna be productive. And its okay, because its Easy.

Working asynchronously means That you do your work. There is no Meeting which Pulls you Out of the Flow. Meetings are Time steeling. If you wanna Talk about Things, do it via Email, send pull requests And use These as a discussion Base.

So in my opinion, all the Things you pointed Out there are very Easy to avoid, if you’re Doing it right.