Not wasting time with version control
Ways to reduce the amount of pain and suffering caused by having to develop code as a team
Don’t fork
Forking is very popular and as almost everyone been told: git makes forking easy.
Git does not make merging easy. The intrinsic complexity of merging code is unchanged by distributed version control. Merge difficulty grows polynomially as the fork ages: for every extra day a fork diverges, it gets twice as hard to merge. This effect is even more pronounced if the team is juggling multiple forks at the same time.
There are two ways to reduce the merge burden. Firstly, limit how far working copies diverge from the master copy. Pull new changes from the master copy into your working copy as frequently as possible. Secondly, to avoid other people’s working copies conflicting with yours, merge your working copy into the master copy as frequently as possible: ideally, after every commit.
Do code review informally, before development begins
Code review after implementation is finished is incredibly wasteful. In the worst case, the entire approach must be redone. Even in relatively good cases the issues that are raised could have been foreseen.
Discuss the exact approach that will be taken on a user story before development begins and establish agreement. If some problem arises with that approach, discuss the second approach too and establish new agreement.
Offer help, not repudiation, when the build is broken
Broken builds are not a sign of personal failure! Whoever broke the build is probably feeling very worried and self-conscious about what others think of them.
A broken build is a crucial moment to provide help if you can. Try to make it clear that you’re not standing over them to make sure they do it right this time but instead are there to share the problem with them until it’s resolved.
Try hard to roll forwards
The social embarrassment of breaking the build causes people to panic and then unmerge or revert their code.
However, it’s normally cheaper in terms of net time spent to insert a quick fix and then refactor at leisure while the build is green. This avoids the lengthy and sometimes complicated process of unmerging and then remerging or reverting and then re-applying changes.
Nothing is too serious to roll back
Sometimes people are afraid to commit code that unfinished or imperfect. They worry that other more experienced people will think less of them when they see the code in the master copy. This behavior is not that unusual: there are likely thousands of useful blogposts that are never published because the author thinks they aren’t good enough to survive public critique.
Version control fear causes many problems. People delay merging their code until it is perfect, increasing their merge burden. They are afraid to commit code locally because the commit history will betray their (temporary) bad variable names.
If your change reduces a race condition from “likely” to “possible but somewhat unlikely” then it is a useful stepping stone on the way to a full solution. It’s really important for everyone to understand that partial solutions get partial credit and that no mistake is so serious that it cannot be undone.