First of all, let's just see if you already have git. Go in to the shell, and try out a quick git --version. This should check to see if Git is already installed on your system, and if it is, well then let's just skip to the next section. Also, if you have no idea what the shell is, go check out my Shell tutso.
Anyways, if you don't actually have it yet, Git can get got from git-scm.com. Go get it there, and install it.
I see you sitting there sweating. Don’t be silly. By now you probably know that Git is a language. Github is a website. Let’s not confuse the two anymore. Git is a language, and that means generally you have to learn a new syntax to use it. This syntax is often shorthand (for power users) and therefore can be daunting to the new recruits. But it’s not that bad.
Everything starts with a terminal (on mac or linux, if you’re on windows use a command prompt) and the simple to remember command:
git
Ignore the $ sign, by the way. That’s just our indicator for the start of our line. The easiest way to check whether git is already up and running on your computer is to just go into the command line and type out:
git help
This should either break completely, or show you some information. If it doesn’t work at all, congratulations, it looks like you have to go install git from http://git-scm.com/. They’ll walk you through the process real nice and gentle. In fact, once you’re into git, this website is a tremendous resource for the language, and all it has to offer.
Now that we’ve got git up and running, let’s set up a local repository. A repository is basically a folder of git information that either sits next to a folder of files and remembers their status, or sites on a remote location and potentially tells many users what the current status of their local repo should look like.
A bare repo is necessary for a non github remote repository. Anyplace that stores the shared information for a repo should be initialized with the --bare flag. This folder should be totally empty, and will never get anything but git things put inside it.
Open the folder in terminal (right click the folder name and choose Services > New Terminal at Folder) and type in the part of this command that follows $. Change the PROJECT part to match a simplified name of your project. Remember what you use here, you’ll need it again later.
git init --bare PROJECT.git
Maybe you caught how easy that was, but if not, you’re done. That was it. I should mention a couple of things. You can make any local folder into a bare repo, even potentially cloud based folders like Dropbox or Drive folders.
It’s important to note that because of the way dropbox and drive handle file transfers, you never want to have a development repo in a cloud folder. Whenever a file commits, it will be rewritten and cause a lot of extra traffic.
It’s also important to note that you probably don’t want an extremely active remote repo on a cloud folder. This is because if two people were trying to write to it at the same time, there is a lag in connectivity, and this can lead to instability. If it’s just you, and you’re certain you’ll never try to push from two different computers at the same time, then you’ll probably be fine. Just be aware of the implications of what you’re doing, and don’t come crying to me.
The project repo will be the location of all our actual files. This could already have files in it, that’s ok. We will do a general git init on this folder to repo it.
git init
After initializing the repo, let’s add in any of the files currently in the folder. Notice the period there.
git add .
Now that we’ve added in our files to the repo, let’s commit these files. The -m flag means we’re adding a message (required) and the text after it is our message. The message for a commit should describe the changes that occured so that while looking back through versions, it will be easier to find the location you want to step back to.
git commit -m "first commit"
Ok. We have our remote bare repo, we have our local repo. Let’s link them up. You’ll have to use a real link to your remote repo.
git remote add origin ~/Project/git/PROJECT.git
Excellent, now that your “local” development repo is hooked up with your “remote” server repo, let’s push our dev files onto the remote repo.
git push -u origin master
Set up a default user name for yourself on your system
git config --global user.name "User Name"
Set up a default email address for yourself on the system
git config --global user.email example@email.com
Set up a default text editor on your system
git config --global core.editor "Sublime Text"
Quickname is a fast name for a branch to be thrown away in a second. Use quick-name or whatever github tells you instead.
git checkout -b quick-name master
git pull https://github-url.com
Regardless if there are any problems with the previous step, you will need to add all files pulled, and commit the quick-branch
git add .
git commit -m "fixed conflicts"
Switch back to the master, merge the quick-name, and commit the merge
git checkout master
git merge quick-name
git commit -m "merged quick-name"
Clean up and delete the quick-name, and push up... or not, whatever
git branch -d quick-name
git push
Temporarily switch to a different commit
If you want to temporarily go back to it, fool around, then come back to where you are, all you have to do is check out the desired commit. This will detach your HEAD, that is, leave you with no branch checked out.
git checkout 0d1d7fc32
Or if you want to make commits while you're there, go ahead and make a new branch while you're at it:
git checkout -b old-state 0d1d7fc32
If, on the other hand, you want to really get rid of everything you've done since then, there are two possibilities. One, if you haven't published any of these commits, simply reset:
This will destroy any local modifications. Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
This saves the modifications, then reapplies that patch after resetting. You could get merge conflicts, if you've modified things which were changed since the commit you reset to.
On the other hand, if you've published the work, you probably don't want to reset the branch, since that's effectively rewriting history. In that case, you could indeed revert the commits. With Git, revert has a very specific meaning: create a commit with the reverse patch to cancel it out. This way you don't rewrite any history. This will create three separate revert commits:
git revert a867b4af 25eee4ca 0766c053
It also takes ranges. This will revert the last two commits:
git revert HEAD~2..HEAD
git revert -m 1 <merge_commit_sha>
To get just one, you could use `rebase -i` to squash them afterwards. Or, you could do it manually (be sure to do this at top level of the repo). Get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .
Then commit. Be sure and write a good message describing what you just did.
git commit