The Common Series is a record of things I frequently use in programming. This article is the second in the series, used to document my commonly used Git commands for easy reference when needed. Although Git provides a GUI interface for operations, I believe there are many Git GUI tools, but mastering the most commonly used commands is something a qualified programmer should do. After all, commands work the same everywhere, but what if one day the GUI software becomes unusable? 🐶 Moreover, the command line mode can execute all commands of Git.
The Most Basic Operations of Git#
The process of moving files from local to repository: The following records the commands that can push a file from my local to the remote repository, which I call basic operations.
Install Git#
If you want to install Git on a Mac, just enter the command to check the git version, and it will prompt you to install (if you haven't installed it before).
Configure User Information#
After installing git, configure the git environment. These configurations only need to be set once on each computer. Of course, they can also be modified after configuration. The most commonly used configurations in git are the settings for username and email address, where
--globalmeans 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 logged-in users on the system
Display Config Configuration#
Get 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
Initialize Repository in an Existing Directory#
This command will create a .git directory in the current directory, which includes all files for initializing the repository.
Clone Repository#
This command will pull everything from the remote GitHub libgit2 repository to your current directory.
Record File Status#
There are 2 types of file status: tracked and untracked. Tracked means that Git can now record all changes to this file (modified, deleted, renamed).
Query File Status#
Track 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.
Compare Differences#
Compare the differences between staged and unstaged files.
When we modify too many files, we may easily forget the changes made to a certain file. At this time, we can use the
diffcommand to see what modifications we have made.
If you want to compare the differences between the files in the staging area and the last commit, you can use the following command:
You can also compare the differences between two different commits:
Rename Files and Folders#
git mvis the command used in Git to rename or move files or folders.
Commit Updates#
If your staging area already includes the files you want to commit this time, you can use the
commitcommand to commit the changes to the files.
Push Files to Remote#
Add 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.
Push#
This command indicates that the code from the master branch is pushed to the remote origin server.
At this point, the process of a file from creation to final synchronization to the remote repository is successfully completed.
Next, I will record some commands to use when encountering certain situations during the use of git.
Commit Operations#
Modify the Last (Most Recent) 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:
Query#
The records here are various situations that need to be checked in the context of using git.
Check Commit History#
Entire Project's Historical Commit Records#
The output content includes:
- SHA-1 checksum of each commit
- Name of the committer
- Email address
- Commit time
- Commit message
Historical Commit Records of a File#
View the commit records of a single file each time.
Commit Records of Each Line#
Can display the last modification commit record of each line in any file.
Find Bugs#
Many times, when there is a problem in the current branch, but it is unclear where the problem occurred, you can use the
git bisectcommand to find out which commit introduced the error.
The principle of this command is binary search:
By binary searching the range of commits that are fine ~ the current problematic branch, you can find the commit that may have issues.
The command git bisect start starts the error search, and its format is as follows:
End is the most recent commit, and start is an earlier commit. The history between them is the range of errors.
When you are unsure which starting commit was fine, you can choose the very first branch.
After executing the above command, the current code will switch to the middle commit within this range.
Then you can test the current code. If there are no issues, execute the following command to mark this commit:
If there are no issues, it means the error was introduced in the latter half of the code history. After executing the above command, Git will automatically switch 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, keep repeating this process until you successfully find the problematic commit. At this time, Git will give the following prompt.
Then you can analyze which files were committed this time to analyze what caused the error.
Note: Code defects need to be judged by 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.
Search for Content#
Since git is similar to Linux commands, it can also be used with
grep.
Undo#
When operating Git, it is inevitable to make mistakes. The way to correct errors is generally either to modify again or to revert to a problem-free state.
File Undo#
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), returning them to the working directory.
Version Undo#
Commonly used after committing a version, when there is a conflict in the remote and cannot merge branches, use
git resetto revert the version, handle the conflict, and then push again.
Stack Operations#
During development, it often happens that a requirement has been developed to a certain extent, and the local code has been modified a lot, but suddenly a temporary BUG needs to be handled urgently. In this case, the modified code can be saved by putting it into the git stack, and after the BUG is handled, the scene can be restored to continue the development of the requirement.
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 a conflict:
- First manually resolve the conflict, then add the newly modified files to the staging area
git add . - After that, there is no need to
git commit, just rungit rebase --continue.
As for the difference between git merge and git rebase?
- After
git merge, the merged branches will be displayed, while aftergit rebase, there will be no record of the previously merged branches. - The order of branch merging is also different.
For more details, you can check 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, re-add the modified files to the staging area
git add . - Use the following command to let the Cherry-pick process continue.