Iyfjky

Question

I am the new developer - this is my first programming position.

My issue is this: We use git - I cut a branch from our develop branch, then I start working on the minor task I've been assigned. It's very slow, because I'm inexperienced. By the time I'm ready to merge my branch back into develop the others have made so many changes that resolving the conflicts is overwhelming (it actually seems easier to scrap my work and start over on the task, which of course is not a sustainable solution).

How do I overcome this? Is there a tactic I can use other than 'be better at coding'? I intend to bring this up with my supervisor next week.

you dont need to only merge your branch into develop only when you are finished. you can merge develop into your feature branch incrementally whenever you like, to make the final merge smaller. — Aug 17 at 12:42
Be sure you're doing the merging process right. Only your files should be affected and only your changes should be applied to the dev branch. If you're getting random conflicts, chances are you done the merge wrong or others are messing up the revision order. It's a good chance to educate yourself and possibly others in merging right. Some folks have a hard time understanding it's changes, not files that are being merged. So revisions ordering out of sync would cause conflicts on files you never touched. — Dan, Aug 17 at 13:00
Also be sure your editor is set right. Sometimes editors "fixes" tabs and spaces so when you edit a file, and attempt to commit back, it changes the entire file. You should make sure before committing that only your changes are being committed to the branch and fix your editor. — Dan, Aug 17 at 13:05
There is one odd thing here "I start working on the minor task " and tons of merge conflicts normally do not match. I just merged a 2 week major update branch into an experimental development and we had 10 (!) conflicts that were not auto-resolvable. You do not get tons of conflicts unless your task is "change variable names over all files". Not for MINOR tasks. — Aug 17 at 16:07

Robert Harvey 161k39371581 · Accepted Answer · 2018-08-17 16:35:04Z

up vote
281
down vote

accepted

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 to have a talk with your team about who's working on what.

If you run it daily, you probably won't need the interactive part. Just let it do its thing.

I'm a fairly experienced developer, and it still takes me quite a bit of time to get up to speed on a new project. In your case, it sounds like you have several people working on the same project simultaneously, so it's either a very large project, or a new project that's evolving quickly. In either case, don't be worried if it takes you several months to get into the flow. If I switch projects for 2 or 3 weeks and then switch back, it can take me a few hours (or even a day or two) to get fully "back into" a project that I wrote 100% on my own!

In short, don't worry about being slow right now. The way to get better is to just keep practicing. Don't be afraid to ask other developers about aspects of the projects you don't understand.

edited Aug 17 at 16:35

Robert Harvey

161k39371581

answered Aug 17 at 13:23

Jacob Robbins

1,896155

22

I guess this is the correct answer, but, IMO, just another example of bad Git design and terminology. Just what are you "rebasing"? Shouldn't this be called "update" or "checkout" or "merge" or some such??? (An answer below argues for "fetch") What's the point of source code control if every day you are forced to update???
â€“Â user949300
Aug 17 at 18:26

93

It isn't updating or checking out though. It's taking whatever is exclusively in your branch, and adding your changes as if you just now made them on the other branch. I.e. your changes are now "based on" the other branch. Furthermore, there does not exist any magical source control system that knows your code and can know how to merge changes when multiple people modify the same files. You update every day to keep the conflicts small and manageable, and the changes fresh in everyone's minds so they know how to handle them.
â€“Â Vectorjohn
Aug 17 at 18:51

53

@user949300 rebasing is distinct from merging, is much more nuanced and requires a better understanding of Git than a simple merge workflow. That's why I never recommend a workflow involving rebasing to a Git novice, because it leads to the assumption that rebasing is the only/default way to update a branch and leads to lots of unnecessary pitfalls and pain. In this case, merging will solve the problem in the same way and neither will solve the problem of merge conflicts in two long-running parallel feature branches.
â€“Â Ant P
Aug 17 at 20:44

13

@user949300 git pull which is just a combination of git fetch and git merge (or you can add --rebase to do a rebase instead of a merge). Assuming you're only about a day behind, then on a LAN this will likely complete in less than second, it might take a couple seconds over the internet. Even over the internet and with minor merge conflicts, you can typically be up-to-date and merged cleanly in less than a minute. Spending five minutes spread throughout the week is a lot better than spending an hour at the end of week dealing with a gnarly merge conflict.
â€“Â Derek Elkins
Aug 18 at 1:15

60

No upvote from me because this answer is entirely fixated on rebasing. Rebasing can be a useful tool, but it should never be used mindlessly. For the day to day updating it's better to merge. Why? Because every rebase is a lie. You are telling history in a way it never happened. This can totally screw mighty tools like git bisect: The rebased stuff may not even compile, so git bisect is worthless on the resulting broken commits. @maaartinus: I, for one, prefer true history over linear history. If you rebase, you absolutely must check every new commit for sanity to avoid harmful lies.
â€“Â cmaster
Aug 18 at 8:46

