Collaboration with Git
There’s no straight line to becoming a programmer, but everyone will have to come to terms with using Git and version control at some point. If you’re going through a coding bootcamp as I currently am, Git probably does not register as very relevant to you amid the sea of unfamiliar terminology and missing closed brackets you now find yourself in.
I know at one point I thought repeatedly typing
git add .
git commit -m “another commit”
git push origin master
seemed like just another one of those unexplained programming rituals you come across in this field, like setting “foo” equal to “bar” or putting “Hello World” into a file that no other human being will see, ever. Instructors/ tutorials/other programmers may tell you that it’s important to get into the habit of git commit-ting early and often, but as beginner projects are so small in scope, and the code you’re writing barely works anyway, there doesn’t seem to be any point in stopping to repeat the sacred git words after every new few bloated function you write.
Git really won’t make your life easier until you begin writing code with other programmers. Even though I prefer to think of myself as an autodidact, I chose to learn programming through an in-person coding bootcamp for the purpose of learning how to work on complicated projects with large groups of people. I was fortunate to be in a “pair of three” for my first paired programming project and got a lot of valuable experience with the power of version control, which I’ve discovered should be applied to coding outside of collaborative tasks.
You don’t have to work with code, however, to understand why Git is such a useful tool.
Why even use Git?
At my previous job as a program assistant in an organization of less than a dozen people, there was a strongly encouraged ethic of collaboration [ie poor leadership]. This meant that very often we were all encouraged to write, edit and contribute to word documents as a group using tracked changes.
Imagine writing the first draft of an important letter, then sending it off to one of your managers, who forwards it to your boss, who edits it on an iPad and forwards it to two other people in your office simultaneously. Some time later you begin noticing some discrepancies in the filenames you see attached to the emails you’ve been cc’d on now cluttering your inbox. You realize that there are at least now two different versions of the document, only one of which has made its way back to your boss for further edits. That great closing paragraph you wrote has vanished, save for a dependent clause that’s awkwardly sandwiched between two sentences you’ve reread twice and still don’t understand.
Thankfully tracked changes was enabled, so you have something approximating a record tracing the path from your original prose to the bloated bloviation the letter had become, but you only have the option of viewing the document in its current form, or with all of your colleagues’ contributions combined into a jumbled heap of red and black text.
You decide to jump into the fray and edit the document just based on its current version and cc everyone trying to get the office back on track. Your bosses like this initiative because they don’t know that the phrase managing up is mostly used pejoratively.
Shortly thereafter there’s been a staff meeting called to sort this mess out. Your edit didn’t include a very important statistic that somehow got deleted in a previous version, and it needs to be amended anyway. This very important letter needs to go out that afternoon, so there’s no time for messing around anymore. One manager is designated to add a paragraph about something meaningful and then give it to the office manager to be sent out.
You think everything’s resolved but now there’s a stressful e-mail exchange over which document actually constitutes the latest version, since by this point the document also exists in multiple versions in various inboxes, local computers, and of course the shared drive (and there’s still some confusion over which folder it should be in).
You put your head down and pretend to work for the rest of the day while you let the other cooks in the kitchen handle it. You start thinking it’s time for a career trajectory change.
Now imagine that that letter wasn’t a word document, but an application consisting of hundreds of files of miles of lines of code wherein a single comma out of place could conceivably render the entire app unusable — in production it could grind an entire company to a halt. A code base is much larger in scope and expected longevity, so having multiple developers with different skillsets working on it is not only likely, but practically unavoidable.
It’s not hard to see how easily the development process could go awry with that many minds involved, and that’s why git and version control is so valuable.
Despite all the ambiguous terminology (fork vs branch vs clone), Git performs several basic but incredibly useful functions:
- It allows you to keep a record of and restore different versions of your code at any point in its development.
- With github, you can also have a remote backup of your information.
- You can share your code with other developers and vice versa and track and review all of the changes your collaborators have made.
Working on a project of even small scale taught me several lessons for managing a code base during its development. I won’t claim to be an expert in using Git right now, but hopefully I’ll be able to write a more detailed explanation of git workflow when I’ve had more experience, but here are my main points of advice for using git with others.
1. The Master Branch is Sacred and Should be Treated as Such
Your master branch should always contain a working version of your program — the version that you could show to someone at a moment’s notice without needing to apologize and explain that “it was working just fine yesterday.” Branch out. Want to add a new feature? Add a branch — get it to work — merge — delete the branch — pat yourself on the back, move on to a new branch.
You wouldn’t want to blow up someone else’s perfectly functioning app, so don’t do it to yourself, either.
2. Only Commit What Works
Be sure that you don’t save any work-in-progress code, because you WILL be interrupted and you WILL inadvertently merge it into your master branch in direct violation of rule one. While git add .is usually a helpful shortcut, if for some reason you need to push part of the code you are working on with a group, but have changes that are not fully implemented, make sure to unstage them using git reset -- the_file_you_want_to_unstage
If you make yourself be more deliberate about what changes you are tracking using git add you will also become a more focused and effective programmer in the process.
3. Make Your Commit Messages as Short but Detailed as Possible.
git commit -m “committing is a big redundant. Write a little more info not just as a courtesy not only to your colleagues, but also to the future version of you (honestly, you have no idea what you’ll have been through). “Refactoring” “fixed a bug” “oops” “added some new stuff” will not help anyone when trying to figure out who broke the code (we all know it was you, anyway) or where to look when fixing bugs down the line.
Whatever organization you end up working for will have conventions for you to follow, but get into the habit early of following your own convention. I’ve been trying to always include the name of the file/class/method or whatever it is I’ve changed since my last commit, for example:
git commit -m "Refactored SomeClass#some_method"
That way anyone reviewing the history of changes to some_class.rb will be able to quickly understand the changes in the commit without having to manually review the code changes.
These recommendations will make working with others on git a much smoother experience, and if you implement them on working on solo projects you’ll be more organized and less frustrated, as well.
And isn’t that a goal worth working towards?
