Making a Commit¶
This chapter will teach you to create your own commits with GitFourchette.
Crash course: What’s in a commit?¶
The contents of a Git repository evolve through a series of commits. A commit is a record of the state of the files in the repo.
More practically, you can think of a commit as a small milestone in your work on the repository: do some work, then commit your work when you’re ready to move on to another task.
In practice, creating a commit entails:
Making some modifications to files in the repository (outside GitFourchette);
Vetting which file modifications to include in the commit (this is called staging the files);
Composing a short message that describes the changes since the previous commit.
When you’ve just finished making the commit, it becomes the HEAD commit—meaning that it’s at the tip of the current branch.
Each commit is identified by a unique SHA-1 hash of its contents and metadata (parents, message, signature). Because of this unique hash, commits are immutable: the slightest modification to an existing commit would result in a different hash, and thereby a different commit.
Jumping to Uncommitted Changes¶
In GitFourchette, you can prepare commits from the Uncommitted Changes view. You can get there:
From the Sidebar: Click Uncommitted Changes (or just Changes if the sidebar is narrow).
From the Commit History: Click Uncommitted Changes at the top of the history.
From anywhere: Press Ctrl U.
Uncommitted Changes displays any files in your working directory that have changed since the HEAD commit:
Unstaged Changes: List of files that have changed since the HEAD commit, but that you haven’t staged for commit yet.
Staged Changes: List of changed files that are ready to be committed.
Diff View: Displays the differences in the selected file between your working version and the state of this file at the HEAD commit.
Note
The number of changes is shown next to Uncommitted Changes in the Sidebar if GitFourchette has an up-to-date model of your working directory.
Staging and unstaging files¶
After you’ve made some changes to files in the repository (outside of GitFourchette), the modified files show up in the Unstaged box.
To prepare a commit, you must decide which of these files to include in the commit—this is called staging the files. Select some files, then press the Stage button. Notice that the files you’ve staged have moved to the Staged box.
If you change your mind about staging a file, select it in the Staged box, then click Unstage. The file will move back to the Unstaged box.
To get rid of an unwanted modification in the Unstaged box, select the unstaged file and click Discard. (You can rescue changes that you’ve discarded by mistake.)
When you’re satisfied with your selection of staged files, click the large Commit files button. This brings up the Commit dialog where you can describe your commit and finalize it.
Tip
Finalizing the commit (the Commit dialog)¶
Clicking the Commit files button in the main window brings up the Commit dialog, where you’ll be able to type up a commit message then confirm the commit.
A commit message consists of:
A mandatory summary line. Describe your changes in a few words so other people—including future you—can learn what your commit is about at a glance. Keep it concise: proper Git etiquette mandates to keep the summary under 50 characters and to avoid going over 72. (The character counter beside this field can help you stick to this guideline.)
An optional long-form description. Feel free to provide as much context for your changes as necessary in this field.
When you’re ready, click Commit—and you’re done! Notice your new commit in the Commit History: the HEAD branch now points to it, e.g. .
Your commits are local until you push them¶
So, you’ve created a commit. But it’s just sitting on your machine, for now—GitFourchette doesn’t send it to any remote servers automatically.
Notice that right after creating a commit, your HEAD branch has moved to your new commit () but the remote server hasn’t budged ().
This is nice, because it gives you a chance to amend your commit before anyone knows you’ve made a mistake in it.
Once you’re satisfied with your work, push your branch to a remote so the world can see what you’ve been working on.