Â |Â
show 31 more comments

Ivan Anatolievich 1,307113 · Answer 2 · 2018-08-17 12:49:28Z

up vote
129
down vote

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

answered Aug 17 at 12:49

Ivan Anatolievich

1,307113

9

This is coding 101 stuff as you mentioned. Not necessarily an accurate reflection on the new employee.
â€“Â Mister Positive
Aug 17 at 13:26

2

@Ivan Anatolievich OP says that they're branched off of develop, not master, FYI
â€“Â Matthew FitzGerald-Chamberlain
Aug 17 at 14:50

6

This answer shows exactly why I don't like GIT: it's again another tool for teams to avoid having a proper management and decent planning. The answer to everything is "who cares, you can always use that command later", instead of avoiding problems before they happen.
â€“Â motoDrizzt
Aug 20 at 10:29

7

my first thought was also a sign of bad practices, devs shouldn't be working on the same files for the most part. If a small project is having this many conflicts, everyone else must just be resolving conflicts all day long without doing any work!
â€“Â Aequitas
Aug 21 at 5:44

13

@motoDrizzt What? I have never heard anyone make that argument.
â€“Â jpmc26
Aug 21 at 15:56

Â |Â
show 4 more comments

Rowan 1,03916 · Answer 3 · 2018-08-17 14:54:57Z

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.

I think you hit the nail on the head with the co-worker conflict. Merge conflicts are a regular thing, but they are generally limited to a handful of files. — Aug 17 at 15:23
This sounds like a corollary to Conway's Law, and the Single responsibility principle -- i.e. that if people are working on different problems then ideally they'll be editing separate parts of the source code. — Aug 17 at 17:04
While I agree that a poor process or poor design can lead to a large amount of conflicts, I'm pretty confident that the issue is simply that the OP isn't merging in the mainline regularly. I don't agree that "taking full and complete ownership" of files is appropriate as a matter of course. I don't want my team having a constant overhead of keeping track of who "owns" what now, asking "permission" to make changes, or guessing what files they should "claim". Only rarely, when significantly rewriting a component, have I asked team members to inform me if they were going to change certain files. — Aug 18 at 0:40
ChrisW has the right idea with what I was driving at. Generally speaking Ownership in my company takes the form of application functionality, I take complete ownership of the Search Filter system as a task and as it happens, nobody else needs to touch the related files under most circumstances. My feeling is that it's very likely OP as a new starter has been given minor parts of tasks closely related to an ongoing set of tasks by another dev. Meaning the other dev is working in the same part of the codebase and they're getting in each other's way. — Aug 19 at 12:04
@Rowan Cool yeah I thought as much. Functionality separation can also help with file separation (sets of functions in different files etc) and this IMO helps with merging. — Aug 22 at 9:43

gnasher729 18.3k22452 · Answer 4 · 2018-08-17 21:06:54Z

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.

Feature branches present themselves like another form of tech debt, where up-streaming changes from the parent branch is like refactoring. — Aug 22 at 17:32

score 15 · Answer 5 · 2018-08-24 12:45:56Z

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 getting the same conflicts over and over and have to review them manually. You can end up fixing the 13th commit and feel like you can't see light out of the tunnel.

By my experience, when I attempted to naively resolve repeated rebase conflicts I ended up losing someone's modifications or with an application that did not even compile. Often I and coworkers did a lot of work but became so overwhelmed by the complexity of repeating conflicts that we had to abort and lose our previous work after a handful of rebase commits.

I am going to suggest you a few techniques but they can only help the merge get easier than automate the task.

Resource/language files. If you have additive changes to a resource file, make sure you always move them to the end of file so that you can easily recall your changes against others' changes. You may be able to copy&paste your changes on the bottom, or just remove the conflict markers

Do. Not. ABSOLUTELY. RE-format. Neither you nor your fellow developers shall perform a "massive code reformat" during daily work. Code reformat adds an excessive number of false positives in conflict management. Code reformat can be done
- Incrementally, e.g. by every developer on every commit, as soon as they use an automated tool (e.g. Eclipse has an option to reformat on save, vanilla Visual Studio has none). Absolutely every developer must use the same code formatting standards, coded into a format file that is eaten by your IDE. To give you an idea, if it's 4 spaces or 2 tabs it doesn't matter, but it really matters if everyone use the same.
- Just before release, by a team leader. If a "code reformat" commit occurs when people are not working on branches, i.e. before they branch, things will make easier

Review the work splitting between coworkers. This one is the part where most engineering comes. As pointed by other answers, it is design smell if multiple developers doing different tasks have to touch the same resources. You may have to discuss with your team leader about what part is to be modified by each concurrent developer.

