Learning git (seven): the use of git rebase

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 devpull a branch from the branch and develop the shopping cart function. You will use it every day git committo 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 rebaseBasic usage of

  git rebase -i  [startpoint]  [endpoint]

It -imeans that --interactivean 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 HEADpointed to by the current branch commit(note: the interval specifies a front-opening and back-closing interval).

insert image description here

Here, commit hash值the general interception of the first few letters on the line

git rebase -i 9c9d69bc

or:

git rebase -i HEAD~5    // 向前合并几个,这里需要自己去数

insert image description here

Here, I was a bit miscalculated, hahaha. Here is ** 前开后闭**, so 9c9d69bcwhen 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:

insert image description here

insert image description here

The department selected in the screenshot above is the default submission information. Here, we can change the submission record to 购物车功能的实现完成.

git log

insert image description here

The above 1is the total record of the merger of the first four items.

Precautions:

The submission of the above 2commit 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

insert image description here

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 rebasethe trunk can be simplified.

insert image description here

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 c2Create a branch on the basis of devand then create a file dev1.txtadd 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"

insert image description here

In this way, the trunk is a straight line.

The difference with merge:

mergeWhen merging, a new commit record will be generated

rebaseNo new commit will be generated

git rebase produces conflicts

In rebasethe process, a conflict may arise. In this case, Git will stop rebaseand 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 --abortterminate 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  

Guess you like

Origin blog.csdn.net/James_xyf/article/details/120813112