The first in a new series of posts on how to use Git for source control in SalesLogix development, this post will introduce Git, some Git terminology and some of the software you’ll use to work with Git and SalesLogix.
In these posts, I’ll focus on how Customer FX works with Git. We use Git for source control on all projects. It is great and SalesLogix development has never felt so good. We use Github for hosting all repositories (Customer FX loves cloud hosted services [:D]) and have a standard set of tools we use. In these posts I will cover a range of topics, from the initial set up to the day-to-day usage of Git when developing for SalesLogix. Over the new few weeks we’ll get deep into all of this.
What is Git?
Git is a distributed source control system. Distributed being the key word here. Basically, you always have your own full copy of the repository or source control with commit history, etc. All developers on the project have this as well. Everyone is working on their own local copy of everything. So to share things between developers, often a central repository will be set up where all developers can push their changes to. This is where Github comes in. Customer FX uses Github to host our project repositories as private repositories. I’ll discuss later how we have that set up. That’s as short of an answer to what is Git as you’ll ever see, but this isn’t meant to be a “what is Git” post anyway, but a how to get started with it (or at least one that starts us down that path).
Let’s start with looking at some of the standard tools for working with Git. Like I mentioned before, there are a lot of options, but I will be focusing on the tools we use at Customer FX for working with Git.
Git (mSysGit) – http://code.google.com/p/msysgit/
mSysGit is the official Windows port of Git. Go to the Google Code site linked above and download and install the latest version listed on the right side of the page. mSysGit gives you all the git commands in Windows. As a side note, installing Git Extensions (listed next) will give you the option to also install mSysGit as well so if you’re going to be installing that also you don’t need to install this separately.
Git Extensions – http://code.google.com/p/gitextensions/
Git Extensions provides some great Windows GUI tools for working with Git and Git Repositories. This also gives you Visual Studio integration (you have toolbars and menus right in Visual Studio to push/pull/commit to Git repositories). For working with Git, I like Git Extensions and this tool makes getting into Git an easy transition.
Git Extensions for SalesLogix – http://wiki.github.com/CustomerFX/SalesLogixGitExtensions/installation
This is a Customer FX developed (and open source) integration for the SalesLogix Application Architect. It basically makes the dialogs from Git Extensions (mentioned above) in the Application Architect so you can commit, push, pull, fork, etc all from inside of the tool you’re already using to develop for SalesLogix. In order to use this, Git Extensions must be installed as well.
TortoiseGit (optional) – http://code.google.com/p/tortoisegit/
TortoiseGit is a Windows extension for Git. It provides right-click context menus for folders and adds shell extensions that give you nice icon overlays in Windows so that you can visually recognize files that are controlled in a Git repository and which files have changed and have not yet been committed to the repository. This is a nice to have, but not needed for what we’ll cover in this series of posts.
In a later post I will cover how to install these and configure Git for use.
Basic Git Terminology
For those new to Git I wanted to mention some brief basic Git terminology so the rest of this series will make more sense. These are my quick and layman term definitions. I’ll point you to a better resource to read more on these commands later on.
A repository is where Git stores your files and information about your files, such as changes, etc. On your local computer, a repository will be a directory containing your files. This directory will have a folder named “.git”. This is where Git will store information about changes to your files (not the changed files themselves, but the delta of these changes – allowing you to revert back to earlier versions of the files). Note that the repository itself is represented as a directory on your local machine, however, that does not mean that all files in that directory are included in the repository. Files must be explicitly added to the repository. So it is possible to have a file in the directory that is not part of the repository (having TortiseGit installed makes this easy to see as it adds an icon overlay to the file on Windows so you can see what it part of the repository and what is not). It is also common to have a remote repository as well where all developers push the commits from their local repository to. More on this in the section on Remotes.
A commit means you are telling Git about changes you’ve made and putting that changes into your local repository. When you have a project under Git source control you can make changes to the files. However you decide when to “commit” these changes to Git. You can think of a commit as queueing files to a staging area. Like “I’ve made these changes and they are good to go”. A commit does not put the change in a central repository, such as one on Github – that is what a push does. Think of commits like a staging area. Once you’re done with everything then you’ll push things back to the remote central repository. The general rule is “commit often but only push good code” (more on Push in a minute). When you commit a change, you must supply a comment. This is required and you should try to make the comment useful so you know what a certain commit was actually for. The commit comment is not meant to contain a lot of prose, just a short comment like “added 5 new textboxes and code to sum the values”.
A push is when you take all your commits and actually merge them into a remote repository. When you push, it will only take what you’ve already committed (if you’ve made changes that you’ve not yet committed those changes will not be included in the push). Going back to the general rule I outlined above, “commit often but only push good code”. What this means is that as you’re doing work, you will make a commit every time you’ve made some significant change. However, don’t push it back to the repository until you’re sure that your changes will not break anyone else’s code. You can only push back to the remote if no one else has pushed since you last pulled, otherwise your push will be rejected. If this is the case, you must first pull and merge in any new changes into your local repository, then you can attempt to push again.
A pull is when you take what is in a remote repository and apply it to your local repository. This is what you’ll do when you start a new day, or phase, of work. This will give you all the most up to date versions of the files. When you sit down to start work you’ll usually do a pull to get up to date first. What a “pull” actually does is really a fetch and a merge. That is, it fetches all data from a branch in the remote repository, creates that branch in your local repository and then merges it with your current branch. A “fetch” command does all of that minus the merge.
Cloning is the initial act of bringing a repository local to work with it. Sort of like the initial pull. Basically, what you are doing is creating a clone of a remote repository locally. Essentially, you’ve made a copy of the remote repository so you have a local repository to work with. You’ll work with the local one and then push it back to the online repository when you’re done (although you’ll still have your local cloned repository – it will just likely be out of date until you pull any changes to it again). One thing to note is that you’re getting a clone of the repository itself. Not just the files, but the version changes as well – even previous commit and comments.
A remote is basically an online repository. This can be online using a host like Github, or even online as in somewhere on the network. When I refer to a remote in these posts, I’ll be referring to a central repository hosted on Github.
Using Github Accounts
As I mentioned earlier, I’ll be mainly focusing on how Customer FX uses Git for SalesLogix projects. We use Github for the host of all remote repositories.Github has several different options as far as accounts go, some free, some paid.
This is how we use Github at Customer FX and it works great. We basically have a paid account that is for Customer FX Development, not for any one single user. All project repositories go under that company account. For this account, you can go with the one of the smaller paid plans and bump up as needed. You can upgrade from one level to the next as needed. Each developer at Customer FX has their own free account on Github. Individual developers at Customer FX do not host any repositories for customer projects on their own accounts, that is all done on the company Customer FX account. However, for a developer to push to a shared private repository they need their own account. When we have a new project to start, someone will log into the company Customer FX account and create the repository and then add the developers that will work on that project as collaborators on the project. Then each developer uses their own free account when they do any work, never the shared Customer FX account. Working this way is nice especially because you have all projects hosted in the same place, on the same account, and not projects scattered across the accounts of all the developers.
Documentaion & References
Here are a few great resources on Git, Git commands, and more. I’m not going to focus too much more on the commands themselves, but more on how you use all this with a SalesLogix project. Reading up on the commands using the resources below will be something you can do on your own to become more proficient with Git as you go forward.
Official Git Community Book – http://book.git-scm.com/
This is considered the official Git documentation, more or less. This is an online book that is a community effort to build the documentation in book form for Git and Git commands.
Pro Git – http://progit.org/book/
This book is a free online book for working with Git. Excellent resource.
Well, that is enough to get us started. Stay tuned for the next post in the “Git for the SalesLogix Developer” series.