I also have seen some bad habits in Git workflows in my teams. Often people overcommit to their branches. I personally witnessed a developer adding 10 to 20 commits labeled "fix", each committing one or two lines. Our policy is that commits are labeled with JIRA tickets to give you an idea.

@JacobRobbins suggests to make git rebase a daily task. I would like to push his approach forward.

First, use rebase once just to reduce the number of commits to a handful. And rebase only onto the original develop branch, which is the commit you have branched from. When I say handful, I could mean 3 or 4 (e.g. all front end, all back end, all database patches) or any humanly-reasonable figure. After you have consolidated them, use fetch and work your rebase over the upstream branch. This won't save you from conflict unless your team reviews their own approach, but will make your life less painful.

If you have additional questions on the specific tasks, feel free to search and ask on Stackoverflow.

[Edit] about the no-reformat and boy scout rule. I have slightly reworded RE-format to highlight that what I am meaning is the task of formatting from scratch the entire source file, including code that was not touched by you. In opposite to always format your own code, which is perfectly boy-scouty, a number of developers, including myself, are used to reformat the entire file with the IDE's capabilities. When the file is touched by others, even if the affected lines are not changed in their contents and semantics, Git will see it as a conflict. Only a very powerful language-aware editor may suggest that the conflict is only related to formatting and auto-merge the best-formatted fragment. But I don't have evidence of any such a tool.

After all, the boy scout rule does not mandate you to clean other people's mess. Just yours.

It is largely a matter of opinion, but I disagree that merge conflicts are easier to handle than rebase conflicts. When you rebase, you essentially apply commits one by one, keeping the scope of the merge conflicts much smaller and easier to follow (you apply YOUR changes that you know - not someone else's changes that you don't). You may have to solve more merge conflicts this way (due to touching the same files multiple times across commits), but they will be smaller and easier to tackle. — Aug 20 at 3:39
Regarding reformatting, while VS can't do it automatically on save, if you set "When I paste" to "Indent and format" in "Tools" --> "Options" --> "Text Editor" --> "<Your language of choice>" --> "Formatting", that means it auto formats on paste. This allows the sequence of three keystrokes: ctrl-A, ctrl-C, ctrl-V to have the desired result. That said, +1 for Do. Not. ABSOLUTELY. Reformat. Except as you outline under very carefully controlled conditions. — Aug 20 at 18:32
Bob Martin readers should note that the Boy Scout Rule must be applied with restraint if you are working in a team (if you are working on your own, you have much more flexibility). If you interpret the rule as "It is my duty as a coder to fix literally everything in every file that isn't perfect the instant I find out about it, nevermind what anyone else is working on.", you will end up with a gigantic amount of hard to resolve conflicts, and it will be a giant mess no matter how good your intentions are. — Aug 20 at 19:35
You you feel a need to reformat or lightly refactor the code, do it before or after your meaningful commit. It will not only reduce conflicts, but also helps future reader of your commit, including reviewers — Aug 21 at 7:16
From my C# culture, "re-formatting" means the action of formatting a whole code file or even entire repository where formatting is only related to readability. If your language uses whitespace meaningfully, you shouldn't mess with whitespaces in LOCs that are not your own. Conversely, your language of choice may still allow non-meaningful whitespaces (e.g. before a brace) that can be "reformatted" according to a readability standard — Aug 21 at 13:18

Peter Mortensen 1,11621114 · Answer 6 · 2018-08-19 00:48:09Z

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.

Also before merging, a git fetch and git diff origin/develop will show you a preview of your merge (sort of). Gives you a chance to clean up your changes before you get a ton of pointless conflicts. — Aug 21 at 13:12

trichoplax 11716 · Answer 7 · 2018-08-28 15:53:08Z

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

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

If there are too many conflicts, your task may be a minor one, but repetitive. Try to find a pattern. This would help in resolving conflicts by the Git UI client tools. I use TortoiseGit. It helps in merge.

And for avoiding in the future,

It's a very good practice to merge the develop branch regularly to your feature branch.

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

+1 The other suggestions for using Git better are good, but actually talking to the other developers about merge conflicts is another key aspect to develop OP's effectiveness. — Aug 20 at 15:41
"You can see the history" Maybe! Depends how squashed & rebased everything is :P — Aug 22 at 10:43

PeteCon · Answer 8 · 2018-08-17 13:03:11Z

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.

