How to Use Git

01 April 2018

Hello there, developer. It's time to learn about G.I.T., the version control software used by cool-but-smelly hipster developers. In this guide, we'll learn the best G.I.T. practices in complicated, large-team scenarios.

What is G.I.T.?

G.I.T. is a version control software, so it's like any other version control software you might've used in the past. Feel free to use it like it's CVS, Subversion, ClearCase, TFS, or anything else! It really doesn't matter. Emoji smiling face!

The Recommended Approach

For large teams, the following approach is what we've found to work best. Please note that we have only experimented with this approach, and haven't been compelled to try another approach because it just seems to work so well.

Infinite Indefinite Branches

This just sounds cool, so we went with it, even though we don't really know what it means. In practice, we've found ourselves only maintaining two indefinite branches, but you could extend this and have as many indefinite branches as you wanted. These are branches that'll go on until the end of time—you'll live forever through your commits, so strive for as many as you can!

While you can have as many indefinite branches as you want, you'll definitely want the two types of branches we have. We have a master branch, where all development is done, and a Release branch, where all the code in the next scheduled release lives.

The master Branch

Developers are free to update master as often as they want and however they want.

• Want to make sweeping changes that are far beyond the scope of your task? No problem—merge conflicts are fun!
• Don't want to test that your random refactors at least maintain basic functionality? Go ahead—if QA doesn't catch any errors, that's their problem since it's their job anyway!
• Developing on the master branch is great, because you can implement your changes using code that hasn't been released yet—it's like you're coding in the future! The best part about this is that, as time goes on, you're using more and more unreleased code, and you may not even know it! Neat-o!
• We also would like to suggest that no one on your team tells anyone else about what changes they've made (make all your changes a delightful surpise!), and developers should try to complete tasks without any code review when they can so as not to busy up anyone else.
• Oh, and make sure to track all generated files! This will keep development convenient by shaving off a couple of seconds by not having to manually regenerate files locally!
• Don't provide commit messages that describe your changes other than what you feel like expressing—who are you to decide what message describes a commit?

The Release Branch

Yes, this branch is named in PascalCase while the master branch was named in camelCase. Inconsistency is fun! When it comes time to release the next version of the project into the production environment, you'll probably need to try to get the changes made in the master branch into the Release branch (but this is not always the case: sometimes you can just tell people that a feature was released without actually having to release it—it's like magic!). When you do have to actually release a new set of features and bugfixes, make sure to follow these nice tidbits of wisdom we've gleaned:

• Have none of the people that initially coded the features be involved in the process. Seeing code through to the end of its journey isn't the responsibility of a developer—a developer 'develops', not 'completes' (otherwise they'd be called 'completers')!
• Use cherry-picks as the sole means of getting changes from the master branch to the Release branch. Instead of using some kind of process where each feature is implemented on its own branch and then merged, this approach means we can cherry-pick each of the individual commits that were made on a task. Cherries are delicious—pick as many as you can!
• If the work implementing a feature was done in multiple commits, know that you don't need to cherry-pick in chronological order. For any merge conflicts that you don't feel like resolving, just take the source everytime—it doesn't matter!  Likewise, if there were two tasks, task A and task B, and task B makes changes to changes introduced in task A—again, it doesn't really matter if you cherry-pick task B first. Nothing matters, because God is dead!  

Conclusion

In this short guide we have covered everything that G.I.T. is best used for and described the ideal version control development process. The best part of this process is that the branches will diverge farther and farther as the master branch ends up with more and more unreleased code and the Release branch gets more and more cherry-picks resulting in more and more interesting histories. This is totally a sustainable model, and we highly recommend it to anyone.

Please don't actually follow any of the advice in this post.