Git it easy. It’s a command with some verbs. Let’s start with the init verb, which creates an empty git repository in the working directory (or supply a path after the verb)
git init
Now let’s touch a file in that directory. Once a new file is there, which that new repo as your working directory, run git with the status verb:
git status
Oh look, you now see that you’re “On branch master” – we’ll talk branching later. You see “No commits yet” and hey, what’s that, an Untracked file! Run git with the add verb, and this time you need to specify a file or path (I’ll use . assuming you’re working directory is still the directory of your path).
git add .
Now let’s run that status command again. And hey, it sees that you now have a staged file (or files).
Now let’s run our first commit. This takes the tracked and staged file that we just created and commits it. Until we do this we can always revert back to the previous state of that file (which in this simple little walkthrough would be for the file to no longer exist).
git commit -m “test”
Now let’s edit our file and this time let’s run git with the diff verb:
git diff
Hey, you can now see what changed between your file(s). Easy, right? Check out the logs to see what you’ve been doing to poor git:
git log
Hey look, there’s a commit listed there, along with an author, a date and time stamp, as well as a name of the file(s) in the commit. Now, let’s run a reset to revert to our last commit. This will overwrite the changes we just made prior to doing the diff (you can use a specific commit by using it as the next position after —hard or you can just leave it for the latest actual commit:
git reset —hard
Now this resets all files back to the way it was before you started mucking around with those poor files. OK, so we’ve been working off in our own little world. Before we explore the wide world that is cloning a repository off the interwebs, first we’re going to do a quick look at branches. You know how we reset all of our files in the previous command? What if we had 30 files and we just wanted to reset one? You shouldn’t work in your master branch for a number of reasons. So let’s look at existing branches by running git with the branch verb:
git branch
You see that you have one branch, the “* master” branch. To create a new branch, simply type git followed by the name of the branch you wish to create (in this case it will be called myspiffychanges1):
git branch myspiffychanges1
Run git with the branch verb again and you’ll see that below master, your new branch appears. The asterisk is always used so you know which branch you’re working in. To switch between branches, use the checkout verb along with the name of the branch:
git checkout myspiffychanges1
I could have done both of the previous steps in one command, by using the -b flag with the checkout verb:
git checkout -b myspiffychanges1
OK now, the asterisk should be on your new branch and you should be able to make changes. Let’s edit that file from earlier. Then let’s run another git status and note that your modifications can be seen. Let’s add them to the list of tracked changes using the git add for the working directory again:
git add .
Now let’s commit those changes:
git commit -m "some changes"
And now we have two branches, a little different from one another. Let’s merge the changes into the master branch next. First, let’s switch back to the master branch:
git checkout master
And then let’s merge those changes:
git merge myspiffychanges1
OK – so now you know how to init a project, branch, and merge. Before we go on the interwebs let’s first setup your name. Notice in the logs that the Author field displays a name and an email address. Let’s see where that comes from:
git config --list
This is initially populated by ~/.gitconfig so you can edit that. Or, let’s remove what is in that list:
git config --unset-all user.name
And then we can add a new set of information to the key we’d like to edit:
git config user.name "Charles Edge" --global
You might as well set an email address too, so people can yell at you for your crappy code some day:
git config user.email “chuckufarley@me.com” --global
OK, optics aside, let’s clone an existing repository onto our computer. The clone verb allows you to, —insert suspense here— clone a repository into your home directory:
git clone https://github.com/autopkg/autopkg
The remote verb allows you to make a local copy of a branch. But it takes a couple of steps. First, init a project with the appropriate name and then cd into it. Then we’re going to grab the url from GitHub:
And add it using the remote verb:
git remote add AutoPkg https://github.com/autopkg/autopkg.git
Now let’s fetch a branch of that project, in this case, master:
git fetch test myspiffychanges1
Now we’ll want to download the contents of that branch:
git pull myspiffychanges1
And once we’ve made some changes, let’s push our changes:
git push test myspiffychanges1