I'm not sure this is correct. Git fetch will get remotes/origin/master up to date but you then need to merge remotes/origin/master into your feature branch (Or remotes/origin/develop if that's the flow they are using) — Aug 17 at 13:10
Assuming he's using git, it's also a good idea to learn how to squash your commit to meaningful parts. That way when you're ready to make a pull request, your commit is lean and straightforward and easy to understand. — Dan, Aug 17 at 13:10
@RichardTingle Correct, He's thinking of a rebase option. You simply fetch & rebase your branch with the dev branch. That will sync up everything. — Dan, Aug 17 at 13:12
@Dan I think that may be a matter of opinion. Personally I hate massive commits. Try git bisecting that! — Aug 17 at 13:12
@PeteCon "and bring them into your feature branch without attempting to integrate the changes into your branch". That seems like a contradictory statement. I think you mean bring them into your local repository without integrating them into your feature branch, but I'm not sure how that helps... — Aug 19 at 1:03

Kafein 1372 · Answer 9 · 2018-08-20 16:23:24Z

Obviously first thing is to avoid having multiple people work on the same files in the first place, at least in a way which leads to difficult conflicts. Adding things into enumerations is no problem as long as a good code format is used. Changing control flow in different ways and moving code around is vastly more tricky. Sometimes this is inevitable nonetheless. You'll need to ask questions when resolving conflicts that are truly complex.

That said, I see many answers recommending to merge/rebase onto develop regularly. I would be much less enthusiastic about that sort of advice. Your goal at this point is to make the conflict solving process as easy and safe as possible. One thing which is going to help tremendously with that process is to have as many regression tests immediately available, including the new ones that are part of your new feature. If you synchronize your branch very regularly with develop, you will invariably end up having to resolve conflicts while you are half done actually implementing your feature. And that means that it will be much more difficult trying to figure out what the code is supposed to do, as you weren't done with it. Before attempting to merge, make sure that your branch is a coherent unit of change. Even better, rebase it into a single commit before merging.

I tried not to go into the merits of rebase over merge which is probably for another question. In this context the tools don't really matter.

James 15814 · Answer 10 · 2018-08-22 10:30:22Z

By the time I'm ready to merge my branch back into develop the others
have made so many changes that resolving the conflicts is overwhelming

This sounds like an ideal scenario for pair programming!

More info about the benefits and basic approaches:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

You will naturally speed up over time from working on your own, but it can be daunting until that time comes, and is a long haul sometimes too. Also, while people can learn quickly being in a stressful environment always pressured to catch up, others who don't learn well under constant pressure will be hindered.

Instead of working on a branch on your own and trying to keep up with other devs who are obviously much faster than you, you'd instead work directly (same PC) with another dev. This way you get instant advice and will probably pick up tips how to speed up etc.

You'd have figure out the best approach for the particular code in your project, as pair programming doesn't always makes sense for some projects - although it arguably always makes sense for learning even if you just sit and watch someone more experienced than you (as long as they're a good dev, experience doesn't necessarily mean they use good practices).

Sitting with a faster, more experienced dev has potential to help by:

Will likely reduce merge conflicts as working with someone more experienced will increase the completion time as opposed to your working alone

As they'll be teaching you it's likely they will be slower than they would be working alone, so there may still be some merge conflicts and so can work through them with someone seasoned and so perhaps pick up some tips on saving time etc

Help you see potential tricks and ways to be speedier (although being slow is sometimes just simply a lack of experience rather than a lack of good practices)

Can ask questions immediately when something doesn't make sense or isn't 100% clear

Working 1:1 is valuable for learning because the person you would ask help from already understands the exact code and scenario as they're working on it, without pair programming you have to explain the code and scenario, which often ends up a problem and so you lose their time/attention on actually getting much needed advice

Get to know the thought process of someone more experienced and seasoned, and with good communications you'll most certainly learn new things

Is there a tactic I can use other than 'be better at coding'? I intend
to bring this up with my supervisor next week.

My advice is to discuss pair programming with the other devs and then approach your supervisor. If they're decent they'll appreciate your initiative which has more chance for you to pitch the pros of pair programming (if they need that, most people know of it and it's common knowledge why it helps).

Honestly who downvoted :( this isn't some wild guess, this happens in my workplace and is proven to work! Incidently, I worked hard on other answers on other questions on this site to be able to have 10 rep (above my associated rep) just to be able to suggest "pair programming" in this one because no-one suggested it. I worked really hard to answer this. — Aug 24 at 10:28

xyious 1335 · Answer 11 · 2018-08-22 16:42:27Z

There are a few underlying problems here. Your problems merging are very likely not your fault and are more commonly a symptom of bad practices.

1) Ideally you would merge your branch into develop every day. Try to have working code at least once a day that passes all tests so you can merge into develop.

2) If you don't have working code at any point during your usual work day you probably have too big chunks of code to work on. You need to break your task up into smaller tasks that can be finished (ideally independently of each other) quicker so that you can merge.

