Git Practice Note

Pushing a branch to a remote warehouse usually serves two purposes:: 1. Collaborative development by multiple people 2. Remote Backup

In fact, commit is also a kind of "backup", but it is only local, you can use git reflog to repent. Do not use git reset head -- hard or git checkout-F and Other Dangerous commands if no backup is performed.
The importance of commit is also reflected in git rebase, git diff, git log... all around the commit object.

Multi-person collaboration branches are mainly divided: The Administrator creates a local development branch and pushes it to the remote & developer configuration Development Branch.

1. Create a local branch and push it to the repository
1. Make sure that the local branches can be compiled, preferably the code after reset head -- hard + git clean-DXF.
In this case, modifications to the local master must be submitted to the remote SVN master through the patch, and the remote SVN code will lag behind the master branch synchronized to the GIT server, lagging results in: the master branch of git cannot update the latest code, and the code in the workspace still exists in the stage region. If you want to create a development branch based on the local master, you need to remove these changes. Otherwise, when you execute git rebase master on the Development Branch in the future, the latest master (synchronized to git through SVN) conflicts with files mistakenly included in the Development Branch.
If you do not want to create a development branch based on the Local Master, you can use git checkout-B login_site origin/master to create
1.2.git checkout-B login_invite new branch created based on local base branch and switched to new branch
1.3.git push branches login_invite: login_invite is pushed to a remote repository. Note that the remote branch is not associated with the local branch.
1.4.git Branch -- Set-upstream login_invite branches/login_invite local branch associated with remote Branch

2. developer operations:
2.1 git remote add branches root @ app220:/home/git. Gold/×××-Dev (if a developer does not have a remote library, add it. If any, skip it)
2.2 git fetch branches (or git pull branches)
2.3 git Branch -- Set-upstream implements branches/branch (branches are created, and git checkout-B localbranchname repositoryname/remotebranchename or git checkout -- track localbranchname repositoryname/remotebranchname)
2.4 git checkout login_invite

How to Create branches locally or remotely:
1. Create a branch based on the local branch and checkout the branch (used before the Administrator pushes to the remote warehouse)
Git checkout-B newbranch master
2. Create a local development branch based on the remote branch and checkout the branch (developers track the remote Branch created by the Administrator)
Git checkout-B localbranchname repositoryname/remotebranchename

Development Branch rebase:
In the Development Branch git rebase master, the principle is to set the head of the current branch to the reference corresponding to the master, and then hit each commit independently from the Development Branch to the head one by one. In this way, the Development Branch is linear commit.
If you want to merge the branch content to the master, you only need to switch to the master, and then git merge dev_branch can achieve quick merge.
Once encountered: instead of git merge dev_branch, It is GIT diff master dev_branch. After the generated patch is reivew, It is patched to the master on SVN.
Note: Diff sequence between branches. Do not use git diff dev_branch master if you generate a master patch. Otherwise, only patch-r-P1 <patch can be used for reverse matching.

 

Differences between rebase and merge:

1. The results of git merge are not linear and there will be multiple parent commits. Compared with GIT rebase, there will be one more commit.

2. A discussion of stackoverflow:

Assuming you start out with a tree that looks like this

             A---B---C topic           /   D---E---F---G master

You'll want to run 2 commandsgit rebase masterTo make it look like this

                                        A'--B'--C' topic                                       /   D---E---F---G master

Then frommasterRungit merge topic, Which will do a fast forward merge, and you'll end up with a tree that looks like this

                                               topic                                             /   D---E---F---G---A---B---C -- master

Can I just checkout master and runGit rebase topic??

Running that command wowould result in a tree that looks like this

                                               topic                                             /   D---A---B---C---E---F---G -- master

This is the (somewhat edited) git documentationrebase, Hopefully this will help:

All changes made by commits in the current branch but that are not inUpstreamAre saved to a temporary area.

If you are ontopicAnd rungit rebase master, That means commits A, B and C are going into a temporary area.

The current branch is resetUpstream. This has the exact same effect as git reset -- hardUpstream.

At this point the temporary state of the tree looks like this

                          topic                        /   D---E---F---G -- master

The commits that were previusly saved into the temporary area are then reapplied to the current Branch, one by one, in order.

