Hot answers tagged

130

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


105

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


27

In general, individual developers will be responsible for merging their own work. Delaying things only means it's more likely for others to get code into your merge target, making the merge worse.


23

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


23

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


19

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


12

The difficulty of a merge grows with the square of the number of merge conflicts. So it doesn't matter whether you fear merge conflicts, you resolve them as soon as you can. Where I work, you branch from the development branch, make changes to your branch, and create a pull request. If the pull request has merge conflicts then it is your job to merge the ...


11

Generally the person who runs into the conflict also has to resolve it, after all it's the person who wants that merge to happen and resolving the conflict is required to make it happen. In your sample that would be person A. It's person A who wants his code in the master branch. It's not person B who wants that code there. Person B just made changes to the ...


5

There is more than one kind of merge conflict, and most of them can be trivially resolved because to a human it is obvious what should happen, but to the computer it's not. Strategies for resolving these: rebase everything instead of merging No merge commits, ever. Instead, a branch is tested on its own, and when it's ready for submission, it is rebased ...


5

A nice tip to make merge conflicts easier. git config --global merge.conflictstyle=diff3. Without this set you will see your code and their code only. With it being set you will also see the original. For more info see this StackOverflow answer. Here's an example. The first is what it would look like normally. <<<<<<< HEAD log.info(...


4

In most development processes which have a "master" branch, it is the responsibility of anyone making changes to do the merges required. The "master" branch is a privileged branch in the sense that it is the "current best version" of the software. Once changes are merged into it, there is an expectation that they will be preserved, as they are now the ...


3

Code formatting standards (Partial answer, just adding to others.) This may sound stupid, but in my experience a lot of merge difficulty (I've seen quite a few instances of regression and new bugs introduced way back...) was caused by code format changes between different developers and the merge tool not being syntax aware enough to handle them gracefully. ...


3

It’s the responsibility of the person who wants to merge. Obviously any changes that would have caused conflicts would have been reviewed before being merged, and if a change caused an unreasonable number of conflicts it would have been rejected. Obviously A doesn’t merge into the main branch and then resolved conflicts. A merges the main branch into his ...


3

Merging a feature branch into master or dev should be a fast-forward merge, and thus should not require another review. Any previous merges or new development should have been peer reviewed already against the feature branch. What you call a "temporary release" branch is also called a "topic" branch or "feature" branch. This is a valid Git workflow, ...


2

If branch "A" and "master" have conflicts, merge "master" into "A" before opening the pull request. This way, the review process isn't started unnecessarily early and you can clearly see and discuss all changes that "A" would introduce, whether they stem from resolving merge conflicts or feature development.


1

The biggest cause for confusion I see is having a branch specific to an application environment. You need the flexibility to deploy any branch from any fork to any pre-production environment for testing. The readiness of a feature for release should be tracked elsewhere, not in Git. Git is for version control, not work item tracking. Don't over complicate ...


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