3) Your projects files are likely too big. If there are many merge conflicts for a file there are too many people working on one file. Ideally something one person is working on should be separate from what everyone else is working on.

4) Your team might be too big. If you find it easier to throw away a whole feature and start over, it's likely there are too many people committing code to the same repository.

5) You might not have consistent code formatting standards. If you don't all consistently use the same code formatting you will get many different conflicts for the same code. Depending on how your git is set up these might even come down to whitespace conflicts (line endings, indentation, tabs vs spaces).

6) People might be pushing their changes directly to the develop branch.

Here's what you can do:
1) If you can not merge into develop every day, merge/rebase develop into your branch every day (or more often).

2) Try to have your code separated from every one else's code.

3) Talk to the rest of the team about smaller features, consistent coding standards and better code organization (smaller files, smaller functions).

Ian 4,1031124 · Answer 12 · 2018-08-23 18:46:09Z

It actually seems easier to scrap my work and start over on the task,
which of course is not a sustainable solution)

Most of the time, this is what I do, the first time I fix a bug or make a change to the system, I am learning about how to do it. The next time I fix the same bug it only takes 1% of the time as I now understand the problem.

I also find that when I redo a bit of work, I write better code.....

Hence there is nothing wrong with creating a new branch from the master, redoing your work in it, while using your "private branch" to remind you what you need to do.

It is also possible that you have discovered a way to split your change into logical and correct parts, each that be merged into the master branch once completed. For example, the unit tests and changes to backend code can be done, and merged in. Then in a separate operation, you can do the UI changes that makes use of them, hence have less risk of someone else editing the same UI file.

allo 1393 · Answer 13 · 2018-08-24 12:51:39Z

If you do not want to merge the develop branch into you branch too often, you can get a workflow which is more like svn by using git pull --rebase. This will pull the new commits and rebase your commits on them. This means when you merge your branch into develop, it will be a fast-forward merge (as if you would have added all your past commits at the same time one after another) and not have any merge conflicts, because you resolved them all during git pull --rebase.

But the more commits you make before merging either your branch into develop or develop into your branch, the more complicated will the next rebase get and it subverts the sense of feature-branches a bit, as your branch only exists as long as it is unmerged.

Robert Harvey 161k39371581 · Accepted Answer · 2018-08-17 16:35:04Z

up vote
281
down vote

accepted

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 to have a talk with your team about who's working on what.

If you run it daily, you probably won't need the interactive part. Just let it do its thing.

I'm a fairly experienced developer, and it still takes me quite a bit of time to get up to speed on a new project. In your case, it sounds like you have several people working on the same project simultaneously, so it's either a very large project, or a new project that's evolving quickly. In either case, don't be worried if it takes you several months to get into the flow. If I switch projects for 2 or 3 weeks and then switch back, it can take me a few hours (or even a day or two) to get fully "back into" a project that I wrote 100% on my own!

In short, don't worry about being slow right now. The way to get better is to just keep practicing. Don't be afraid to ask other developers about aspects of the projects you don't understand.

edited Aug 17 at 16:35

Robert Harvey

161k39371581

answered Aug 17 at 13:23

Jacob Robbins

1,896155

22

I guess this is the correct answer, but, IMO, just another example of bad Git design and terminology. Just what are you "rebasing"? Shouldn't this be called "update" or "checkout" or "merge" or some such??? (An answer below argues for "fetch") What's the point of source code control if every day you are forced to update???
â€“Â user949300
Aug 17 at 18:26

93

It isn't updating or checking out though. It's taking whatever is exclusively in your branch, and adding your changes as if you just now made them on the other branch. I.e. your changes are now "based on" the other branch. Furthermore, there does not exist any magical source control system that knows your code and can know how to merge changes when multiple people modify the same files. You update every day to keep the conflicts small and manageable, and the changes fresh in everyone's minds so they know how to handle them.
â€“Â Vectorjohn
Aug 17 at 18:51

53

@user949300 rebasing is distinct from merging, is much more nuanced and requires a better understanding of Git than a simple merge workflow. That's why I never recommend a workflow involving rebasing to a Git novice, because it leads to the assumption that rebasing is the only/default way to update a branch and leads to lots of unnecessary pitfalls and pain. In this case, merging will solve the problem in the same way and neither will solve the problem of merge conflicts in two long-running parallel feature branches.
â€“Â Ant P
Aug 17 at 20:44

13

@user949300 git pull which is just a combination of git fetch and git merge (or you can add --rebase to do a rebase instead of a merge). Assuming you're only about a day behind, then on a LAN this will likely complete in less than second, it might take a couple seconds over the internet. Even over the internet and with minor merge conflicts, you can typically be up-to-date and merged cleanly in less than a minute. Spending five minutes spread throughout the week is a lot better than spending an hour at the end of week dealing with a gnarly merge conflict.
â€“Â Derek Elkins
Aug 18 at 1:15

