Git Part 4 : conflict rebase - innowantai/Note GitHub Wiki
Part 4 : Git rebase
Git merge
目的為將分支上已開發完成之程式合併於master上
- 實際開發情況時有著
分支
需要較長時間才可開發完成但其間主分支
又持續更新,為了讓分支
中的程式碼能夠與主分支
上同步,希望兩者基礎程式架構能夠同步,因此必須定時將主分支
的修改合併到正在開發的分支
上
- 使用
Git merge
將主分支
最新結果push至分支上
也不算錯,但隨著專案進行下去會形成複雜的網狀結構
Git rebase
目的為將主分支
之修改合併至分支上
,但其中要注意的是合併後,分支
的過去紀錄會消失
使用merge將主分支
push至分支

使用rebase將分支
rebase on 主分支上
且分支
舊紀錄已消失

The logs with change in master branch
* 1021d0b (HEAD -> master) Change in master
* 842d17c Add 2 in 2.py
* deb3a5a add 1 in 1.py
The logs with change in dev branch
* af4b7f2 (HEAD -> dev) Change in dev
* 842d17c Add 2 in 2.py
* deb3a5a add 1 in 1.py
Run "git rebase master" on the branch of dev that will occur the conflict
First, rewinding head to replay your work on top of it...
Applying: Change in dev
Using index info to reconstruct a base tree...
M 1.py
Falling back to patching base and 3-way merge...
Auto-merging 1.py
CONFLICT (content): Merge conflict in 1.py
error: Failed to merge in the changes.
Patch failed at 0001 Change in dev
Use 'git am --show-current-patch' to see the failed patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
If want get back to the state before "git rebase", run "git rebase --abort"
Run "git add ." and "git branch" will see that at third unknow branch neither dev nor master
* (no branch, rebasing dev)
dev
master
Run "git rebase --continue" after "git add ." when resolve all conflicts manually
$ git rebase --continue
Applying: Change in dev
The logs in master branch after rebase
* 1021d0b (HEAD -> master) Change in master
* 842d17c Add 2 in 2.py
* deb3a5a add 1 in 1.py
The logs in dev branch after rebase
* 2db6f7d (HEAD -> dev) Change in dev
* 1021d0b (master) Change in master
* 842d17c Add 2 in 2.py
* deb3a5a add 1 in 1.py
2018-06-29