7 Basic Git Commands
In this Git Weekly issue, we'll cover what basic commands are used when committing directly to the main branch. As a few commands have been introduced recently in the git API (e.g. git restore was introduced in August 2019), reading through the issue will be worthwhile even for experienced users.
0. Set Name and Email
This is a setting that should be set before someone can commit:
git config --global user.email <email>
git config --global user.name <name>
As an example, I do:
git config --global user.email "[email protected]"
git config --global user.name "Mohammad-Ali A'rabi"
1. Git Clone
Assume that you have created a repo on GitHub or GitLab and initialized it with a README file. To make a copy of it locally, one should clone the repo.
There are usually two ways to clone git repositories:
The latter is recommended but needs you to save your SSH keys in your GitLab/GitHub account. With the former, you need to enter your account password manually every time you want to push.
To clone using any of the two methods, copy the URL, and use the following command:
git clone <url>
As an example, the following is cloning using the SSH method:
git clone [email protected]:rxjsx/rxjsx.git
And this is cloning the same repo using the HTTPS method:
git clone https://github.com/rxjsx/rxjsx.git
A new directory will be created by running this command and your repo is copied into it.
2. Git Log
Git log is the command that shows information about the commits:
git log
And the output will be something similar to this:
commit a582046e47cd25e0c20755828a3189b346c1ada7 (HEAD -> master, origin/master, origin/HEAD)
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Tue Apr 26 10:00:41 2022 +0200
Docs: Add code quality badge
commit b848e1ccd6ff6cf57846e50ad5a0bfd5d77136a3
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Fri Apr 22 00:30:33 2022 +0200
Build: Remove comments from tsconfig.json
The main reason is that Snyk cannot import the project currently.
commit 91bbb10c11178b50e04fc9c8888b80b5ddbc8574 (tag: v1.0.0)
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Thu Apr 21 16:58:34 2022 +0200
1.0.0
commit a47da95b438adf5ec70daf94cac52e82e1e23e20
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Thu Apr 21 16:56:53 2022 +0200
Docs: Add more examples
Fixes #4
This is the information about the last 4 commits. Take the first one:
commit a582046e47cd25e0c20755828a3189b346c1ada7 (HEAD -> master, origin/master, origin/HEAD)
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Tue Apr 26 10:00:41 2022 +0200
Docs: Add code quality badge
It shows the commit hash in the first line, together with the "extra labels":
The second line shows the author's name and email. The email address shown here is one created by GitHub so the original one is not exposed.
The third line is the date and time in which the commit was created. In this case, it was the 26th of April, 2022, at 10:00:41 AM in the German Summer time.
And finally the commit message.
3. Git Status
The status message is mainly about the files, rather than the commits. Let's try it out:
git status
The output is similar to this:
On branch aerabi/add-codeql
Your branch is up to date with 'origin/aerabi/add-codeql'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
modified: package-lock.json
modified: package.json
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.txt
no changes added to commit (use "git add" and/or "git commit -a")
It basically says that README.md, as well as two other files, are modified, but not staged (we'll get to that part). At the same time, temp.txt is not tracked by git at all.
4. Git Add
If you want to commit some changes, you have to "stage" them first. This is done by:
git add <path>
In the previous example, let's assume we want to commit the README file:
git add README.md
And then, by doing a git status, we'll get:
On branch aerabi/add-codeql
Your branch is up to date with 'origin/aerabi/add-codeql'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: package-lock.json
modified: package.json
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.txt
5. Git Restore
The restore command has two main functions:
5.1. Git Restore to Unstage
This is the inverse of the git add command:
git restore --staged <path>
In the previous example, let's assume we have accidentally staged the package.json file as well:
On branch aerabi/add-codeql
Your branch is up to date with 'origin/aerabi/add-codeql'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
modified: package.json
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: package-lock.json
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.txt
But we don't want to include these changes in the next commit. To unstage the changes in package.json, do:
git restore --staged package.json
This will result in package.json being removed from the list of changes to be committed:
On branch aerabi/add-codeql
Your branch is up to date with 'origin/aerabi/add-codeql'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: package-lock.json
modified: package.json
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.txt
5.2. Git Restore to Discard
This variant of git store discards all the changes in a file, completely:
git restore <path>
In the previous example, let's assume we want to discard all the changes we made in package.json:
git restore package.json
This will result in the file being restored to its status in the last commit:
On branch aerabi/add-codeql
Your branch is up to date with 'origin/aerabi/add-codeql'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: package-lock.json
Untracked files:
(use "git add <file>..." to include in what will be committed)
temp.txt
6. Git Commit
The commit command will "commit" all of the staged changes in the local repo:
git commit -m <commit_message>
In the previous example, we can commit the changes in README.md by:
git commit -m "Add test coverage badge to README.md"
Try always to have an informative commit message. More on commit messages:
The output of the commit command is:
[aerabi/add-codeql 1b3f325] Add test coverage badge to README.md\
1 file changed, 1 insertion(+)
It means that one line was added to one file. Now let's look into the commits:
git log
The output:
commit 1b3f32586edf82a6e51c3a2a71cda0cd05ea8500 (HEAD -> aerabi/add-codeql)
Author: Mohammad-Ali A'rabi <[email protected]>
Date: Mon May 30 10:45:35 2022 +0200
Add test coverage badge to README.md
commit a58060cc5263fa66f5b5f61dd395baead10536a9 (origin/aerabi/add-codeql)
Author: Mohammad-Ali A'R?BI <[email protected]>
Date: Thu Sep 16 13:36:39 2021 +0200
Create codeql-analysis.yml
As you can see, a new commit was added and timestamped on May 30th. The label HEAD -> aerabi/add-codeql is on the last commit, meaning that it's the last commit on the branch aerabi/add-codeql on the local repo. The other label, origin/aerabi/add-codeql which is on the second commit, shows that the remote branch does not have the commit I have made locally.
To update the remote branch, we have to push it!
7. Git Push
The push command will update a remote branch with the local changes.
git push
Summary
This basic guide was aimed at someone who is new to git and wants to work with the main branch of their own repo, with no other collaborator. Other posts regarding branching and collaborating will come in the future weeks.
Stay tuned for more weekly git tips!