60

No upvote from me because this answer is entirely fixated on rebasing. Rebasing can be a useful tool, but it should never be used mindlessly. For the day to day updating it's better to merge. Why? Because every rebase is a lie. You are telling history in a way it never happened. This can totally screw mighty tools like git bisect: The rebased stuff may not even compile, so git bisect is worthless on the resulting broken commits. @maaartinus: I, for one, prefer true history over linear history. If you rebase, you absolutely must check every new commit for sanity to avoid harmful lies.
â€“Â cmaster
Aug 18 at 8:46

Â |Â
show 31 more comments

Ivan Anatolievich 1,307113 · Answer 15 · 2018-08-17 12:49:28Z

up vote
129
down vote

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

answered Aug 17 at 12:49

Ivan Anatolievich

1,307113

9

This is coding 101 stuff as you mentioned. Not necessarily an accurate reflection on the new employee.
â€“Â Mister Positive
Aug 17 at 13:26

2

@Ivan Anatolievich OP says that they're branched off of develop, not master, FYI
â€“Â Matthew FitzGerald-Chamberlain
Aug 17 at 14:50

6

This answer shows exactly why I don't like GIT: it's again another tool for teams to avoid having a proper management and decent planning. The answer to everything is "who cares, you can always use that command later", instead of avoiding problems before they happen.
â€“Â motoDrizzt
Aug 20 at 10:29

7

my first thought was also a sign of bad practices, devs shouldn't be working on the same files for the most part. If a small project is having this many conflicts, everyone else must just be resolving conflicts all day long without doing any work!
â€“Â Aequitas
Aug 21 at 5:44

13

@motoDrizzt What? I have never heard anyone make that argument.
â€“Â jpmc26
Aug 21 at 15:56

Â |Â
show 4 more comments

Rowan 1,03916 · Answer 16 · 2018-08-17 14:54:57Z

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.

I think you hit the nail on the head with the co-worker conflict. Merge conflicts are a regular thing, but they are generally limited to a handful of files. — Aug 17 at 15:23
This sounds like a corollary to Conway's Law, and the Single responsibility principle -- i.e. that if people are working on different problems then ideally they'll be editing separate parts of the source code. — Aug 17 at 17:04
While I agree that a poor process or poor design can lead to a large amount of conflicts, I'm pretty confident that the issue is simply that the OP isn't merging in the mainline regularly. I don't agree that "taking full and complete ownership" of files is appropriate as a matter of course. I don't want my team having a constant overhead of keeping track of who "owns" what now, asking "permission" to make changes, or guessing what files they should "claim". Only rarely, when significantly rewriting a component, have I asked team members to inform me if they were going to change certain files. — Aug 18 at 0:40
ChrisW has the right idea with what I was driving at. Generally speaking Ownership in my company takes the form of application functionality, I take complete ownership of the Search Filter system as a task and as it happens, nobody else needs to touch the related files under most circumstances. My feeling is that it's very likely OP as a new starter has been given minor parts of tasks closely related to an ongoing set of tasks by another dev. Meaning the other dev is working in the same part of the codebase and they're getting in each other's way. — Aug 19 at 12:04
@Rowan Cool yeah I thought as much. Functionality separation can also help with file separation (sets of functions in different files etc) and this IMO helps with merging. — Aug 22 at 9:43

gnasher729 18.3k22452 · Answer 17 · 2018-08-17 21:06:54Z

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.

Feature branches present themselves like another form of tech debt, where up-streaming changes from the parent branch is like refactoring. — Aug 22 at 17:32

score 15 · Answer 18 · 2018-08-24 12:45:56Z

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 getting the same conflicts over and over and have to review them manually. You can end up fixing the 13th commit and feel like you can't see light out of the tunnel.

By my experience, when I attempted to naively resolve repeated rebase conflicts I ended up losing someone's modifications or with an application that did not even compile. Often I and coworkers did a lot of work but became so overwhelmed by the complexity of repeating conflicts that we had to abort and lose our previous work after a handful of rebase commits.

I am going to suggest you a few techniques but they can only help the merge get easier than automate the task.

Resource/language files. If you have additive changes to a resource file, make sure you always move them to the end of file so that you can easily recall your changes against others' changes. You may be able to copy&paste your changes on the bottom, or just remove the conflict markers

Do. Not. ABSOLUTELY. RE-format. Neither you nor your fellow developers shall perform a "massive code reformat" during daily work. Code reformat adds an excessive number of false positives in conflict management. Code reformat can be done
- Incrementally, e.g. by every developer on every commit, as soon as they use an automated tool (e.g. Eclipse has an option to reformat on save, vanilla Visual Studio has none). Absolutely every developer must use the same code formatting standards, coded into a format file that is eaten by your IDE. To give you an idea, if it's 4 spaces or 2 tabs it doesn't matter, but it really matters if everyone use the same.
- Just before release, by a team leader. If a "code reformat" commit occurs when people are not working on branches, i.e. before they branch, things will make easier