Commits a, B, c that were saved into the temporary area are "recommitted" to the branch you are currently ontopic.

                                             topic                                            /   D---E---F---G---A---B---C -- master

Runninggit rebase topicFrommasterWocould perform the exact same steps, could t instead of putting commits a, B, c into the temporary area, it wocould put commits E, F G into the temporary area.

 

Example of a complete development branch rebase: Create a rebase branch, and combine multiple commit of the Development Branch into one commit to hit the rebase branch. If you need review code, you also need to generate a diff file.

Assume that the development branch code is based on the m_old node of the master.

1. switch to the master branch, reset to the m_old node, create and switch to the branch rebasecode. (the purpose of creating this branch is to hit multiple commit of the previous Development Branch to the rebasecode at a time to avoid rebase operations)

2. Git diff rebasecode> 1. Diff

3. Patch-P1 <1. Diff

4. Git commit (after hitting 1. diff, it will only be reflected in the workspace. The GIT rebase master merge targets all commit objects, so it must be submitted)

5. Switch to master and pull the latest code

6. Switch to rebasecode and execute git rebase master

7. Resolve Conflict (if git branch is executed during rebase, no branch is displayed. If git rebase -- abort or rebase is completed, git branch is displayed as rebasecode)

Git add-u

Git rebase continue

8. Git diff master rebasecode> 2. Diff (this file is the diff used for codereview)

9. the review modification can be submitted directly on the rebasecode instead of the initial development branch code. If the code is submitted, git diff v_old v_now can also generate a diff file and patch it to the rebasecode.

10. After review is complete, git rebase master again, git diff master rebasecode> complete. Diff

11. If it is submitted on SVN, you can directly patch-P0 <complete. Diff

 

Git diff and anti-patch

You may often submit and push to a remote branch by mistake. In this case, you can solve the problem in three ways:

1. Create a new branch (it is best to keep the old Branch)

2. Reset the remote branch to the previous version.

3. for example, if the status quo is V1 ----- V2 and the node submitted by mistake is V2, use git diff V2 V1> rpatch. diff, and then use pathch-P1 <rpatch. diff clear error submission. The result is that the status of V1 ----- V2 ----- V3. V3 should be consistent with that of V1.

 

 

 

 

Git config:

The command for editing the git ini file. Compared with vim, git config can be executed in any directory of the GIT project.

