Cyufjy

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 avoid working in areas that are busy already.

In my team, we tend towards a high degree of task-ownership.

I'll usually take full and complete ownership of two or three files at a time and work on them in a branch for a day or two at most.

Typically if anyone else touches those files it's only if absolutely necessary for their own tasks, we generally don't work together on the same block of tasks at all!

If you're finding that you have to merge a lot at all then either all your teams code is in one place (which is something to avoid in itself) or all your tasks are.

All that said, as a new dev you're probably not in a position to enforce, request or even really suggest any sort of restructuring.

What I'd expect is that your tasks have been assigned as "learn-the-ropes" stuff that should be reasonably approachable at your skill level in order to ease you into the team. They've probably been culled from the tasks of a co-worker who is still working in the same area, hence your merge conflicts.

The solution to this then is to plug away at it, solve the problems, deal with the merge conflicts as best you can and don't worry too much, as long as you're doing your best it's down to your manager to worry about your progress.

You'll get faster and more confident as you go, and your co-workers will give you more autonomy and get in your way less as a consequence.

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 take a long time, then it may be because you spend most of the time figuring out what the changes are, and then a small amount of time implementing the changes. If that is the case, merge with the development branch before you start actual code changes.

Talk to your colleagues about strategies to avoid conflicts. You get conflicts if two people edit the same code. Not just the same file, but the same code. So I need a new function functionA and you need a new function functionB, and we both add it at the end of the same file, we have a conflict. If we add it in different places, no conflict. If we both add it at a place in the file where it logically belongs, chances are we have no conflict.

If you have conflicts, get a good diff tool, so you can compare the develop branch before your merge, your code before the merge, your original code, and the merged code, and merge by hand.

Worst case: You don't throw your work away, but use a good diff tool to find out exactly what changes you made, branch again from develop, and apply all the changes you made manually instead of retyping them.

You should run regularly (daily) the command 'git fetch' (not git pull) from your development branch. This will get other peoples committed changes and bring them into your feature branch without attempting to integrate the changes into your branch.

This is something you should talk to the lead developer about (not necessarily your manager), because your company may have their own standards or recommended ways of handling this issue; it's very common. Don't wait until next week - find out the process now, and ask if you can commit some trivial work (such as code formatting or adding comments) so you can test the process.

First, don't think about discarding your changes. You will loose opportunities to learn merge process.

Second, find person who worked on files causing conflict. You can see history. Talk to person and resolve conflicts in that files. Do same for other conflicts.

If it's too many conflicts, your task may be a minor but repetitive. Try to find pattern. This would help in resolving conflicts by git UI client tools. I use TortoiseGit. It helps in merge.

And for avoiding in future,

-it's a very good practice to merge develop branch regularly to your feature branch.

-If you have CI enabled, see if CI tool provide branch build. This should build on every check in you make in your feature branch but after merge develop branch.

You get merge conflicts if the changes you did in your branch are near the changes your colleagues did in the develop branch in the meantime, that is, if you and your colleagues changed the same lines of code or adjacent lines in the same file.

So to reduce the likelihood of merge conflicts, you can try to merge earlier so that your colleagues changed fewer lines in the meantime, or you can try to change fewer lines yourself.

To change fewer lines yourself, make sure to only make changes related to your task.

If you need to experiment with different ways to achieve your goal, maybe some of your experiments changed lines that don't really need to be changed? Undo these changes before merging.

There are also some Git commands that can help you change as few lines as possible:

• 
  git diff and git diff --staged to see which lines you changed.


• 
  git add -p to only add some of your changes in a file.


• 
  git commit --amend and git rebase -i to tweak commits you already made in your local feature branch before pushing them to other Git repositories.

(Changing as few lines as possible can also make it easier to review your work or to use tools that work on the differences between commits such as git cherry-pick, git rebase, git bisect, and git blame.)

But even if you reduce the likelihood of merge conflicts, you will still run into merge conflicts sometimes. So don't be afraid of them, but learn how to resolve the conflicts.