Review the work splitting between coworkers. This one is the part where most engineering comes. As pointed by other answers, it is design smell if multiple developers doing different tasks have to touch the same resources. You may have to discuss with your team leader about what part is to be modified by each concurrent developer.

I also have seen some bad habits in Git workflows in my teams. Often people overcommit to their branches. I personally witnessed a developer adding 10 to 20 commits labeled "fix", each committing one or two lines. Our policy is that commits are labeled with JIRA tickets to give you an idea.

@JacobRobbins suggests to make git rebase a daily task. I would like to push his approach forward.

First, use rebase once just to reduce the number of commits to a handful. And rebase only onto the original develop branch, which is the commit you have branched from. When I say handful, I could mean 3 or 4 (e.g. all front end, all back end, all database patches) or any humanly-reasonable figure. After you have consolidated them, use fetch and work your rebase over the upstream branch. This won't save you from conflict unless your team reviews their own approach, but will make your life less painful.

If you have additional questions on the specific tasks, feel free to search and ask on Stackoverflow.

[Edit] about the no-reformat and boy scout rule. I have slightly reworded RE-format to highlight that what I am meaning is the task of formatting from scratch the entire source file, including code that was not touched by you. In opposite to always format your own code, which is perfectly boy-scouty, a number of developers, including myself, are used to reformat the entire file with the IDE's capabilities. When the file is touched by others, even if the affected lines are not changed in their contents and semantics, Git will see it as a conflict. Only a very powerful language-aware editor may suggest that the conflict is only related to formatting and auto-merge the best-formatted fragment. But I don't have evidence of any such a tool.

After all, the boy scout rule does not mandate you to clean other people's mess. Just yours.

It is largely a matter of opinion, but I disagree that merge conflicts are easier to handle than rebase conflicts. When you rebase, you essentially apply commits one by one, keeping the scope of the merge conflicts much smaller and easier to follow (you apply YOUR changes that you know - not someone else's changes that you don't). You may have to solve more merge conflicts this way (due to touching the same files multiple times across commits), but they will be smaller and easier to tackle. — Aug 20 at 3:39
Regarding reformatting, while VS can't do it automatically on save, if you set "When I paste" to "Indent and format" in "Tools" --> "Options" --> "Text Editor" --> "<Your language of choice>" --> "Formatting", that means it auto formats on paste. This allows the sequence of three keystrokes: ctrl-A, ctrl-C, ctrl-V to have the desired result. That said, +1 for Do. Not. ABSOLUTELY. Reformat. Except as you outline under very carefully controlled conditions. — Aug 20 at 18:32
Bob Martin readers should note that the Boy Scout Rule must be applied with restraint if you are working in a team (if you are working on your own, you have much more flexibility). If you interpret the rule as "It is my duty as a coder to fix literally everything in every file that isn't perfect the instant I find out about it, nevermind what anyone else is working on.", you will end up with a gigantic amount of hard to resolve conflicts, and it will be a giant mess no matter how good your intentions are. — Aug 20 at 19:35
You you feel a need to reformat or lightly refactor the code, do it before or after your meaningful commit. It will not only reduce conflicts, but also helps future reader of your commit, including reviewers — Aug 21 at 7:16
From my C# culture, "re-formatting" means the action of formatting a whole code file or even entire repository where formatting is only related to readability. If your language uses whitespace meaningfully, you shouldn't mess with whitespaces in LOCs that are not your own. Conversely, your language of choice may still allow non-meaningful whitespaces (e.g. before a brace) that can be "reformatted" according to a readability standard — Aug 21 at 13:18

Peter Mortensen 1,11621114 · Answer 19 · 2018-08-19 00:48:09Z

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.

Also before merging, a git fetch and git diff origin/develop will show you a preview of your merge (sort of). Gives you a chance to clean up your changes before you get a ton of pointless conflicts. — Aug 21 at 13:12

trichoplax 11716 · Answer 20 · 2018-08-28 15:53:08Z

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

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

If there are too many conflicts, your task may be a minor one, but repetitive. Try to find a pattern. This would help in resolving conflicts by the Git UI client tools. I use TortoiseGit. It helps in merge.

And for avoiding in the future,

It's a very good practice to merge the develop branch regularly to your feature branch.

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

+1 The other suggestions for using Git better are good, but actually talking to the other developers about merge conflicts is another key aspect to develop OP's effectiveness. — Aug 20 at 15:41
"You can see the history" Maybe! Depends how squashed & rebased everything is :P — Aug 22 at 10:43

