A commit is a set of changes to the files tracked by your repository. This can include files added, files removed, and files changed.
To commit is to add a new commit to the repository history.
A repository (or repo) is a folder where you can specify files for git to track. In each repository, you can commit files and folders and have git remember what changes you have made. You can also push your changes so that people you’re working with can see them.
If you’re not starting a new project but are making changes to a project that already exists, it makes more sense to “clone” the repo - that means to download a copy of a git repository stored somewhere else.
Now that you have a git repository on your computer, you will be able to examine the status of the git repository and make commits.
After creating, deleting, or editing some files, you can ask git to tell you which files have been modified since the last commit.
Get used to running this command often!
In order to commit a change or a set of changes, you must “stage” them first.
It’s better to create many small commits rather than one big one, which is why it’s better to use the first version to stage specific files. This lets you create a commit corresponding to a specific change.
There’s even more you can do with the staging area - be sure to checkout the section on “More On The Staging Area” later on this page.
Sometimes you want to know not just which files you’ve changed and/or staged, but also what in the file was changed.
Once you have staged all the changes you want for a commit, you can tell git to make a commit.
Now that you’ve made a commit, it will show up in git’s record of commits.
You will be using this command a lot too!
You can always check what the last commit changed.
Sometimes you want to “undo” a commit. You can do this in git by reverting the commit. This creates a new commit that undoes all the changes of the commit.
If you’d like to make a lot of commits and keep them logically separate for a while, while still sharing them with other people, you can use branches. This is frequently used when adding a large feature to a project: you work on the new feature in a new branch, leaving the master branch clean for others (or yourself) to make bugfixes; then, when the new feature is stable, you merge it back into the master branch.
(Yes, the naming of this command is kind of inane. It’s equivalent to running
git branch <branchname> to create the branch, and then
branchname to switch to it.)
The one you are currently on will have a star next to it.
Now you can make changes and commit as usual on any new branch you create. At some point, you’ll want to merge the changes made on one branch to your “main” branch.
This will merge the branch called “branchname” into your current branch. So if
you want to merge “branchname” into the master branch, you should
the master branch, then run
git merge <branchname>. This will pull in all the
changes from the branch into the master branch. You may have to resolve some
conflicting changes by hand.
Earlier on, you may have “cloned” your git repository from another place, like Github. So there you were downloading changes to a git repository. You can also upload changes, which we call “pushing”.
You may have to replace “origin” with the name of the upstream to which you want to push (if you cloned the repository, it will be “origin” by default). You may also have to replace “master” with the branch you want to push changes from.
There’s a trick you can do to shorten this command:
So far, all of the commands discussed have dealt with the files in your directory (the “working tree”), the local repository, and possibly a remote repository. There is actually a fourth area where your changes can be stored, called the “index”, which is logically located between the working tree and the repository. The index is a sort of staging area for commits, giving you the ability to control and inspect exactly what will be included in a commit. When something is in the index, it is said to be “staged”.
To “stage” changes (to add changes from your working tree to the index), you can use various forms of the git add command.
git add <files>- add the listed files to the index
git add -p- interactively add “hunks” to the index. This examines all files tracked by the repository, detects the sections that have been modified, and lets you add sections of files individually.
git add -p <files>- like git add -p, but only looks at the listed files.
You can examine the staged changes with git diff –cached.
If you have staged changes which you wish to remove from the index, the command git reset can remove them:
git reset <files>- unstage all changes from the listed files.
git reset -p- interactively remove staged hunks from the index.
git reset -p <files>- probably what you expect
git reset --mixed- unstage all changes in the index
Once you have modified the index to your liking, you can commit the staged changes with a simple git commit (no arguments!).
You can use the Git man page:
man git to see an overview, or
git help <command> to open the man page for each individual git command.