Git Tutorial - Git Workflow

Jinku Hu Jan 30, 2023
  1. git add
  2. git commit
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 after git 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"
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.
Author: Jinku Hu
Jinku Hu avatar Jinku Hu avatar

Founder of 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