Git reflog fixes lost commit codedetached-head
Reflog is a safety net for Git operations, with the ability to log changes to almost any local repository. All branch commits that have been deleted (but not actually deleted) will be recorded. In summary, whenever the HEAD changes, you can see it through reflog.
detached-head
Code loss recovery
- Git submitting to HEAD detached causes code to be lost
- StackOverflow – gitx How do I get my ‘Detached HEAD’ commits back into master
background
In daily development, the wrong operation of switching branch caused the loss of local code modification.
At this point, git reflog can be used to retrieve lost code changes.
Loss of cause and procedure
First developed on the Master branch, there were bugs on the line and the old version of the tag went back. At this point, some code on the Master branch has been modified but not committed.
Git status is executed on the master branch and there is uncommitted code, as shown in the figure below
Execute git tag on the master branch to view the tag information, as shown in the following figure
At this point you have uncommitted code, then execute Git Checkout V1.0
In this case, the hint is that the current branch is a detached HEAD
Git add./git commit and git checkout master. The detached HEAD branch is gone and all the uncommitted code on the master branch is gone.
Code to retrieve
Run git reflog to view the commit record
Find commitId 247e11b for the submission and run the following command to retrieve the missing code
Git checkout 247e11b // checkout the corresponding commit git checkout -b diff // create a new branch git checkout master // switch to the master branch git merge diff // Merge the new diff branch into the master branchCopy the code
Deletes all historical commit records
- How to delete all commit history in github | Stackoverflow
Here’s how to delete all historical commit records to form a brand new repository.
- 1 – Checkout
git checkout --orphan new_branch
Copy the code
- 2 – Add all the files
Git add -a is equivalent to git add --all or git add.Copy the code
Git add uses the -a or –all parameter to track all operations, including additions, modifications, and deletions
With Git 2.0, the -a parameter is the default. Equivalent to git add -a or git add –all
- 3 – Commit the changes
git commit -am "commit message"
Copy the code
- 4 – Delete the branch
Git branch -d master deletes both local and remote branchesCopy the code
- 5 – Rename the current branch to master
git branch -m master
Copy the code
- 6 – force update your repository
git push -f origin master
Copy the code
The above steps are described below
git checkout –orphan
Git checkout –orphan
- Create a new “orphan” based on the current branch
orphan
) “, does not have any commit history, but contains all the content of the current branch - After executing the above command, the workspace (
Workspace
) are considered new in this operation (git statue
Check the status of all filesnew file
, as shown in the figure below)git add .
All files are added to the cache (Index
)
- Strictly speaking, execution
git checkout --orphan <new_branch_name>
After, the creation is not a branch, because at this pointHEAD
None in the reference pointing tocommit
Value. It is not a true branch until it has committed once.
This parameter indicates that an isolated branch is created without any commit history and has no relation to the current branch (check the commit information, it is an isolated point, as shown in the figure below).
In the same way that orphans have no parent information, the created branch does not contain any historical commit information
git commit -am
- Git commit-m differs from git commit-am
git branch -m
rename
git push -f origin master
Git project collaboration – Keep Git information concise
The same branch git pull uses rebase
By default, Git pull uses the Merge behavior. When multiple people collaborate on development, merge commit records are unnecessary, causing confusion in the commit chain.
Git pull –rebase is recommended when updating code in the same branch.
Set dev branch to dev branch
git config branch.dev.rebase true
All git pulls use --rebase
git config --global pull.rebase true
git config --global branch.autoSetupRebase always
Copy the code
Merge branches using merge –no-ff
Usage
Fast-Forward
When the current branch is merged into another branch, if there are no conflicts to resolve, the file pointer is moved directly and no merge commit record is generated. The process existsgit
The file pointer moves quickly, so the process is calledFast-Forward
.--no-ff
(no fast foward
) : Each merge creates a new onecommit
Record. use--no-ff
, can keep the integrity of the original branch’s submission chain, and when the branch is deleted, the submission information still exists.
Based on the above analysis, feature-1 branch (blue) is detected on dev (green) branch, and no submission is made on dev branch
- directly
merge
, the default isFast-Forward
, the submission chains of the two branches will be merged into a straight line, which is not conducive to the later code review and maintenance - use
git merge --no-ff feature-1
Merging the code will generate a new commit, and the two branch commit chains will not overlap, which is conducive to the later code review and maintenance
Merge Default Settings
Git merge uses fast-forward by default. You can change git merge to –no-ff by default.
git config --global merge.commit no
git config --global merge.ff no
Copy the code
In addition, SourceTree can also be set –no-ff in Settings.