How to Create a Repository wih Git and Start Using It
About three weeks ago or so I decided to get started with Git. After all, it seems that everyone else is using it and I felt that at the very least I should investigate it and play around with it a little. I didn't know what the best approach was to for my research. Little did I know that it was going to be a difficult journey, especially since I am doing all of this research on my own time instead of during work hours. Also because Git is so robust and has so many different ways of doing the most basic things.
At first I took advantage of my Safari Books Online account to read Scott Chacon's Pro Git. I found it to be a difficult read as a beginner. It became easier to digest once I'd gone a couple of rounds with Git. I also found out that the book is available for free online at the Pro Git Website. Recently I also received some hints to other resources such as the CoDe Magazine article, Git for SubVersion Users, by Derick Bailey and also to the Alamo Coders Video on Git also by Derick Bailey. This advice came from none other than Derick himself. He also pointed out that the book Version Control with Git (Loeliger) was much easier for beginners than Chacon's Pro Git. However, Pro Git is the best reference on the topic of Git.
I am saying all all this only to point out the resources that I used along my journey. If you are ready to embark on the same journey, by all means go for it. I don't intend to undermine all of the work that the developers responsible for those resources put into their work. I highly recommend reading and viewing that material for anyone interested in using Git for the long term. I also think that it is extremely important to understand the architecture and philosophy of Git. However, the focus of this article is to provide a how-to into the world of Git.
I intend to provide a quick start for anyone that wants to get up and running quickly with Git. All the material here is what I've learned from the resources mentioned above. It is somewhat compressed and at the same time watered down. I intentionally avoid discussing all the theory of the architecture and the mechanics of Git, not because they are not relevant, but rather to pack more practical punch in this article. If you are OK with that, keep on reading and I promise that you will be able to use this short article to begin using Git in a practical manner. If you intend to use Git in a production environment, I highly recommend that you do not stop with this post and instead use the references above to help you along your journey.
Installing Git
Before you can start using Git you must install it on your machine. There is more than one way to acquire git. For this purpose I will point you in one direction and that is to visit the Google Code Page for MSysGit and download it. Once you download it, go ahead and install it by following the on screen prompts.
Creating your First Repo
Open the Git Bash program from your windows start menu.
You should get a command prompt window like the one below
At this prompt you can use normal bash commands to navigate the directory.
The first thing that you will want to do is setup you user configuration. You do this by entering the following commands and replace "John Doe" and "johndoe@example.com with your information. Git will use this information for keeping track of changes you commit to the repository.
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
You can also setup your editor of choice (Which I consider a topic for discussion in its own right). For the sake of this article we will skip that step because I discovered that it was not absolutely necessary for me. I will caution you that if you do not how to use the VIM or Emacs editors you may run into problems at the very least you may want to research how to save and also to exit the editors. Getting stuck in the editors, is quite annoying.
At this point you are ready to start using Git. If you already have a project that you would like to place under version control with Git, navigate to that folder using the bash commands (cd to change directory and ls to view the directories).
Let's say that you navigate to a project at the following location:
$cd C:\myprojects\mysolution
Then you can initialize that project as a git repository by executing the following command
$git init
At this point you will notice that you have indirectly created a directory named .git at the root of your working directory. That folder is the entire repository for that project. Unlike Subversion, Git creates one and only one folder for the entire repository. I believe that if you lose (think Delete) that folder you lose your repository and all version control along with it.
You do not have any files committed to Git yet. To start committing files you will have to run two separate commands (git has ways of combining the two commands into one if you'd like). That is because git has the concept of staging and then committing files. One important thing to point out about staging and committing is that when you stage that is what Git will commit even if you made changes after you staged.
To Stage the files you must run the following command
$git add .
This tells git to add all files in the directory and its sub directories to the staging process. You may have files and folders that you do not wish to commit (such as user configurations, resharper, bin directories, etc) and for that reason you will need to add a file named ".gitignore" to the root of your repository. I will not discuss how to configure that file here, but you can find out how do it in the Pro Git book. Or you can do like me and steal one from an open source project to use it as your starting point. You can also tell git to add specific files (instead of the full directory - .) but I discovered that nine times out of ten you will want to add everything you have starting for the repository's root.
To commit the files you must run the following command
$git commit -m "First Commit Ever"
That line tells git to commit everything that is staged and you are adding the message "First Commit Ever". If you run this commit exactly as you see it you may end up in the VIM editor and you may have a hard time navigating your way out of it.
One thing worth mentioning is that any time you may run the following command to view the status of your repository to determine which files are staged or edited.
$git status
At this point you have a repository that you can start tracking changes on. To view the changes that have been made to you can run the following command:
$gitk
That command will give you the following GUI to view the changes in your repository.
You can also run the log command to view the changes in the command line. As with all other bash commands, please see the help files to use the command in the way that suits your needs best.
$git log -u
The command above will show the log along with the diffs for each file.
You can use the following command to view the help files associated with that command
$git --help log
Moving on to multi-user access
So far we were able to create a repository for our own project. The only benefit that we gain from Git at this point is that we can track changes to our project along the way. If that was all there was to git it would do little good for team collaborations. I don't intend to demonstrate a practical work flow for git. Instead I just want to demonstrate how you can give access to others for your repository. You can search on the web for work flows and I'm sure you will find other presentations and blogs on that concept.
Let's say that you placed that repository as a shared folder and then allowed certain individuals access to that folder. They then could access your repository by creating a remote to your repository. The most common way to create a remote is to simply clone the repository(Please research the correct way to setup repositories - this is only used for demonstration purposes but you should always setup your repositories with security in mind). Let's assume that your folder could be accessed by the following path on the network:
file:///\\jdoe-pc\mysolution
Anyone, for the sake of this post let's say that anyone is Dave, wanting to create a remote could perform the following commands on the bash
$CD C:\myapplications\jondoesolution
$git clone file:///\\jdoe-pc\mysolution .
That action will clone John Doe's solution in the location C:\myapplications\jondoesolution on Dave's computer.
The clone action by default creates a remote and by convention names it "origin" on the client repo. At this point any time John and Dave can work independently and then share code through pull and push actions. I recommend pull over push personally, but then I could be wrong as I am new to Git. With that said John could create a remote on his repo that points to Dave's machine and pull on demand. Since Dave already has a remote to John's machine he can already begin executing pulls on demand.
For Dave to pull from Johns machine he just has to navigate to the folder C:\myapplications\jondoesolution and execute the pull command as shown below:
$ git pull
For Dave to push code up to John's machine he can execute the push command as shown below
$ git push origin master
A word of caution if you try to execute the push is that git may refuse the action for a reason that I will mention shortly. The reason that the push will likely not work is because John is logged in to the master branch. To get around that John must simply create a branch and log into that branch instead.
We briefly discussed creating a remote. That is because in the one case we discussed, the clone command created the remote for us. But let's say that John wants to have a remote to Dave's machine so that he can pull Dave's changes over to his repository. He can do this by executing the following command:
$ git remote add davesrepo file://davesmachine/hissolution
Assuming that Dave used that path to share that folder. Now whenever John wants to pull the latest changes from Dave's repository he can execute the following command:
$ git pull davesrepo
Summary
This is what I've learned how to do so far. As with anything, I actually know a little more than what I've shown here. I've watered down the concept. As you can imagine git (coming from Linux) is very robust and the commands and switches are many. I intend to learn more as I go along but I think that I have enough to get started and hopefully with this post you do too.
At first I took advantage of my Safari Books Online account to read Scott Chacon's Pro Git. I found it to be a difficult read as a beginner. It became easier to digest once I'd gone a couple of rounds with Git. I also found out that the book is available for free online at the Pro Git Website. Recently I also received some hints to other resources such as the CoDe Magazine article, Git for SubVersion Users, by Derick Bailey and also to the Alamo Coders Video on Git also by Derick Bailey. This advice came from none other than Derick himself. He also pointed out that the book Version Control with Git (Loeliger) was much easier for beginners than Chacon's Pro Git. However, Pro Git is the best reference on the topic of Git.
I am saying all all this only to point out the resources that I used along my journey. If you are ready to embark on the same journey, by all means go for it. I don't intend to undermine all of the work that the developers responsible for those resources put into their work. I highly recommend reading and viewing that material for anyone interested in using Git for the long term. I also think that it is extremely important to understand the architecture and philosophy of Git. However, the focus of this article is to provide a how-to into the world of Git.
I intend to provide a quick start for anyone that wants to get up and running quickly with Git. All the material here is what I've learned from the resources mentioned above. It is somewhat compressed and at the same time watered down. I intentionally avoid discussing all the theory of the architecture and the mechanics of Git, not because they are not relevant, but rather to pack more practical punch in this article. If you are OK with that, keep on reading and I promise that you will be able to use this short article to begin using Git in a practical manner. If you intend to use Git in a production environment, I highly recommend that you do not stop with this post and instead use the references above to help you along your journey.
Installing Git
Before you can start using Git you must install it on your machine. There is more than one way to acquire git. For this purpose I will point you in one direction and that is to visit the Google Code Page for MSysGit and download it. Once you download it, go ahead and install it by following the on screen prompts.
Creating your First Repo
Open the Git Bash program from your windows start menu.
You should get a command prompt window like the one below
At this prompt you can use normal bash commands to navigate the directory.
The first thing that you will want to do is setup you user configuration. You do this by entering the following commands and replace "John Doe" and "johndoe@example.com with your information. Git will use this information for keeping track of changes you commit to the repository.
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
You can also setup your editor of choice (Which I consider a topic for discussion in its own right). For the sake of this article we will skip that step because I discovered that it was not absolutely necessary for me. I will caution you that if you do not how to use the VIM or Emacs editors you may run into problems at the very least you may want to research how to save and also to exit the editors. Getting stuck in the editors, is quite annoying.
At this point you are ready to start using Git. If you already have a project that you would like to place under version control with Git, navigate to that folder using the bash commands (cd to change directory and ls to view the directories).
Let's say that you navigate to a project at the following location:
$cd C:\myprojects\mysolution
Then you can initialize that project as a git repository by executing the following command
$git init
At this point you will notice that you have indirectly created a directory named .git at the root of your working directory. That folder is the entire repository for that project. Unlike Subversion, Git creates one and only one folder for the entire repository. I believe that if you lose (think Delete) that folder you lose your repository and all version control along with it.
You do not have any files committed to Git yet. To start committing files you will have to run two separate commands (git has ways of combining the two commands into one if you'd like). That is because git has the concept of staging and then committing files. One important thing to point out about staging and committing is that when you stage that is what Git will commit even if you made changes after you staged.
To Stage the files you must run the following command
$git add .
This tells git to add all files in the directory and its sub directories to the staging process. You may have files and folders that you do not wish to commit (such as user configurations, resharper, bin directories, etc) and for that reason you will need to add a file named ".gitignore" to the root of your repository. I will not discuss how to configure that file here, but you can find out how do it in the Pro Git book. Or you can do like me and steal one from an open source project to use it as your starting point. You can also tell git to add specific files (instead of the full directory - .) but I discovered that nine times out of ten you will want to add everything you have starting for the repository's root.
To commit the files you must run the following command
$git commit -m "First Commit Ever"
That line tells git to commit everything that is staged and you are adding the message "First Commit Ever". If you run this commit exactly as you see it you may end up in the VIM editor and you may have a hard time navigating your way out of it.
One thing worth mentioning is that any time you may run the following command to view the status of your repository to determine which files are staged or edited.
$git status
At this point you have a repository that you can start tracking changes on. To view the changes that have been made to you can run the following command:
$gitk
That command will give you the following GUI to view the changes in your repository.
You can also run the log command to view the changes in the command line. As with all other bash commands, please see the help files to use the command in the way that suits your needs best.
$git log -u
The command above will show the log along with the diffs for each file.
You can use the following command to view the help files associated with that command
$git --help log
Moving on to multi-user access
So far we were able to create a repository for our own project. The only benefit that we gain from Git at this point is that we can track changes to our project along the way. If that was all there was to git it would do little good for team collaborations. I don't intend to demonstrate a practical work flow for git. Instead I just want to demonstrate how you can give access to others for your repository. You can search on the web for work flows and I'm sure you will find other presentations and blogs on that concept.
Let's say that you placed that repository as a shared folder and then allowed certain individuals access to that folder. They then could access your repository by creating a remote to your repository. The most common way to create a remote is to simply clone the repository(Please research the correct way to setup repositories - this is only used for demonstration purposes but you should always setup your repositories with security in mind). Let's assume that your folder could be accessed by the following path on the network:
file:///\\jdoe-pc\mysolution
Anyone, for the sake of this post let's say that anyone is Dave, wanting to create a remote could perform the following commands on the bash
$CD C:\myapplications\jondoesolution
$git clone file:///\\jdoe-pc\mysolution .
That action will clone John Doe's solution in the location C:\myapplications\jondoesolution on Dave's computer.
The clone action by default creates a remote and by convention names it "origin" on the client repo. At this point any time John and Dave can work independently and then share code through pull and push actions. I recommend pull over push personally, but then I could be wrong as I am new to Git. With that said John could create a remote on his repo that points to Dave's machine and pull on demand. Since Dave already has a remote to John's machine he can already begin executing pulls on demand.
For Dave to pull from Johns machine he just has to navigate to the folder C:\myapplications\jondoesolution and execute the pull command as shown below:
$ git pull
For Dave to push code up to John's machine he can execute the push command as shown below
$ git push origin master
A word of caution if you try to execute the push is that git may refuse the action for a reason that I will mention shortly. The reason that the push will likely not work is because John is logged in to the master branch. To get around that John must simply create a branch and log into that branch instead.
We briefly discussed creating a remote. That is because in the one case we discussed, the clone command created the remote for us. But let's say that John wants to have a remote to Dave's machine so that he can pull Dave's changes over to his repository. He can do this by executing the following command:
$ git remote add davesrepo file://davesmachine/hissolution
Assuming that Dave used that path to share that folder. Now whenever John wants to pull the latest changes from Dave's repository he can execute the following command:
$ git pull davesrepo
Summary
This is what I've learned how to do so far. As with anything, I actually know a little more than what I've shown here. I've watered down the concept. As you can imagine git (coming from Linux) is very robust and the commands and switches are many. I intend to learn more as I go along but I think that I have enough to get started and hopefully with this post you do too.
Comments
http://help.github.com/win-set-up-git/