Getting started with GIT

263 VIEWS

·

What Do You Use for Source Code Control?

I was asking everyone I met at NI Week about what frameworks they were using and about source code control. Almost everyone I talked to said they were using some kind of source code control. A lot of people are using Git, and a few people are using Mercurial, but I was surprised by how many people are 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 three 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 customer’s site that had no Internet access. This posed two problems — He couldn’t check anything in or out of the repository, and he couldn’t browse the log. With SVN, both use 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. 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 check-in and checkout. With Git, not only do you not need to push over the network every time you check in, but when it does push or pull data over the network, it does a bunch of optimizing. You notice the speed improvement 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 check in or check out. 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. 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. 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). Additionally, 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.

Gitting Started

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 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 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 several 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 option — which I don’t really use)  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’s 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 them 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’s 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.


Sam makes it easier for LabVIEW Teams to write great code. Sam helps them develop and implement processes that take advantage of the latest software engineering tools so everything flows smoothly and the developers can focus on what they do best, solving their customer's problem.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu