As we have just learned, adding a file or committing it is basically a two-step process.
Add the files to the staging area. Like the command below,
$ git add test1.txt
file1.txtis added from your working copy to the staging area and it ready for committing to the repository. Whenever we create a file, it’s on our working copy, it’s on then local computer and after
git addcommand, it goes to the staging area.
It takes all the files from your staging area to push them to the repository.
$ git commit -m "commit message"
We normally add message to describe what does this commit, like what we have changed in the files or projects, therefore we could get the logging information of this commit in the future.
After you have changed a file and saved it, this file on our computer is different than the file in our repository, because in the repository it is still the same content before this modification. If you type
git status, you could see that
git knows your file has been updated.
$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: test1.txt no changes added to commit (use "git add" and/or "git commit -a")
As suggested by
git, we use
git add to update the files that will be committed.
$ git add test1.txt
Now, you could commit this updated file from the staging area to the repository.
Sometimes, we have updated multiple files and of course we could add files in this way,
$ git add test1.txt test2.txt test3.txt
But it brings you a big headache if you have bunch of files or the file name is too long.
git has a shortcut to add all the updated files and untracked file to the staging area,
$ git add .
. means all the files that are different from the repository.
We have shown how to use
git commit when we introduced other features of
git commit pushes the staging area to the repository, and you are strongly advised to add the commit message to describe what you have changed for this specific commit. You could get all your commit log information back with the
git log command.
Commit Directly to the Repository
Before what we commit, we need to add changes to the staging area. Then we could commit them. But there really isn’t a need to add them to the staging area. First, because we know that these changes we want in our final project, in our repository or on the server for everyone to have updated files.
So what we could do is check
git status first, so we know what’s modified in the working copy. Then we could directly use
git commit before even adding these modification to the staging area.
$ git commit -a -m "commit message here."
what we do here is we use a shortcut instead of adding it to the staging area. But this is only useful in certain situations, whenever you use this command, you need to be careful because it’s going to grab everything in your working copy and push them right to the repository.
Amend a Commit
We could have come to a situation after a commit, we find a typo or other tiny faults in the code. Of course, you could revise the codes and commit the changes to the repository again. But what we could do is that we rewrite this most recent commit, and the latest commit will be rewritten with the new modification.
git commit tells
git that this commit will replace the previous commit that will not be in your working branch any more.
$ git commit --amend "new information is updated"
Never amend a commit that is not the most recent commit any more, because other team member or other branches have the version based on that commit. After amending, they lose their reference point and it is difficult to recover from it.