The git ini file is divided into version library-level configuration (. Git/config)> global configuration (. gitconfig)> system-level configuration file (/etc)
Maven's settings. xml also has a similar overwrite policy.
Example 1:
Git config -- unset usage: Used to reset the key-value in git/config.
For example, git config -- unset remote. Origin. url root@172.16.10.220:/home/git. Gold/daodao-site
Git config -- unset remote. Origin. URL will be deleted directly.
If you want to delete all content under the node [remote "Origin. Git config -- unset remote. Origin is incorrect. to delete a node, use git config -- remove-section remote. Origin.
Example 2: usually set user. Name User. Email to global and delete user. Name:
Git config -- unset -- global user. Name

View and add a remote Repository:
Git remote-V view remote repository git remote add of local configuration

When to delete a branch: The branch code is checkin by merge or the patch of the Branch
1. delete a local branch
Git branch-D Branch
2. Delete the remote branch. Note the preceding space.
Git push remote: Branch

Why cannot the previous environment be restored after git reset head -- hard:

Because git reset head -- hard only restores files that have been tracked by git. However, the patch contains new files that have not been tracked by git.

Solution:
1. Create a New Rm-RF file and then apply a patch. Otherwise, the new file will block the patch.
2. Git clean-DXF is actually executing the RM command, but this command will delete all untrack files in the workspace, and some eclipse projects will be affected after execution.
Example:
Ygao @ pts/ttys000 $ git status
# On branch master
# Changes to be committed:
.......
# Changes not staged for commit:
......
# Untracked files:
# Test11

Ygao @ pts/ttys000 $ git clean-DXF
Removing test11

Ygao @ pts/ttys000 $ git status
# On branch master
# Changes to be committed:
......
# Changes not staged for commit:
......

Conflicting scenarios:
1. patch installation may conflict. The linux patch command is the same, and merge may conflict.
2. rebase different branch conflicts

2.1 rebase conflict content format Analysis
During the rebase process, the <part should be the code of the workspace after the current patch is completed ==== indicates the Code where the patch old hits the file >>>>
For example, in the following example, the header indicates that rebase first hits the "add batch API" patch, and then the rebase creates a "refactor" patch. The two patches modify the same piece of code, causing a conflict, And the add batch API indicates the code of the previous patch. The processing sequence is to delete the code of the old patch.

<Head return 0 ;====== if (o1.getlocationid () = o2.getlocationid ()) {return 0 ;}>>>>>>> add batch API merging result: Return 0;

 

2.2 After rebase, check whether it is correct, otherwise git checkout -- conflict = merge file will be resolved again.

 

3. complex conflict resolution process:

<Head dblocationelement ele = dblocationstore. getinstance (). getlocationelement (locid); While (Ele! = NULL &&! Ele. isgeographic () {ele = ELE. getparentlocation () ;}if (Ele = NULL) {return-1 ;}====== dblocationelement ele = dblocationstore. getinstance (). getlocationelement (locid); ====== dblocationelement ele = dblocationstore. getinstance (). getlocationelement (locid); >>>>>> commit revise script while (Ele! = NULL &&! Ele. isgeographic () {ele = ELE. getparentlocation ();} If (Ele = NULL) {return-1 ;} 
 
 

 
Two different conflicts are distinguished because the conflict resolution methods are different.
1. Patch conflicts or merge conflicts. There is no difference between the editing conflicts and the usual modification code. After the modification is complete, add the modification to the cache git add and then git commit.
2. rebase Conflict Resolution:
2.1 After resolving the application conflict of a patch, git add-u is used to add the files that have been tracked to the stage.
2.2 then execute git rebase-continue to directly create another patch.
Repeat 2.1, 2.2 Until rebase is complete. Note that the rebase does not need to explicitly execute commit. Commit is automatically completed by git.
3. You can use git diff to view conflicts. Git diff has different meanings in different scenarios.
Git pull:
It is equivalent to git fetch + git merge. If git merge is a quick merge, a commit point is formed.
The commit point corresponding to git merge can be referred to using merge-head (fetch-head ).
The commit point corresponding to git push can correspond to head
 
Git Add:
Unlike the traditional SVN, The add operation not only adds a new file to version control, but also needs to add to modify the file content. This means that git add is not like SVN, for the file name, but for the file content.
Use Cases of git stash & git stash POP:
Example:
The master branch is modified and pushed by others, but its local code does not have a commit. In this case, the remote code of pull will prompt that there are uncommitted local modification files.
This is a good use case for git Stash:
1. If there is no conflict between git stash + git pull + git stash pop, it indicates automatic merge. This is useful and you do not need to discard the existing modification through git checkout before git pull.
2. If a conflict is created (by patch manufacturing), the conflict is resolved, but the possibility of occurrence is small. 1 is common.
3. if there is a manufacturing conflict, there is another way: the local code is committed to the head before pull, but not push (or push, because it is in conflict with remote ), when git pull remote code is used as merge, it will conflict with the local code. It is essentially a conflict of merge manufacturing.
Note: git stash pop is similar to the following operations:
1. Generate a diff file based on the old version of the local code.
2. Git reset head -- hard discard modifications to the local workspace.
3. Git pull
4. Try to create a diff conflict.
 
Git blame comparison with GIT log
Git blame is fine-grained. You can view the history of a method or code block in a class or file. Git log is mainly used to view the history of files or classes. Is coarse-grained.
Example: git blame-L 10, 50 test. Java-L is used to specify the start and end ranges of the code block or method to be tracked. The class or file must be specified later.
Git log -- author ygao-P file -- Author can be used to query the submission records of a person.-P is used to display the diff file, and file can specify the file to be tracked.
 
 
Git + SVN mode:Git server can only be pull and cannot be pushed. SVN server performs patch checkin
The master branch detected by git locally cannot be pushed, but can only be pull.
Once pushed, a commit point is formed. When the master branch of the Repository synchronizes the latest code from the svn server, we will find that the head in the warehouse points to the commit object instead of the commit formed by pull during the last synchronization, but a leading commit. At this time, merge is non fast forward. If you perform the merge operation in the case of Non fast forward, there will be two parents and non line history problems.
Non line history is like the traditional SVN commit is a straight line. Git merge usually forms non line history, and git rebase is recommended.