Github branch handles stash, rebase, merge, fastforward and branch code submission to the main branch

1 Three areas for git file storage

Git’s file storage is divided into three areas, namely workspace and Staging area and code warehouse (repository). The purpose of dividing into three areas is also very clear, which is to isolate local untracked code and warehouse version code, and to greatly facilitate the storage of local untracked code.

Workspace is a location where the code is not tracked by the git software. When we modify the code, it is as if there is no version management software;

Code repository is the location where the local git version management software stores all submitted versions;

The middle temporary storage area is self-evidently an area for buffering, which can integrate each request to Modifications submitted in the temporary storage area, and after all modifications are completed, the code will be pushed to the local code repository .

The git software also provides a stack structure stash. Compared with temporary storage area, stash operations can only be processed each time in the form of a snapshot. Push the stack, and the snapshots stored in each push cannot be merged. This can reflect the advantages of temporary storage area

Three areas of git Git adopts an incremental file storage system, similar to hadoop The redo log or the bin log in MySql master-slave mode, so each submission essentially records a different record compared to the previous submission.

2 git simple submission format and query and modification of three location files

The process of git submitting files from the workspace to the local version repository is very clear:

> git add . # Add all files at once
> git add [file_name] [file_name] ... # Add specific files
> git commit -m "comments for this commit"

If we need to query files in various locations, we can use the ls-files tool

> git ls-files -c # List files in the staging area
> git ls-files -o # List untracked files, that is, files in the workspace
> git ls-files -t # List all tracked files
> git ls-files -s # Display all file status information

After querying the location of the file, if you want to clear the files that have been submitted to the temporary storage area, you can use the –cached long parameter to delete the temporary storage area files.

> git rm -r --cached # Clear the temporary storage area
> git rm [file_name] [file_name] ... --cached # Clear the specified file

3 git rebase

The rebase operation is suitable for merging multiple commits on the same branch into one commit, with the purpose of simplifying the commit history on the branch. The rebase operation usually has the following three steps:

Initiate rebase
Enter the interactive interface, choose to merge commits and retain commits, and add a description for this rebase.
end rebase or terminate rebase

> git rebase -i [Oldest commit number that needs to be merged] [Latest commit number that needs to be merged]

Note: If the second parameter is blank, git defaults to the commit pointed to by the HEAD pointer, which is usually the latest commit.
In addition, we can also use HEAD~[position] to specify the commit. The commit pointed by the HEAD pointer (usually the latest commit) defaults to HEAD~1, and the position is an Arabic numeral. The value increases sequentially from the commit pointed by the HEAD pointer;
The above merged interval is open on the left and closed on the right.

It should be noted that rebase can only merge a series of commits that have at least one common ancestor commit, but this common ancestor cannot be the first commit of the warehouse.

After entering the interactive interface, the first few lines are the commit numbers that need to be merged. Note that all submissions are arranged in descending order of time, that is, newer submissions are at the top and older submissions are at the bottom. We usually choose to keep the latest commit, that is, keep the first row, and then merge all rows after the first row or merge to the specified row
Follow the prompts, keep the parameter as p, and merge the parameter as s

Finally, if there are no conflicts, we will enter the commit phase of the final commit statement. By default, git will record all merged commit instructions into the commit instructions retained after the merge. We also need to add a new description for this merge. If all past instructions are not needed, the unnecessary instruction lines can be deleted at this stage.

If there is a problem with rebase, you need to perform the following operations

> git rebase --todo #Remodify the merged file and return to the second step
> git rebase --continue #After modification, continue the rebase process
> git reabse --abort #terminate this process

After a rebase, the local code may have historical differences from the remote code, and the remote code version may lag behind the local version. At this time, if you are sure that the local version is the latest version, and you want to overwrite the remote history through the local code submission history, you need to use the –force parameter to force override. The usage is as follows

> git push [remote repo alias] [local branch name]:[remote branch name] --force

4 git merge

The essence of the merge operation is to merge the changes in two commits that have at least one common ancestor, and combine the results to produce a new commit that is stored in the code repository. Starting from this concept, we can divide the merge operation into two different situations:

