This is a guide to using Git for absolute beginners to version control for development projects, using the GitHub for Windows program and just the basics needed to integrate Git into your everyday workflow. Git is a very powerful system but even the fundamental concepts can be overwhelming at first, especially when your only question is “How do I start using version control with my current workflow?” This series of Beginner’s Guide to Git tutorials will help answer that question.
If you haven’t installed Git yet, or you’re wondering why you should even use version control, check out the previous post in this series.
Last time, we installed the GUI client GitHub for Windows and created a repository in our local directory. If you are the only person working on a project, or you only want to track files that you modify on your personal workstation, then a local repository might be enough for you. More often than not, we will collaborate with other members of the team who also contribute to the project source code. In this case, you’ll want to use a Remote Repository.
Now there could be a number of options for using a Remote Repository, including:
- Keeping the Remote Repository in a shared disk or directory on the network, which all the members of the team have sufficient permissions to access
- Keeping the Remote Repository in a remote server, which all the members of the team can access through SSH
- Keeping the Remote Repository in a cloud service, such as GitHub or CloudForge or yes even Dropbox, and all the members of the team have access to the cloud location
In this tutorial, we’ll deal with the first option – a shared disk on the network, aka a network share. All of the options are fairly easy to set up. Depending on how many projects your team deals with, you probably don’t need a dedicated server for your shared repositories, so unless you already have a server at your disposal, cloud services can provide a cost-effective option.
Create a Bare Repository
In the last post I showed you the steps for creating a local repository, but a remote repository is different. A remote repository must be a Bare Repository, which is a special term in Git land. Unlike the local repository, also called a ‘Working repository’, a Bare Repository should always stay bare. You never work directly with files in this repository. This may not make sense yet, but very soon we’re going to make both a bare and working repository, and you can compare them. (If you’re wondering about the whys and wherefores, read this post Shared Repositories Should Be Bare Repositories.)
To create a bare repository, you can’t use the GitHub for Windows GUI client, but rather you must use the command line. This step should only be done once at the start of the project, and then you can use the GUI for pretty much everything else. You can use the Git Shell program, which should have been installed along with GitHub for Windows (there’s probably a shortcut on your desktop). As I mentioned earlier, in my case I am going to use a network share to store my remote repositories, which is just a disk that is accessible on the network.
In Windows, you can either:
- Map the shared disk to a network drive (instructions here)
- Use the UNC format to refer to the shared server (instructions here)
If you use the network share often, you may have already done these things. You are then going to navigate to the directory where you want the remote repository to live by using the change directory ‘cd’ command. (If you’re not familiar with the command prompt, see instructions here.) Once you are inside the directory, run the following command (replacing [ProjectName] with the desired name for the remote repository):
$ git init –-bare [ProjectName].git
For example: (I mapped the shared disk to the D: drive.)
This will create an empty repository, which is a new folder in the network share. If you open up the folder, you will notice that all the files that are kept separately in a .git folder for a local repository, are in the root of the bare repository itself. Once again, you are not supposed to work with files directly in the remote repository. You should clone the repository to your local machine or another personal location first.
Clone a Remote Repository
Cloning a remote repository is also something you typically only have to do once, the first time you start working with that remote repository. It’s exactly what it sounds like – you make an exact copy of the remote repository in a local folder, for example on the disk of your own computer. The reason why Git clones the entire repository is so that in the event that you do not have connection to your remote repository, such as if you disconnect from the network or the Internet, you can still work on the files in the repository. You just need to reconnect when you are ready to push your changes to the remote repository.
Now let’s open up GitHub for Windows, and navigate to the Tools > Options panel. You can set the default storage directory for your local repositories. I created a directory called ‘Repositories’ on my local disk for this purpose.
Now whenever you open up Git Shell, it should open right up to your default storage directory. Next run the command:
$ git clone [RemoteRepositoryPath]/[RemoteRepositoryName].git
For example: (This time I used UNC format, just to show you how – you can use the mapped drive instead.)
I placed a green box over the server name, but notice how I used the UNC format to refer to the network share, which can be a bit tricky, so I wanted to show you an example. Use the format file:// + \\ + UNC path. It looks a bit confusing, but there are two forward slashes and four back slashes before the server name. Also notice that I cloned the entire Remote Repository directory, whose name ends in .git. Now I have an identically named, empty folder in my default storage directory. Its name does not end in .git because it is not a Bare Repository.
Lastly, drag the folder into the space for local repositories in GitHub for Windows.
As a final note, if you look into the repository settings, you will notice that the original repository is listed as the primary remote, also known as the origin. This is the default repository GitHub for Windows will use when you request to push/pull your changes; just be aware that you can modify this if needed (for instance, if you move the remote repository to a different location in the future).
So now I have an empty local repository, cloned from my empty remote repository – now what? In the next post, we’ll look at the basics of using Git while working on a project – including Commit, Revert, & Roll Back. You can go back and read the first post to see how to create a local repository, if you don’t want to work with a remote repository. Either configuration can be used for the next post.