This article is part of a series that focuses on converting my Windows application to cloud-based web apps and services.
When I first started writing my app using Visual Studio, it was just me. I would code up whatever I felt like for the day and then save my work. Every few hours, my computer would go through a differential backup. The backup gave me peace of mind, and I did not feel it necessary to use a version control system until, that is, it was time to release and then update my product. Git is a technology that has been around for a while now, but it was entirely new to me. I had the opportunity to speak with plenty of developers who went right over my head using terms I was not familiar with, so hopefully, I can help a little bit in this article.
A friendly broken-record-style reminder: I am a developer who just recently pulled myself out of client-server software development. I am learning, and this is a journal of what I learn, and it may not always be 100 percent accurate.
Gitstory
Git is a version control system (VCS) originally developed by Linus Torvalds. Legend has it, Linus created Git because the Linux open-source community was using a previously free product that started charging a fee. Linus decided to create his own VCS that would be distributed and not require a central server.
As with Linux, Linus made Git an open-source project. Any company can incorporate Git features into their products. Apple allows you to create Xcode projects that use a Git repository, Visual Studio supports Git, and of course, there is the well-known GitHub. Do not confuse GitHub for Git. GitHub is a for-profit enterprise that allows you to use Git freely for open-source projects or for a fee to anyone that wants to protect their code base.
It turns out Git came at just the right time. As software developers and engineers continued their march to Agile methodologies, Git freed up developers to use a simplified VCS (simplified being a relative term).
Git for one, please
While I do work with other developers, I do not let them access my complete repository of code. The reason I do not share the code is that I hire freelancers who have a very particular skillset I do not have. These freelancers could download my code, add their own, and then submit it back to me, but the idea of giving full access to my codebase to someone I never met sounds like a bad idea.
The fact I manage the code myself does not mean Git is overkill. On the contrary, Git is still a great solution for independent developers because they can manage their code, track issues, and manage changes. At first, I was confused by the whole process, but after a while, it all started to become second nature to me.
Gitionary
In Git, there are a few important terms for you to learn. Here is how I define the terms:
- Clone and cloning — Every software project has a repository. You can technically modify the code in that repository from the VCS, but most people clone a copy. Cloning is essentially the process of creating a personal copy of the code. You can change the code all day long and never once affect the original code.
- Master, repo, and origin — Let’s say you create an open-source project on GitHub. That project is the master. If I clone a copy of your work onto my computer, then that is a repo. Since I can make any changes I please to that repo without ever submitting the code back to you, that repo is considered to have a master as well. The origin project is a pointer back to your GitHub project.
- Branch(ing) — When you want to modify the code, you create a branch, make your changes, and then merge the code later after you perform a pull request. You can also use branches to create whole new versions of a product so that changes can be very small or quite large.
- Pull request — I had a hard time with this because when you submit code, you are pushing it up the chain to someone else, so why call it a pull request? Let’s say you own a project on GitHub. I clone a copy and make some changes. To share these changes, I send you a pull request. I am making a request that you to pull my code and review it.
- Merge and commit — After you create a branch and send your pull request, collaboration can occur. One or more developers can review and even modify your code (maybe there’s a bug, maybe it can be improved, etc.). The hallmark of a good Git system is the ability to allow this collaboration and code tracking by teams of people, so only the best code gets added to the master codebase. That master codebase gets an update when you merge and commit your changes. Now, the end product will have the new code contained within.
There are more terms to learn with Git, but these are the ones that took me a while to figure out
When to get Git
Git is really for anyone who is doing any development. Even if you are a sole developer working on a small project, there is no reason you should not use a VCS, and once you get familiar with Git, it is quite easy to use. You will need to think about how you will use Git to manage various versions of your product and have a branching strategy, but I suggest you start using it first and figure out the details later.
Creating a branching strategy is important to how you manage your project. Do not just read the first one or two articles that come up on a Google search, because you will run across some good and bad ideas. Instead, you will want to formulate an approach that works for the particulars of your project. While I am not yet doing this, I do recommend you join some projects on GitHub and start contributing to get a sense of how it works.
Git is not just for software code. Since Git is not much more than a text-based VCS, you can maintain documentation, FAQ’s, and much more.
You will find there are two camps in the Git community. There are the camps that love using the command line and those that love working with a user interface. I get the clear sense that most developers prefer using the command line, but for me, getting started was much easier using the user interface.
Photo credit: Flickr / verkeorg
