Maybe you only need 1-2 hours to refactor the file. Instead, this might even be a weekly 1-2 hour event until you all get things looking how it needs to be. You may want to set a specific amount of time to this, so that it doesn't end up being a week worth of arguments with no end in sight.
#GIT IT BIG CODE#
Once everyone relevant has their code checked in, find a conference room with a projector and work together to start moving things around and into new files. Have everyone check-in their code who can, then help others who are still working with the file. I'm going to suggest a different than normal solution to this problem. Inform your mates what you are doing, so they know why they have to expect merge conflicts for the particular file. This won't eliminate merge conflicts or the need for resolving them manually, but it restricts each conflict to a small area of code, which is way more manageable.Īnd of course - communicate the refactoring in the team.
The same holds when in step 2 you get a merge conflict because someone else updated trunk in between.
#GIT IT BIG UPDATE#
That way, next time your teammates update their branches from trunk, they get your changes in "small portions" and can merge them one-by-one, which is a lot easier than having to merge a full split in one step.
Repeat step 2 until Foo and Bar have equal size (or whatever size you prefer) Apply the move, update from trunk, build and test the code, and commit to "trunk". Let's say your large file has the name Foo:Īdd a new empty file, Bar, and commit it to "trunk".įind a small portion of the code in Foo which can be moved over to Bar. This isn't so bad until something urgent interrupts this refactoring, the duplication is forgotten or deprioritized, and you end up with a bunch of tech debt.īut in the end, any solution will require you to coordinate with your team.ĭo the refactoring in smaller steps. The cost of this approach is that it's much slower than changing everything at once, and that you temporarily have two duplicate APIs. In particular, there will only be conflicts if someone else is also changing the functionality you extracted. This multi-step process can avoid many merge conflicts. (Repeat for the next bunch of functionality).Finally, you can delete the old functions.Over time, port dependent code to the new API.Change the old functions to forward their calls to the new API.Extract the functionality into a separate module.For example, if you want to extract some functionality into a separate module:
You may also want to prevent breaking large swaths of dependent code and only make API-compatible changes. That's not impossible, it's just avoidable work.
If they wait longer, they'll have to deal with the merge conflicts themselves. But it may be feasible to ask colleagues to merge their changes that impact this file until the end of the week so that you can perform the refactoring. That might be too much for your immediate problem. As soon as the code has been integrated into your master branch, it becomes accessible to the kind of refactoring you are trying to do. If some code isn't yet production ready, it might be possible to integrate it but deactivate it through a feature flag. A development team that is able to rapidly integrate their changes will see fewer merge conflicts. The general rule to fast and easy merges is to prevent big differences from accumulating, in particular that feature branches should be very short lived (hours or days, not months). Development teams tend to launch a lot of branches and are then surprised that merging them is difficult, possibly because they are trying to emulate the Git Flow without understanding its context. This is part of a larger issue with Git, in that branching is very easy but merging can still take a lot of effort. You have correctly understood that this is not so much a technical as a social problem: if you want to avoid excessive merge conflicts, the team needs to collaborate in a way that avoids these conflicts.
0 kommentar(er)
