Common Series - Git Commands

The Common Series is a record of commonly used programming tools. This article is the second in the series, documenting my frequently used Git commands for easy reference. Although Git provides a GUI interface for operations, I believe there are many GUI tools for Git, but mastering the most commonly used commands is essential for a qualified programmer. After all, commands work the same everywhere, but what if one day the GUI software becomes unusable? 🐶 Moreover, the command line can execute all commands of Git.

Basic Git Operations#

The process of moving files from local to repository: Below are the commands that can push a file from your local machine to a remote repository, which I refer to as basic operations.

Installing Git#

If you want to install Git on a Mac, simply enter the command to check the git version, and it will prompt you to install it (if you haven't installed it before).

Configuring User Information#

After installing Git, configure the Git environment. These configurations only need to be set once on each computer, and of course, they can be modified later. The most common configurations in Git are setting the username and email address, where --global means it applies to all repositories on the system.

Config has three scopes: when not explicitly set, it defaults to local.

local: valid only for a specific repository
system: valid for all users logged into the system

Displaying Configurations#

Obtaining a Git Repository#

There are usually two ways to obtain a repository:

Convert a local directory into a Git repository

Copy a repository from elsewhere to your local machine

Initializing a Repository in an Existing Directory#

This command creates a .git directory in the current directory, which includes all files necessary to initialize the repository.

Cloning a Repository#

This command pulls everything from the remote GitHub libgit2 repository to your current directory.

Recording File Status#

There are 2 types of file status: tracked and untracked. Tracked means that Git can record all changes to this file (modified, deleted, renamed).

Checking File Status#

Tracking New Files#

After using this command, the file will be placed in Git's staging area, and the files in the staging area are candidates to be pushed to the remote repository.

Comparing Differences#

Compare the differences between staged and unstaged files.

When we modify too many files, we may easily forget the changes made to a specific file. In this case, we can use the diff command to see what modifications we have made.

If you want to compare the files in the staging area with the files from the last commit, you can use the following command:

You can also compare the differences between two different commits:

Renaming Files and Directories#

git mv is the command used in Git to rename or move files or directories.

Committing Updates#

If your staging area already includes the files you want to commit, you can use the commit command to commit the changes to the files.

Pushing Files to Remote#

Adding a Remote Repository#

If you did not clone the files from a remote repository but created the Git repository locally, you need to add the repository you want to push to before pushing to the remote repository.

Pushing#

This command pushes the code from the master branch to the remote origin server.

Thus, the process of creating a file and finally synchronizing it to the remote repository is successfully completed.

Next, I will document some situations encountered while using Git and the commands to use.

Commit Operations#

Modifying the Last Commit#

Modify the information filled in the last commit
Add modifications or files based on the last commit

Both situations can use the following command:

Querying#

This section records various situations where queries are needed in the Git context.

Checking Commit History#

Entire Project's Commit History#

The output includes:

SHA-1 checksum of each commit
Committer's name
Email address
Commit date
Commit message

File's Historical Commit Records#

View each commit record of a single file.

Commit Records for Each Line#

Displays the last modification commit record for each line in any file.

Finding Bugs#

Often, when there is an issue in the current branch, but it is unclear where the problem lies, you can use the git bisect command to find out which commit introduced the error.

This command uses the principle of binary search:

By binary searching the range between commits that are error-free and the current problematic branch, you can find the commit that may have issues.

The git bisect start command initiates the error search, formatted as follows:

End is the most recent commit, and start is an older commit. The history between them is the range of errors.

When unsure which starting commit was error-free, you can choose the very first branch.

After executing the above command, the current code will switch to the middle commit in this range.

You can then test the current code. If there are no issues, execute the following command to mark this commit as good:

If there are no issues, it means the error was introduced in the latter half of the code history. Executing the above command will automatically switch Git to the midpoint of the latter half.

Then test again. If there is an issue, mark this commit as bad:

At this point, it doesn't end here; there is an issue, but we need to find the first problematic commit.

Next, continue repeating this process until you successfully find the problematic commit. At this point, Git will provide the following prompt:

You can then analyze which files were committed in this commit to determine the cause of the error.

Note: You need to judge code defects yourself; Git cannot help you analyze where the problem lies.

Then, use the git bisect reset command to exit the error search and return to the most recent code commit.

Searching for Content#

Since Git works similarly to Linux commands, it can also be used with grep.

Undoing Changes#

When operating Git, mistakes are inevitable. The general methods for correcting errors are either to modify them again or revert to a previous state.

Undoing File Changes#

Operations in the Working Directory#

Revert all modifications that have not been added to the staging area.

Revert modifications in the working directory relative to the staging area. If there is no corresponding file in the staging area, revert to the version pointed to by HEAD.

Operations in the Staging Area#

Undo modifications to files in the staging area (unstage) and return them to the working directory.

Undoing Versions#

Commonly used after committing a version when there are conflicts in the remote that prevent merging branches. Use git reset to revert the version, resolve the conflicts, and then push again.

Stash Operations#

During development, it is common to have a requirement that has been developed to a certain extent, but suddenly a temporary bug needs urgent attention. In this case, the modified code can be saved in Git's stash and restored later to continue the development of the requirement after the bug is fixed.

Branch Operations#

Basic Branch Operations#

Merge#

Used to merge two branches.

Rebase#

Also used for branch merging.

The operation of merging branches is basically the same as merge.

If git rebase encounters conflicts:

First, manually resolve the conflicts, then add the modified files to the staging area with git add .
After that, you do not need to git commit, but directly run git rebase --continue.

What is the difference between git merge and git rebase?

After git merge, the merged branches will be displayed, while after git rebase, there will be no record of the previously merged branches.
The order of branch merging is also different.

For detailed information, you can refer to this blog Summary of git merge and git rebase.

Cherry-pick#

Merge a specified commit into the current branch.

If a conflict occurs during cherry-pick, after manually resolving the conflict, use the --continue command to continue the process.

After resolving the code conflict, add the modified files back to the staging area with git add .
Use the following command to continue the Cherry-pick process.

lMingyul