Create a Repository
This part is simple. Go to GitHub, make sure you’re signed in, and click that lovely little “New repository” button on the right hand side.
On the next screen you’ll give the repo a name. You can give it a description also, if you’d like.
Make sure to check the box “Initialize this repository with a README”. then go on ahead and hit create.
GitHub will stick you on the landing page of your brand new repo. Here you’ll notice it has a single file (README.md) and you’ll see the contents of your readme. I’m sure you’re intelligent enough to figure out that you should always read the readme (should), thus if you have one, it’s shown here.
Now, let’s get down to business… to defeat the Huns! (#SorryNotSorry)
Get Git Gud
(Tell me that heading doesn’t just roll off the tongue)
Now we need a Git client. Personally, I use Git SCM but other flavours are available. The astute among you may wonder why we’re not using GitHub’s client, to which I tell you this:
It’s pretty bad.
Once installed, right-click on your desktop and choose “Git Bash Here”. You’ll be presented with a linux-style terminal, into which thou shalt typeth the following:
$ git clone http://github.com/<your-username>/<your-repo-name>
Git will do some stuff, then you should see a shiny new folder on your desktop with the same name as your repo. Go ahead, take a peek. Open up that readme and admire the vast complexity of your newest project.
But it’s looking a bit bare in here right? Let’s move some files in. I’ve been working on a new WordPress theme lately, so I’m going to drag in those files. Now instead of just a readme, I have a folder that contains files a bit like this:
If you don’t have a .git directory in here, you probably have Show Hidden Files turned off. But that’s not important. Back in the terminal type $git status and you’ll see that that Git has detected the new files.
Let’s get these files pushed to GitHub.
Pushing Files to GitHub
$ git add *
You generally shouldn’t be using the * wildcard unless you’re confident that everything you’re adding is meant to be in the repo. $ git status is a great way to tell if there’s any fluff in your project folder. Certain things like debug configs, generated images or cache files you probably don’t want on GitHub.
$ git add “index.php”
Generally speaking, you should be using the command like this to add individual files to the repository.
$ git commit -m “Initial Commit”
I trust you see what’s going on here? I’m committing the change, where I’m adding files to the repo. -m means I’m typing my own commit message, and the text in quotes after that is the message.
$ git push
Git will now upload your changes to the GitHub server. Woohoo! If you go back to the browser and refresh your repo’s page, you’ll see your changes reflected there. Just like magic.
I Changed Something on Another PC
This is probably the most complicated thing you’ll have to do if you’re using GitHub in it’s most basic way. Every time you sit down to work after making a change somewhere else, use the following command to pull the updates to your machine:
Just like that, your updates are pulled down to your local machine.
But wait! I’ve made changes to the old files already!
Yeah, well, we’ve all been there. Try $ git pull anyway. If it throws an error there’s a couple of things you can do. The “easy” action is to clone a fresh copy to the repo and re-add you changes manually.
Alternatively, you can use the mergetool (use $ git help mergetool for some documentation). But resolving conflicts through Git is a whole different ballpark. Even those who are Git experts end up scratching their heads sometimes.