Ask yourself a few more whys every day, and you will always get unexpected results. The growth path of a rookie Xiaobai (copyer)
rebase
:rebase
Purpose: to let git的提交记录变得更加的简洁
.
Usage Scenario 1: Simplify Commit Records
Example: The team leader arranges a large functional module for you (such as the shopping cart function), allowing you to develop it independently and giving you five days. Then you will dev
pull a branch from the branch and develop the shopping cart function. You will use it every day git commit
to record your daily workload. Five commits will be generated in five days. When you hand it over to your team leader , these five commits are useless to your team leader, he only needs your last code submission, so you can merge the useless commits.
Simple example:
// 这里就把master想象成开发分支, dev想象开发的购物车的分支
git init
touch master.js
git add .
git commit -m 'master分支上的最初版本'
// 拉取一个开发购物车分支
git checkout -b dev
// 接下来就进行开发
// 第一天
touch dev1.js
git add .
git commit -m '购物车静态页面的实现'
// 第二天
touch dev2.js
git add .
git commit -m '购物车的逻辑实现1'
// 第三天
touch dev3.js
git add .
git commit -m '购物车逻辑实现2'
// 第四天
touch dev4.js
git add .
git commit -m '接口联调'
// 第五条
touch dev5.js
git add .
git commit -m '购物车功能的优化'
//然后这时候,就可以把代码合并到master分支上了
If merged, many of the commit information are useless, so they need to be merged.
git rebase
Basic usage of
git rebase -i [startpoint] [endpoint]
It -i
means that --interactive
an interactive interface pops up to allow the user to edit and complete the merge operation, [startpoint]
[endpoint]
and an editing interval is specified. If not specified [endpoint]
, the end point of the interval is by default HEAD
pointed to by the current branch commit
(note: the interval specifies a front-opening and back-closing interval).
Here, commit hash值
the general interception of the first few letters on the line
git rebase -i 9c9d69bc
or:
git rebase -i HEAD~5 // 向前合并几个,这里需要自己去数
Here, I was a bit miscalculated, hahaha. Here is ** 前开后闭
**, so 9c9d69bc
when selecting and merging, it will not be included 购物车的静态页面的实现
. I found a problem here, and I will pay more attention to it in the future, and hope that I won't make it again in the future.
In the screenshot above, there is a command area :
pick: keep the commit (abbreviation: p)
reword: Keep the commit, but I need to modify the comment of the commit (abbreviation: r)
edit: Keep the commit, but I want to stop and modify the commit (not just the comment) (abbreviation: e)
squash: Merge this commit with the previous commit (abbreviation: s)
fixup: Merge this commit with the previous commit, but I don't want to keep the comment information of the commit (abbreviation: f)
exec: Execute shell commands (abbreviation: x)
drop: I want to discard the commit (abbreviation: d)
The main thing here is to use s
, merge this commit with the previous commit (abbreviation: s).
Modified screenshot:
The department selected in the screenshot above is the default submission information. Here, we can change the submission record to 购物车功能的实现完成
.
git log
The above 1
is the total record of the merger of the first four items.
Precautions:
The submission of the above
2
commit has been pushed to the remote warehouse, it is best not to merge, otherwise it will cause unnecessary trouble
Use Scenario 2: Simplify the main trunk of a branch
In the above notes, I learned the command merge. Merging here will make the main trunk very complicated.
https://blog.csdn.net/James_xyf/article/details/120809220?spm=1001.2014.3001.5501
There is a branch here, and there is a fork, so if there are too many branches, the branches will become complicated, just like a spider's web.
Then rebase
the trunk can be simplified.
The process diagram is still the same.
The picture is a bit ugly, but the general meaning should be clear.
The process begins.
1. First create a folder managed by git
git init
2. Create master1.txt
, then add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c1'
3. Create master2.txt
, then add commit
touch master1.txt // 创建一个文件夹
git add .
git commit -m 'master c2'
4. master c2
Create a branch on the basis of dev
and then create a file dev1.txt
add commit
git branch dev
git checkout dev
// 等价于
git checkout -b dev
touch dev1.txt
git add .
git commit -m 'dev c1'
5. Switch back to the master branch, continue to create master3.txt
, and then add commit
git checkout master
touch master3.txt
git add .
git commit -m 'master c3'
6. Switch to dev, rebase on the dev branch, and merge the master branch
git checkout dev
git rebase master
7. Then switch to the master branch, merge to merge the dev branch
git checkout master
git merge dev
git log --graph --pretty=format:"%h $s"
In this way, the trunk is a straight line.
The difference with merge:
merge
When merging, a new commit record will be generated
rebase
No new commit will be generated
git rebase produces conflicts
In rebase
the process, a conflict may arise. In this case, Git will stop rebase
and let you resolve the conflict; after resolving the conflict, use the "git-add" command to update the index (index ), then you don’t need to execute git-commit, just execute:
$ git rebase --continue
This way git will continue to apply (apply) the remaining patches.
At any time, you can --abort
terminate the rebase action with an argument, and the "dev" branch will return to the state it was in before the rebase started.
$ git rebase --abort
Summarize
The purpose of git rebase is to optimize
// 合并commit提交记录
git rebase -i [startpoint] [endpoint]
// 合并分支
git rebase master