Git Tutorial - Git Workflow
As we have just learned, adding a file or committing it is basically a two-step process.
-
git add
Add the files to the staging area. Like the command below,
$ git add test1.txt
file1.txt
is 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 aftergit add
command, it goes to the staging area. -
git commit
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.
git add
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 .
Here, .
means all the files that are different from the repository.
git commit
We have shown how to use git commit
when we introduced other features of Git. Basically, 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.
The flag --amend
following 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 -m "new information is updated"
Founder of DelftStack.com. Jinku has worked in the robotics and automotive industries for over 8 years. He sharpened his coding skills when he needed to do the automatic testing, data collection from remote servers and report creation from the endurance test. He is from an electrical/electronics engineering background but has expanded his interest to embedded electronics, embedded programming and front-/back-end programming.
LinkedIn Facebook