In my team, we use git branching to keep different features separate (of course). However, one co-worker insists on keeping these features in different files as well to avoid merge conflicts. For example, we may have a FormView.java on master, but in have both a FormView.java and a ValidatedFormView.java on the form-validation branch. I suggested that rather than duplicating files to "work around" git, we should let git do its thing and merge features when we want to. He also wants to keep duplicates in order to be able merge some parts of a feature into other branches without having to deal with merging the FormView.java file itself.
What should we do? If he is right, why? If I am right, how can I convince him as such?
Top comments (7)
What. The. Actual. Fuck.
There are so many things wrong with this. If your team is encountering merge conflicts on that regular basis, perhaps you need to start splitting work smarter so you're not working on exactly the same parts of the code at the same time.
Yes. I encounter merge conflicts on a regular basis (maybe once every day or two) and they are there to stop stupid things happening. You need to teach this guy how to Git properly, as merge conflicts are not a bad thing.
Sack him. No, I'm joking. But your team needs to sit him down and get him to work in a more effective way. He's working as part of a team, and he needs to start acting like it.
What he's trying to do may have merit if there was a case where you want to preserve the original behavior of
FormView, and you want to useValidatedFormViewas a special case in a different context. If that was the case, then yeah, it's fine if you introduce that as a derivative that lives alongside the original (base class).However, it sounds like this is not the case here. He is trying to rework an existing component. And he uses that approach as some kind of version control within version control.
I don't quite see how he truly gets around potential merging issues with that approach, though.
His alternative derivative classes still need to be registered somehow with the main application, so something that uses and references those forms needs to be changed from:
to
It wouldn't make much sense to also introduce a
ValidatedController.javabased onController.javajust to get around that merge issue. Where does that end? A complete rewrite of the entire application just to introduce a new feature?Second of all: Let's assume he has it his way, and a new fix or feature extension needs to be slapped on his
ValidatedFormView, what would be the name for that? Will class names grow longer and longer? Are we going to have:FormViewValidatedFormViewFixedValidatedFormViewAsynchronousFixedValidatedFormViewdown the road, sitting there side by side?
I think your team probably needs some serious kind of discussion about establishing a standard for development workflows and integrating new features. Have it in writing, and make sure that everyone follows those rules.
When it comes to dealing with your colleague here, it sounds like he's actually afraid or unable to handle merge conflicts properly. There must be a reason for that which should be addressed. Maybe a lack of training or understanding of the available conflict resolution tools provided by Git.
Maybe your overall workflow causes merge conflict situations too frequently, and he acts out of frustration?
Those issues can be addressed. When a feature branch lives too long and diverges from the mainline branch too much, then make sure to rebase (or merge in mainline) often. At least once a week for example, so Git can do its automatic merge magic more easily, and in case of a merge conflict it's not too overwhelming to deal with in small doses.
If those conflicts happen in shorter periods of time, then try to coordinate work on certain parts of the system better. Make him the sole responsible person for
FormViewuntil his feature is ready, and no one else is allowed to touch it.On the first point, you're right, with the possible exception of your software needing to use one or the other of the variants (this approach is one way to do feature flags for big stuff, the problem is that it makes each feature managed this way mutually exclusive, which may or may not be a good thing depending on your software).
The correct way to mitigate merge conflicts is to regularly update the feature branch so that it's in-sync with the upstream branch it's based off of, either via rebasing (generally preferred if you're working on it solo, because it makes it easier in many cases to figure out how to fix what conflicts do arise as well as keeping the history cleaner) or back-merging the upstream branch into the feature branch. If your colleague can't manage to do this, the problem is him, not you.
On the second point, that's easily doable without the duplicates if you do your development right. Provided that each 'part' of the feature is a commit, you can easily merge in just some parts using
git cherry-pick(that's exactly what cherry-picking is for actually. You should be developing this way anyway though, because it makes tracking down bugs a hell of a lot easier (git bisectis a wonderful tool, but it's useless if every feature is just one big commit (even more so in cases like this where you're keeping duplicate files)).As far as convincing him of this, I would start by sending him through a proper course on how to use git. Most people who think this way were never actually properly taught to use version control correctly (or they were taught on classic monolithic VCS platforms instead of DVCS platforms). If you're lucky, that should be enough for him to figure out that you're right, and if not, it will at least make sure he's on the same page in terms of what git actually does.
Hi Friend!
If I understand situation properly, of course your position is correct. Git is clever enough so no such additional precautions are needed. Moreover it is more hindrance than help - you will lose ability to easily check differences between versions of file (you still can compare files, of course, using IDE features for this - but it is awkward anyway).
Then at some point file in the master is updated (perhaps someone have completed feature in some other branch and merged it) - you now need to merge this update to your branch - but git won't understand this, as this is different file. Well, you can work around this, but anyway it is difficult.
Moreover, imagine merge between two branches (without merging to master) - e.g. for creating deployment for tests. Files will have different names in both branches, say
ValidatedFormView.javaandImprovedV3FormView.javaand git will think it is a conflict that you are trying to rename file in two different ones. You'll need to resolve it manually.I don't like it because git is complicated system and "workarounding" it may create a lot of mess, especially when changesets are large (perhaps, several files).
how can I convince him as such?
Well, if person is doing something wrong, it is not always easy to help him switch to the proper way. His way is not disastrous, so your team can continue this way, though it is wrong and somewhat painful. Whatever reasons you'll give, he can point some workarounds.
So you should try your best. Be friendly, propose asking for mediation from some other colleagues or from internet (here or stackoverflow). Suggest creating question at stackoverflow by you both, in co-authorship. It is important to remember that your colleague suggests his way not because he is evil or silly. He wants the project to be more safe. But probably with more experience he later may see that "manual version control" in this manner won't really increase safety.
Your co-worker is wrong. Period.
Git is a tool to support you in developing software. You should use it the way it is intended to be used. So again, you're right, the other guy is definitely wrong.
That said, I can understand that people may want to avoid merge conflicts and issues. But in my experience, these are people who did not take the time to learn how to correctly use a tool. I know someone, who is not comfortable with using git an never took the time to make himself familiar with even the most basic things. I don't know about your co-worker, but maybe some kind of Git training would convince him and give him more confidence in Git's capabilities.
We're using Git everyday, happily forking, branching, merging all the time. It works.
This is fundamentally wrong and defeats the purpose of git.
This is not a code issue, this is an organization of work issue.
Your co-worker likely needs some... education...