Gitting Started With Git

What do you use for source code control?

While I was asking everyone I met at NI Week about what frameworks they were using, I also started asking about source code control as well. Almost everyone I talked to universally said they were using some kind of source code control. A lot of people are using Git, a few people we using Mercurial, but I was surprised by how many people were still using SVN.

Why Git?

My general impression is that a large portion of the LabVIEW community has moved away from SVN and towards Git.  We moved from SVN to Git about 3 years ago. It was not painless, but we thought the benefits were worth it.

Now don’t misunderstand me, SVN is certainly better than no source code control at all. In some situations, it may still be the best choice. I think a lot of resistance to moving away from SVN, is “Well SVN works for me and I’ve been using it for X number of years, so I don’t want to invest the time to learn Git.” I used to buy into that argument. I think the best way to beat that argument is to point out the advantages to using Git.

1. Working Remotely – What convinced me to give Git a try was a conversation I had with local CLA Levi Gustin. He was explaining how often he would get called to fix problems at a customers site that did not have internet access. This posed 2 problems, he couldn’t check anything in or out of the repository and he couldn’t browse the log. With SVN, both of those require internet access.  Git solves both of those problems by giving you a complete copy of the repository when you clone it. You can check in all your changes on site and then push them over the network when you get back.  You also have a complete copy of the log at any time.
2. Speed – This became painfully obvious to me recently. I’ve been doing some work for a friend of mine who still uses SVN. When I was using SVN every day, I never realized just how slow it was. As your SVN repositories get larger you are sending more data over the network with every checkin and checkout. With Git, not only do you not need to push over the network every time you checkin, but when it does push or pull data over the network, it does a bunch of optimizing so the speed is much faster.  You notice the speed improvement a lot with log file viewing and branching.
3. No central server – You might not see a central server as a problem, but consider the following:  What happens if your server goes down? Hopefully, you have backups, but until it gets rebuilt you can’t checkin or checkout. With Git, there is no “official” central server. All the cloned copies are peers. They have a complete copy of the repository. So you automatically have a backup built in. Also a developer can just check in locally until the server comes back up and then push everything to the server at that point.
4. GitLab and Github – Both Gitlab and Github make setting up a “central” repository and sharing code very easy. They also have lots of integrations for software engineering tools, such as issue tracking, continuous development, etc.  Both have free plans, so it is quick and easy to get started.

The downside

I would be remiss if I didn’t mention that there are a few downsides to using Git.  The first major obstacle to adopting Git is learning all the new commands. Git is way more powerful than SVN, but that comes at a price. There are a lot of new commands to learn.  To add to the confusion, some of the commands are similar to SVN commands, but are used differently and mean different things.

Another pain point when learning Git is the branching model.  Git makes branching incredibly easy.  This can be a good thing, but it can also cause lots of confusion.  I suggest researching GitFlow, GitHub Flow, or GitLab Flow (my favorite).  Also, tools like Source Tree from Atlassian or gitk make viewing the branch hierarchy a lot easier.  Personally, I just use gitk since it comes with Git for Windows.

NOTE: Read the book mentioned below before you delve into branching models.  It will make a lot more sense once you understand the basics of branching.

I recommend you start by learning the various commands.  The best way to learn all the commands is from the O’Reilly Book:

I recommend reading the book even if you do use fancy GUI tools, like TortoiseGit or SourceTree.  It will all make more sense.  The book has a bunch of examples that you can follow along with.  They are key.  Make sure you do them.  It will really help.

There is also a pocket guide from O’Reilly, which is useful, but I recommend reading the full-size book and then just using the pocket guide as a reference.  You will likely need it.  Note: I own and use both.  The pocket guide is much more convenient for throwing in my laptop bag, but sometimes when I need to dive into a topic, the full-size book has the level of detail I need.

Installing Git

Before you can do many of the exercises in the book, you will need to install Git. I recommend using Git for Windows.  When installing there are a bunch of options. I just use the default.  This will give you a Git Bash (and Git GUI – which I don’t really use) option for the right-click menu in Windows.  It will also give you gitk which you can access from the Git Bash shell.  It’s quite useful for viewing different branches.

The other tool I like to install is TortoiseGit.  I do most of my git work from the Git Bash command line using Git for Windows, but I do like Tortoise for the icon overlays.  It lets me easily see at a glance what if anything has been changed.  I also like it for the diff/merge feature.  You set it up just like TortoiseSVN.  I don’t use it a lot, but sometimes it nice to see exactly what someone changed.  It works very similarly to Tortoise SVN, so it should seem familiar.

Gitlab

After you have learned the basic commands, I recommend you check out Gitlab and open up a free account.  Once you open your account, create a new project.  GitLab will automatically show you what Git commands you need to issue in order to clone your repository or upload an existing folder.  From there, just experiment.

There is a whole lot more to Gitlab.  Luckily the help is very detailed.  The one thing you might have trouble with at first is ssh keys.  Just look it up in the Gitlab help.  It should point you in the right direction.

Conclusion

I think Git offers a lot of advantages over SVN.  If you are still using SVN, I recommend you check it out.  It can be daunting at first, but once you figure it out, it is not too bad.  This post really just scratches the surface, but hopefully, it has given you enough information to point you in the right direction.

If you need more direction in setting up Git for your organization or transitioning to Git, schedule a free one-hour consultation.