Git - Merging changes from one feature branch into another between developers

Question

In general, our code is quite modular so developers are not making changes to the same files at the same time. But, I have run into a situation and I see two ways to solve it, so I'm looking for opinions on which is the best way and why (or additional solutions). My coworker made changes to some files in his feature branch which I would like to use in my feature branch. These are separate features, not a shared feature branch. I see two solutions:

1) He can merge his feature branch into develop and push to the origin. I can then pull the develop branch and rebase my feature branch onto it locally.

2) I can merge his feature branch directly into mine.

I don't really like the latter because it just seems off; merging a feature branch into a feature branch directly when the two features themselves don't relate, just a couple of the dependencies do. So, I went with the former, but for future reference I am curious how others would handle this situation.

Answer 1

What you do in git is just a reflection of the development process.

1) You don't need to rebase your work on the develop branch just merge the develop branch into your working branch. If you rebase you can't share your work.

2) You need to incorporate his work but he is not ready to push to develop then there is no technical problem with you merging his work in. Just beware you may be incorporating beta work!

This isn't a git problem you are just depending on work that is not finished yet, happens all the time you just need to keep regularly merging in the other developer's's work until he is finished.

Answer 2

I understand your instinct to prefer the first solution, and I think it's the right way, because:

• The other developer will merge his own changes onto develop. This is very natural: he merges his own changes, and if necessary, resolves his own conflicts.
• When you rebase on top of develop, you effectively merge your own changes, and if necessary, resolve your own conflicts. Again, this is very natural and intuitive.

In the other alternative, you will merge his branch to yours, and maybe you'll have to resolve his conflicts. And that's actually just the tip of the iceberg, because even if the merge passes without conflicts, what if the build breaks? Or what if the build is still ok, but now the program has some weird behavior? The other guy would know best how to handle these issues.

When the original developers merge their own changes, they are responsible to keep everything working: resolve conflicts, make the build pass, make the tests pass, validate the changes, resulting in a package that's ready to use by others and fully functional. This way the next developer working on top of the well-validated branch can safely assume that if something is not working after his change, the cause must be his own changes.

I use this daily. I'm very comfortable merging my own changes or my team's changes, because I know what they are about. I hate to merge other team's changes (if ever I have to), because I don't know what they are about and how to test the result.