Starting from the same commit, two different branches A and B are branched. In the future, A and B will develop and submit independently at the same time, and finally hope to merge the B branch into the A branch. This is the most common three-way merge. We It can also be said that the merge operation is to merge the specified branch into the current branch

> git checkout [branch A] #Needs to be on the branch that is on the trunk after merging
> git merge [branch B] # The parameters of merge need to be the branch that disappears after the merge

After submitting the merge request, you will enter the interactive interface. If there are differences between two versions in the two submissions, this is also called a conflict; the interactive interface will display the conflict between the two versions through comparison, and Clear prompt messages will also be generated in the corresponding files. At this point we need to exit the interactive interface and then modify the corresponding files.

It should be noted that the files in the workspace during the merge process are actually files that git extracts at the common ancestor of the two commits and overlays the modifications generated by the commits of the two branches that need to be merged. So this is a completely new filesystem snapshot, not either of the two comiit. Then choose to continue the merge or terminate the merge;

> git add . # After making conflict modifications, the modified code needs to be stored in the temporary storage area
> git merge --continue # Continue to merge, this command will enter the step of generating new commits
> git merge --abort # Terminate the merge at this time, and the system will return to the state before the merge.

The operation of continuing the merge is actually the operation of generating a new commit. We need to submit the description of this commit in the interactive interface, then submit the commit, and the merge ends.

Starting from the same commit, two different commits on the same branch. At this time, git will use fast-word mode to merge, that is, directly point the HEAD pointer to the latest commit, and no new commit will be generated.
If you want git not to use fast-forward mode for merging, that is, if you want to be able to generate a commit that marks the merge after the commits on the same branch are merged, you can use –no-ff Parameters

> git merge [commit] --no-ff

5 Differences between merge and rebase

First of all, it is recommended to use rebase on a separate branch rather than between branches to reduce confusion caused by commits between branches.
Secondly, the rebase operation on the same branch is similar to the merge fast forward operation. The difference is that rebase will synchronously delete all commits in the merge interval, while merge fast forward will only move the current HEAD to the specified commit, and will not Delete the commit between the two merge points
Therefore, merge is often used to solve the merge operation between branches, and is an important operation for merging the development branch into the main branch; while rebase is often used to solve the merge of redundant commits within the branch, and is an important operation for coordination and organization within the development branch.

6 git stash

stash provides a stack storage space for storing modifications made in the workspace. However, it should be noted that the bucket file stored by stash is only based on the current branch, and in order to avoid version conflicts, it is best to make a commit before stash.

File area snapshots in stash are stored in a stack, and each location has its own number. If multiple file area snapshots are stored, we can index by number.

> git stash save "message" #Save the currently uncommitted modifications to the staging area and add a description message.
> git stash list #List all stash records.
> git stash apply [stash_id] #Apply a certain stash record and delete it from the stack.
> #If stash_id is not specified, the latest stash record will be applied by default.
> git stash pop [stash_id] #Apply a stash record and delete it from the stack.
> #The difference from apply is that the pop operation will pop the stash record on the top of the stack.
> git stash drop [stash_id] #Delete the specified stash record.
> git stash clear #Clear all stash records.
> git stash branch [branch_name] [stash_id]
> #Create a new branch and apply a stash record to the branch.
> #If stash_id is not specified, the latest stash record will be applied by default.

7 Applications in Development

During development, we often pull branches from the master, and then carry out iterative development of product functions. After the development is completed, we merge the branch back to the main branch. At this time, we recommend:

a. Use git stash to save the code of your own development branch into the staging area and restore the local warehouse to the state before modification;
b. checkout master to enter the main branch, and git pull pulls the latest commits of master;
c. Checkout mydev to enter the development branch, and merge the latest commits of the master into its own development branch through git rebase master, ensuring that the historical commits of the branch are the same as those of the master;
d. Use git stash pop to take out your modifications; git commit and git push to the remote development branch;
e. Initiate a merge request and merge into the master branch

Directory