Committing Changes to Your Repository
Time to do our first commit! To make the change in .
gitignore official, type
git commit -m "Added deleteme.txt to .gitignore" .
Figure 11: Committing with a commit message.
–m option is followed by the commit message. You could just type
git commit, but then Git would load up a text editor and you'd be required to type a commit message anyway. In Mac OS X and Linux, vim is the editor that would load up; and in Windows, you'd get an error. If you prefer a full screen editor in Windows, you can type this to configure it:
git config --global core.editor "notepad"
If you end up in vim and are unfamiliar with it, note that it's a very geeky and unintuitive but powerful editor to use. In general, pressing the escape key, and typing "
:x" will save what you're writing and then exit. The same syntax will work to choose a new full screen editor in OS X and Linux, of course replacing notepad with the
/full/path/and/filename of a different editor.
The full screen editor is necessary if you want a commit message with multiple lines, so if you hate vim, configure Git to use an editor you do like.
To see the commit you just made, type
Figure 12: Log of the most recent commit.
The change on top is yours. Oh, what the heck, let's take a look at it with diff:
Figure 13: A diff output of the commit.
+deleteme.txt is the change that was just committed. The way this diff works is that Git tries to show you three lines before and after each of your changes. Here, there were no lines below your addition. The
+3,4 are ranges.
- precedes the old file's range, and
+ is for the new file. The first number in each range is a starting line number. The second number is the number of lines of the displayed sample before and after your modification. The 4 lines displayed only totaled 3 before your change.
Note that if you want to revert changes you made, the safest way is to use "
git revert," which automatically creates a new commit that undoes the changes in another commit. If you wanted to undo that last commit, which has the SHA-1 starting with 0c22, you would type:
git revert 0c22.(Don't actually do this if you are following along.)
Pushing Your Changes to Remote Repository
You cloned your repository from your GitHub account. Unless something went horribly wrong, the repository on GitHub should be:
https://GitHub.com/<your GitHub username>/potayto.git
Git automatically labels the location you cloned a repository from as "
origin." Remember when I said the internals of a Git repository were easily accessible in that .
Git folder in your project? Look at the text file
Figure 14: The contents of the .git/config file.
It's as simple as this.
Before I explain how to make your changes on the version of your code stored on GitHub, I should first explain more about branches. I already noted how a branch is a separate version of your code. A change made to one branch does not affect the version of your repository represented by another branch, unless you explicitly merge the change into it. By default, Git will put your code on a "master" branch. When you clone a project from a remote repository ("remote" in this case means hosted by GitHub), it will automatically create a local branch that "tracks" a remote branch. Tracking a branch means that Git will help you to:
- See the differences between commits made to the tracking branch (the local one) and the tracked branch (remote)
- Add your new local commits to the remote branch
- Put the new remote commits on your local branch
If you didn't have your local branch track the remote branch, you could still move changes from one to another, but it becomes more of a manual process. To do this, first, type
Figure 15: Showing that the local repository is ahead of the remote repository.
deleteme.txt change you made in your local master branch is not yet on Github! You have one commit that Github's origin) remote master branch (denoted as origin/master) does not yet have.
Let's put the change on Github. Git's
push command, if you don't provide arguments, will just push all the changes committed in your local branches to the remote branches they track. This can be dangerous, if you have commits in another local branch and you're not quite ready to push those out also. (I once accidentally erased a week of changes in New York Magazine's main repository doing this. We did manage to recover them, but don't ask.) It's better to be explicit. Type
git push origin master.
Figure 16: Pushing commit.
You don't really need to concern yourself with the details of how Git does the upload. But as for the command you just typed, Git's
push lets you specify the "remote" that you're pushing to, as well as the branch. By specifying the branch, you tell Git to take that particular branch ("master," in this case) and update the remote branch, on the origin (your Github potayto repository) with the same name (it will create a new remote "master" branch if it doesn't exist). If you don't specify "master," Git will try to push the changes in all your branches to branches of the same names on the origin (if they exist there).
If you type "
git status" again, you'll see your branch now matches the remote repository's copy of it. You can also look at the changes to the origin, by typing
git log origin/master.
Figure 17: Log of changes to the origin.
This is the syntax to see a log of the commits in the master branch on your "origin" remote. You can see the change is there. You can also see this list of commits by logging into Github, viewing your Potayto repository, and clicking on the link in Figure 18.
Figure 18: Seeing changes to the origin.
In the next installment of this tutorial, we'll examine how to pull changes from the remote repository, how to handle merges and merge conflicts, and other workflow tasks that are part of standard SCM work with Git.
Scott Danzig has been programming for more than 20 years. His personal projects on Github can be found at https://Github.com/sdanzig.