PeteCon · Answer 21 · 2018-08-17 13:03:11Z

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.

I'm not sure this is correct. Git fetch will get remotes/origin/master up to date but you then need to merge remotes/origin/master into your feature branch (Or remotes/origin/develop if that's the flow they are using) — Aug 17 at 13:10
Assuming he's using git, it's also a good idea to learn how to squash your commit to meaningful parts. That way when you're ready to make a pull request, your commit is lean and straightforward and easy to understand. — Dan, Aug 17 at 13:10
@RichardTingle Correct, He's thinking of a rebase option. You simply fetch & rebase your branch with the dev branch. That will sync up everything. — Dan, Aug 17 at 13:12
@Dan I think that may be a matter of opinion. Personally I hate massive commits. Try git bisecting that! — Aug 17 at 13:12
@PeteCon "and bring them into your feature branch without attempting to integrate the changes into your branch". That seems like a contradictory statement. I think you mean bring them into your local repository without integrating them into your feature branch, but I'm not sure how that helps... — Aug 19 at 1:03

Kafein 1372 · Answer 22 · 2018-08-20 16:23:24Z

Obviously first thing is to avoid having multiple people work on the same files in the first place, at least in a way which leads to difficult conflicts. Adding things into enumerations is no problem as long as a good code format is used. Changing control flow in different ways and moving code around is vastly more tricky. Sometimes this is inevitable nonetheless. You'll need to ask questions when resolving conflicts that are truly complex.

That said, I see many answers recommending to merge/rebase onto develop regularly. I would be much less enthusiastic about that sort of advice. Your goal at this point is to make the conflict solving process as easy and safe as possible. One thing which is going to help tremendously with that process is to have as many regression tests immediately available, including the new ones that are part of your new feature. If you synchronize your branch very regularly with develop, you will invariably end up having to resolve conflicts while you are half done actually implementing your feature. And that means that it will be much more difficult trying to figure out what the code is supposed to do, as you weren't done with it. Before attempting to merge, make sure that your branch is a coherent unit of change. Even better, rebase it into a single commit before merging.

I tried not to go into the merits of rebase over merge which is probably for another question. In this context the tools don't really matter.

James 15814 · Answer 23 · 2018-08-22 10:30:22Z

By the time I'm ready to merge my branch back into develop the others
have made so many changes that resolving the conflicts is overwhelming

This sounds like an ideal scenario for pair programming!

More info about the benefits and basic approaches:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

You will naturally speed up over time from working on your own, but it can be daunting until that time comes, and is a long haul sometimes too. Also, while people can learn quickly being in a stressful environment always pressured to catch up, others who don't learn well under constant pressure will be hindered.

Instead of working on a branch on your own and trying to keep up with other devs who are obviously much faster than you, you'd instead work directly (same PC) with another dev. This way you get instant advice and will probably pick up tips how to speed up etc.

You'd have figure out the best approach for the particular code in your project, as pair programming doesn't always makes sense for some projects - although it arguably always makes sense for learning even if you just sit and watch someone more experienced than you (as long as they're a good dev, experience doesn't necessarily mean they use good practices).

Sitting with a faster, more experienced dev has potential to help by:

Will likely reduce merge conflicts as working with someone more experienced will increase the completion time as opposed to your working alone

As they'll be teaching you it's likely they will be slower than they would be working alone, so there may still be some merge conflicts and so can work through them with someone seasoned and so perhaps pick up some tips on saving time etc

Help you see potential tricks and ways to be speedier (although being slow is sometimes just simply a lack of experience rather than a lack of good practices)

Can ask questions immediately when something doesn't make sense or isn't 100% clear

Working 1:1 is valuable for learning because the person you would ask help from already understands the exact code and scenario as they're working on it, without pair programming you have to explain the code and scenario, which often ends up a problem and so you lose their time/attention on actually getting much needed advice

Get to know the thought process of someone more experienced and seasoned, and with good communications you'll most certainly learn new things

Is there a tactic I can use other than 'be better at coding'? I intend
to bring this up with my supervisor next week.

My advice is to discuss pair programming with the other devs and then approach your supervisor. If they're decent they'll appreciate your initiative which has more chance for you to pitch the pros of pair programming (if they need that, most people know of it and it's common knowledge why it helps).

Honestly who downvoted :( this isn't some wild guess, this happens in my workplace and is proven to work! Incidently, I worked hard on other answers on other questions on this site to be able to have 10 rep (above my associated rep) just to be able to suggest "pair programming" in this one because no-one suggested it. I worked really hard to answer this. — Aug 24 at 10:28

xyious 1335 · Answer 24 · 2018-08-22 16:42:27Z