Well, I had an account on
github since 2009, but I started using it recently. On the one hand, that was because I was a very lazy programmer, but on the other hand, it was because git used to confuse me.
Now, after watching some
webcasts and reading some
scattered documents, I made myself a cheat-sheet, and I'd like to share it with you here.
First thing first, git is not github. I mean, you can use your local git and never touch github, however, github is the de-facto git in the cloud nowadays, and sharing your code there is a very cool thing. Hint hint, some employers also value those who share beautiful code there.
Second thing second, I will assume you are using
GNU/Linux, oh, I forgot to tell you, Windows sucks, and one of the main reasons I never understood git, was because I was using Windows back then. Mac should be fine too, however, I never touched an Apple laptop before, so I cannot really tell.
Initializing Git
Now. let's say are writing some cool software in some folder. In your beautiful GNU/Linux terminal get into that folder and type the folloing command:
$ git init
This is a mandatory initial step, it tells git to creates a hidden folder there ".git". And it uses that folder to do all its black magic.
How are you? How are they hanging? Que tal?
Throughout your gitting life, you can use the following command anytime to check the status of your repository:
$ git status
As opposed to status, log tracks history not the status current moment
$ git log
Still confused a bit, give them a try now, or you know what, let me give you one more hint.
Help! I need some help
The easiest way to ask for help, is to write git followed by the word help, then the command that you need to know more about.
$ git help status
$ git help log
Probably, it will give you some cryptic information, so let's skip it for now, at least, you now know that help it there whenever you need it.
Let's start the fun
Git respects your privacy, and gives you control on what to commit (their lingo for saving) at a certain moment. So, whenever you edit your code, you have to explicitly tell it which files you need to commit later on. To add a file to git:
$ git add file_name.txt
You can use wildcards too, written in quotes. Below you add all text and python files:
$ git add '*.txt'
$ git add '*.py'
Similarly you can remove file from staging
$ git rm file_name.txt
After adding comes the committing
To commit files from staging area to repository:
$ git commit -m "Some committing comment here"
I know, 'staging', 'repository' and 'committing', all sound Chinese to you now. Well, if staging is like the RAM, some temp location or so, and the repository is like the Hard Disk, then committing is like saving. The text in quotes after the '-m' is mandatory, but it is up to you to write anything there, you can even write a single dot in there if you want to. However, it is useful for your reference later on in case you needed to revert to a certain version of your software. So, it is always a good practice to write down what you have actually done before this commit. 'Add a hocus_pocus method to my Magic class', 'Corrected a typo in README', etc.
Github FTW
So far, we have been doing thing on our local machine, let's see how to publish all that to github. In your github homepage, there is a button called "New repository", click on it to create a new repo. They will ask you some question about your project's name etc. When done go to that repo, and on top of the page, you will find a URL that looks like this:
https://github.com/[YOUR-USERNAME]/[PROJECT-NAME].git
Copy it, and go back to your GNU/Linux termina and write the following command
$ git remote add origin [URL]
Well, I believe origin can be replaced with any other name, but I still have no clue about it, so let's stick to origin for now, I am just a monkey-see monkey-do at the moment.
Publishing your work
Now you connected your local git to github, what to do next? Exactly, publish that changes you have just committed. Or in our case, we will be publishing everything from scratch since our github repo is still empty now. Once more, those git people use their own lingo, so they call publishing pushing.
$ git push origin master
Remember, we used origin before, so we use it again here, as for master, this is something called branches, but let's not confuse ourselves with it now, let's stick to origin and master for now.
You know what, I've got a short-cut for you. Let's add a '-u' to the previous command
$ git push -u origin master
Great, by doing so, from now on, git will remember your choices and you will not need to say origin and master in your pushes again again. I.e. next time, just write the following and it will work:
$ git push
You 3 useful commands
Most of the time from now on, you will be editing files locally, then pushing them to git hub, to publish your changes all you need to do is the following 3 steps. Adding files, committing then pushing.
$ git add '*.py'
$ git commit -m "Cleaned my code a bit"
$ git push
Sharing is caring
Like any social network, github is mean for people to share code. So, most probably you will have some other friends working on the same project with you, and they do make their own changes to the code as well. So, how to synchronize your local repo with the changes they already published on githib. Easy peasy! If push was our way of pushing our code to github, then pull is the way to get the updates from there.
$ git pull -u origin master
See, we added our magical '-u', so next time, we can simple write the following.
$ git pull
Well, that's enough for now, in the following section, I will list some other commands for your (and my) reference, but you can skip them for now.
To see difference between last commit and current files
$ git diff head
Also you can see differences for staged files
$ git diff --staged
To create a branch to play in
$ git branch branch_name
To see which branch you are in, just type:
$ git branch
To move to your new branch, type:
$ git checkout branch_name
To merge changes in branch_name to master, type the following wile on master
git merge branch_name
