This is the 11th day of my participation in the More text Challenge. For more details, see more text Challenge

1, Git rebase and Git merge

Git Rebase solves the same problem as Git Merge by merging commits from one branch into another,

(1), merge

Merge to switch to newBranch and merge the master code

git checkout newBranch
git merge master
Copy the code

Advantages: Merge it preserves the branch structure and the historical commit directory, but also causes the commit history to be polluted by merges

Rebase is a common, but not very good command, rebase merge is also known as: rebase

(2), rebase

Rebase operations compress all commits into a single patch and add the patch to the target branch. Rebase creates new commits in the project history for each of the commits in the original branch.

git checkout newBranch
git rebase master
Copy the code

Advantages: Rebase displays the history in one line, which makes it clearer to obtain the project history. It eliminates the unnecessary merge commit record required by merge. At the same time, when rebase merges the base, it loses the context information of the commit, which makes it impossible to see the true merge time

2, interactive Git rebase-i
git checkout newBranch
git rebase -i master
Copy the code

Go to the edit page, show the record of each submission, you can edit, remove, readjust the record of submission, the record of submission can be changed to whatever you want,

Multiple Commits need to be merged into a single commit

-i means interactive mode, which means you can intervene in the rebase transaction process, including setting the Commit message, entering edit mode, and some common parameters

Pick: means include commit, and use the commit information squash: This command allows you to combine two or more commits into a single commit. The commit is compressed into the commit above it drop: a commit record is droppedCopy the code
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#. create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
#. specified). Use -c 
      
        to reword the commit message.
      
#
# These lines can be re-ordered; they are executed from top to bottom.
Copy the code
3. Compare git merge with Git Rebase
# git merge1, record the merge operation action, many of which are useless merge information 2, do not change the commitId, commit the record in order, but the branch looks not orderly 3, the conflict is resolved only once
# git rebaseChange all commitids so that the commit record is one line, the project history looks simpler, and the commit history is clearer. 3. Each commit needs to resolve conflictsCopy the code

Suggestion: To make the submission history clearer and easier to understand, using Rebase is a wise and efficient choice

#Field notes3, git rebase --continue 4, git rebase -- I HEAD // Change the structure, order, history, etcCopy the code
4, git tag

Add a tag to the project and label it

Git tag release 1.0.0 Git push origin release 1.0.0Copy the code

Note: When we complete a requirement and are ready to release online, we should mark the complete project code and release the marked version online. ReleaseV1.0.0 bit tag name, tag name can be better meaning, convenient code rollback, search, location

* * mark is used for a specific point or submit history, usually used to mark the release of the name and version number, someone asks what is the difference between the tag and branch, in fact, the mountains are the same, a complete branch can also be used to release, but: branding submission is fixed, can’t change, and mark has more meaning.

5, HEAD

HEAD indicates the latest commit of the current branch, that is, the latest commitId

The last version was HEAD^

The last version was HEAD^^

Of course, it’s not convenient to write 100 ^ for the first 100 versions, so I’ll write HEAD~100

#Check the commitId
git log 
#Shuttle to a specific commitId location
git reset --hard commitId  
#To go back into the future, look at the command history
git reflog
Copy the code

Git reflog: Git reflog allows you to view all branch operations, including commit, reset, and deleted commit records. Git reflog does not allow you to view deleted commit records

6, actual operation
#Package and extract one of the tagged versionsGit archive -v releaseV0.1 > releasev0.1. zip --format=zip  
#Run Git's garbage collection to clean up the historical snapshots
  git gc
  
#To retrieve updates from the remote repository back to the local repository, pull all branches by default
  git fetch

#Add a new remote repository, specify a name,
  git remote add origin https://xxxxxxxxx

#View the history of all branch operations, including commit, reset, and deleted
  git reflog
 
 #To undo an operation, both before and after the commit is retained, and the undo is treated as the latest commitGit Revert git Revert HEAD git Revert HEAD git Revert HEAD git Revert HEAD git Revert HEAD git Revert HEAD git Revert HEAD  
#Undo multiple operations and make one final unified commit
  git revert -n HEAD
 
#Anything in the staging area and workspace is discarded and the HEAD is pointed to COMMIT
  git reset --hard commit

#Nothing is changed in the staging area and workspace, just the HEAD is pointed to commit
  git reset --soft commit
  
#Merges one or more records of a branch to the current branch tip
  git cherry-pick commitId
  
#Displays history with comparison of commit differencesThe git log file  
#Output a short history
  git log --pretty=oneline
  
  
#Save uncommitted files to the cache
  git stash save 'xxxx'
 
#View the list saved in the stack
  git stash list
 
#Displays one record in the stack
  git stash show stash@{0}
 
#Remove a record from the stack
  git stash drop stash@{0}

#Check out the last saved record from the stack and remove it from the stack
  git stash pop

#Check out, but not remove, a record from the Git stack
  git stash apply stash@{0}

#Checks out and creates a branch from the most recent record in the current stack
  git stash branch branchName
  
#Clear all records on the stack
  git stash clear
  

Copy the code
7. Two questions interviewers should ask

Git rebase = git merge = git rebase = git merge

The rebase,merge differences can be summarizedCopy the code

2. What do you do when you are working on a feature in a branch and you are notified that there is a production problem that needs to be fixed urgently, but you have added other uncommitted code to the branch with a problem?

The main thing the interviewer is looking for is knowledge of git StashCopy the code