Getting started with git commands

Reference

Liao Xuefeng git tutorial-recommended
git diagram
Branch naming convention
ps: The pictures are all other people’s

1.Basic concepts

Region

  • Four areas: Working Directory, Staging Area (stage/index), Local Repository, and Remote Repository. The relationship between them is as follows:

–

branch

  • Master branch (master/main) (the master branch is always the stable version available and cannot be developed directly on this branch)
  • develop (development of the main branch, all new features use this branch to create their own development branch, this branch can only be merged, and cannot be developed directly on this branch)
  • feature-xxx (feature development branch, create a branch on develop, name it after the function module you developed, merge it into the develop branch after the function test is normal)
  • feature-xxx-fix (feature bug repair branch, find the bug after merging the feature branch, create a branch on develop to fix it, and then merge it back to the develop branch)

tag tag

  • Tags are used to mark a specific point or commit in history and cannot be changed

head

  • As a pointer, HEAD points to the latest submitted node of the current branch;

.gitignore

Official template, just use it
Put files that don’t need to be pushed inside, and git will ignore these files.
for example:

.vscode/*.json

#C++
# Prerequisites
*.d

# Compiled Object files
*.slo
*.lo
*.o
*.obj

2.Basic operations

  • git clone "remote warehouse address" #Contains init operation;

  • git init #Initialize a warehouse locally

  • git remote add origin "address" Establish a link with the remote warehouse after #init; origin is the remote host name

  • git fetch #Fetch updates from all branches by default,

  • git pull (origin "remote branch name" : "local branch name") # Complete writing method; if the same name is used, there is no need to write the local branch name. If it is associated, just write git pull. The pull operation will be directly Pull the remote warehouse to the workspace!

  • git add "file" #Add the modified file to the temporary storage area git rm and git mv are the same.

  • git status #View warehouse status -s The parameters will be more concise

  • git diff "file name" #View the differences between the staging area and local warehouse files

  • git commit -m "First line description" -m "Second line description" # Submit to the warehouse, -am multi-line submission reasons

  • git log (--pretty=oneline) # View commit history git log --graph --pretty=oneline --abbrev-commitCommonly use this

  • git reset --hard HEAD~n/commit_id # Rolling back to a certain version will modify the workspace staging area and version library; soft retains the workspace and staging area, and mixed retains the workspace;

  • git branch -a/-r #View branch/remote warehouse branch -d/-D "branch name"Delete/force delete branch

  • git checkout -b 'branch name' #Create a new branch based on the current branch and switch to the new branch; equivalent to git branch 'dev' + git switch 'dev'

  • git push -u origin "local branch name" # Associate the local branch with the remote branch of the same name; if the remote branch does not exist, create the branch remotely.

  • git push origin -d "branch name" # Delete the local and remote warehouse branches, branch -r -d origin/branch name just delete the tracking branch

  • git merge "branch name" --no-ff # Merge a branch into the current branch without using fast merge and retain the information

  • git push origin "local branch name":"remote branch name" # Push the local warehouse to the remote warehouse;

3. Command description (organized slowly)

Order:
/add/commit/merge
/fetch /push /pull
/remote /branch /checkout
/rebase /stash /git cherry-pick
/reset /revert /restore
/log /relog /diff

3.1 add/rm/mv

Using git rm/mv is equivalent to adding rm/mv first to git add;

git add -f/--force #Force to add a file, which can be used to add files in .gitignore

3.2 push/pull/fetch

pull = fetch + merge

#Synchronize remote warehouse to local warehouse
git fetch "branch name"

#Associate to the remote library with the same name, if not, create a remote library with the same name
git push -u origin <local branch name>
#After association:
git push
git pull
#Unassociated push to the same name library
git push origin <local branch name>
git pull origin <remote branch> #Don’t do it the other way around! !
#Full command:
git push origin <local branch name>:<remote branch name>
git pull origin <remote branch name>:<local branch name>

# Delete remote repository
git push origin -d "branch name"

3.3 remote/

About remote warehouse operations

git remote add "remote host name default origin" "address"
git remote -v #Display the linked remote repository

3.4 stash

Save work in the stack,

git stash
git stash list
git stash pop
git stash apply ID
git stash drop ID

3.5commit/merge/cherry-pick

git commit "File" -m "Description 1" -m "Description 2"

git merge "branch name" #default quick merge
git merge -no-ff -m "merge fix bug 01" #Recommended method

git cherry-pick commitHash #Merge a commit on other branches

3.6 log/reflog

log has many optional parameters

git log --pretty=oneline #Single line display
git log --graph # graph
git log -5 # Display the last 5 commits

3.7 diff



3.8 branch/switch/checkout




The checkout command had two core functions of branch management and file recovery in early versions, but these functions were divided into two independent commands, switch and restore after version 2.23. Therefore, it is recommended to use the switch command if you just need to create and switch to a new branch (no need to check out files or undo changes, etc.). The switch command can better ensure the safety of branch operations, because it prohibits switching branches on uncommitted changes (unless the –discard-changes option is used to discard the changes)




git branch -m <branch-name> #Rename
git branch <branch-name> #Create a new branch
git branch -a #View all branches
git branch -v # View remote branches
git branch #view
git branch -r -d/-D "branch name" #Delete tracking branches and local branches; if you want to delete remote branches, use push -r, which is --remote

git switch branch #switch branch
git switch -c newbranch (ori_branch) #Create and switch to a new branch
git checkout -b newbranch (ori_branch) #Create and switch to a new branch




3. restore/reset/revert


Git Reset three modes




The restore command is used to restore files in the workspace. It can restore files from the staging area (index) or commit (commit) to the workspace.
 The essence of reset is to reset/move the node pointed by HEAD (with branch).
 The principle of revert is to cover previous problems by submitting new ones.




git restore <file>
git restore <file> --source=HEAD #Restore the file from the staging area to the work area.
git restore <file> --source=<commitHash> #Restore the file from the specified commit to the workspace.

git reset --hard HEAD^/HEAD~n/commitHash #Return to a certain node, and all local warehouses in the temporary storage area of the workspace will be rolled back
git reset --mixed ... # mixed is also the default parameter, which only affects the staging area and local warehouse, and retains the contents of the workspace
git reset --soft ...# only affects the warehouse, and both the staging area and the work area are retained (it should be said that the staging area will store the differences caused by resetting HEAD)

git revert commitHash



4. Practice




These are simple questions that must be mastered




4.1 Synchronization/Multiple Collaboration




You are working in the local warehouse, and now the remote warehouse is updated. How should you synchronize the updates and continue your work?




git fetch origin #Get the updated contents of the remote library to the local warehouse
#If it does not affect your work, then there is no need to merge, otherwise it needs to be merged
git switch "working branch"
git merge origin/"branch to be merged" # If there is a conflict, resolve the conflict first; git pull is equivalent to fetch + merge?
#Normal operation after that
git add ..
git commit -m ""
git push origin "local branch"



4.2 bug branch




How to fix a bug found on dev or master: Create branch bug_fix007 locally and merge it into the main branch after modification.




git checkout -b bug_fix007 dev
#After modification
git push -u origin bug_fix007 #Create a remote branch with the same name and push it,
#or
git switchdev
git merge bug_fix007 -m "merge bug_fix007"





Your current work is not completed, but you need to deal with other issues in the code at this time, such as fixing a bug or submitting another branch soon, or when multiple people are collaborating and the current work is not completed. In order to avoid conflicts with others, you need to What should I do if the changes are temporarily stored?




#Use stash to save uncommitted files in the stack. At this time, use git status and you will find that the workspace has become clean.
git stash
git switch master #Switch to the branch that needs to be modified
git branch -m issue-01 #Create a temporary branch issue-01 on the dev branch
git add
git commit -m "fix bug 01"
git switchdev
git merge -no-ff -m "merge fix bug 01" #bug modified
git switch dev #Return to the work between
git status #Clean workspace
git stash list #View stack,
git stash apply (stash@{<!-- -->n}) #Restore the content, the stash content is not deleted, the default is the top of the stack, you can also specify n, n can be viewed through the list.
git stash drop #Delete the contents of stash. You can also use pop directly to pop the stack.





There is a problem at this time, that is, dev also comes from master, so this bug also exists on dev. How to quickly solve this problem?




git cherry-pick commitHash





Other solutions: first use git stash to save unfinished work; then fix the bug on dev,
 There are many other operations on stash. Note that stash can only save files that have been tracked. If you create a new file without add, it will not be tracked. Stash will be invalid and can also be seen in other branches.




4.3 Rollback




What should I do if I find errors in the submitted content, which may be in the staging area or have been submitted to the local warehouse?




# If it is in the temporary storage area:
git restore --staged <file>... # git status will automatically prompt to cancel the staged save
# If it has been submitted to the warehouse, then there are two ways: one is to commit the modification, but the record will be submitted again; the second is to use reset, so that it will not appear in the log.
git log #View commit records
git reset --hard HEAD^/HEAD~n/commitID #Return to a certain node, and all local warehouses in the temporary storage area of the workspace will be rolled back
git reset --mixed # mixed is also the default parameter, which only affects the staging area and local warehouse, retaining the contents of the workspace
git reset --soft #Only affects the warehouse, and both the staging area and the work area are retained (it should be said that the staging area will store the differences caused by resetting HEAD)





You want to undo a commit to the remote repository. Don’t care about others, how to operate




git pull
git reset --hard/soft/mixed HEAD^
git push -f #force push





You want to undo a commit to the remote repository. At this time, you may think of using reset to roll back, but if you look at the latest commit on the branch and the code of other colleagues, using reset will also withdraw this part of the code. What should you do at this time?




git pull
git log -10 #View the last ten commits and find the hash value of your submission
git revert commit_id #Create a new commit to make up for previous mistakes
git revert -m 1 <commitHash> #Sometimes if you don’t know which one is the main line, use this command and let’s talk about it later.





What should I do if I misuse reset --hard or remember the commitHash incorrectly?




git reflog # Powerful regret medicine, search command records, find the commitHash of the wrong submission /
git reset --hard commitHash



4.4 branch problem




When using git clone, you can only see the local master branch by default. What if you want to develop on the dev branch?




git clone ""
git branch #found only master
git checkout -b dev origin/dev #Create the dev branch of remote origin to local
# Push after local modification
git branch --set-upstream-to=origin/dev dev #Link local and remote branches. After push/pull fails, git will prompt,
git push origin dev #





If you create a branch locally but do not have it remotely, you want to push it locally to the remote repository with the same name.




git checkout dev
git checkout -b feature_01 #Create a new branch feature_01 from dev
git push -u origin feature_01
#The function of this command is to push the local feature_01 branch to the feature_01 branch of the remote warehouse (origin).
#At the same time, if the remote warehouse does not yet have the feature_01 branch, this command will automatically create it. The -u parameter indicates setting the dev branch as the default push branch.





The remote origin/dev branch is too behind, how to update it?




git switch master
git pull
git checkout -b dev origin/dev #Create a local branch
git merge master -m "update dev" #Merge
git push (-f origin dev:origin/dev) #push



5 Supplementary knowledge


5.1 About commitHash




git reflog found several times the commithash of the command history is the same \






- git reflog can find that the commit hashes of multiple command histories are the same because they correspond to the same commit.
Each submission generates a unique commit hash, which is calculated based on the submitted content and other relevant information.
Therefore, if the contents of the commits are exactly the same in different branches or operations, the commit hashes they generate will be the same.

- For example, if multiple commits are made on a branch and then the same commit is made on another branch,
Then the commit hash of these two submissions will be the same. This is because they all correspond to the same submission content.

- In addition, git reflog can view all operation records of all branches, including commit and reset operations, and can be used to restore accidentally deleted branches or retrieve lost commits.
Among them, the commit record contains the complete information of the submission, and the reset record means moving the HEAD pointer to a previous submission.