-
1 # 天使之光導師
-
2 # 酷冰資訊分享
也倒不一定會有問題。但是並不建議這樣使用git merge，因為很容易產生分叉和新的commit
雖然這樣操作非常簡單就能合併程式碼，但是專案中都是合作開發，如果大家都這麼操作，那麼最後遠端主分支記錄結果就會變成
再看看使用git rebase和git merge的對比圖
但是並不是說不能使用git merge，而是需要了解了二者的區別以及適用場景採用合適的方式。
推薦一個玩遊戲學git的網站，非常有趣，玩完相信你會有一個新的認識。https://learngitbranching.js.org/
-
3 # 美美和沫沫
你們回答的是不是都是從哪抄的 回答驢唇不對馬嘴的。我覺得答案就是沒什麼問題，但是要注意衝突，多拉最新的版本 防止衝突
-
4 # 程式設計師小助手
結論：沒什麼問題，但是失去了分支的意義。
前言git的分支，用來儲存不同的開發進度，比如
master分支，用於線上正式使用；
dev分支用於開發新功能使用；
bug分支用於熱修。
合理地分配分支職能，會給倉庫維護帶來方便。
舉個栗子說空洞的名詞，難以下嚥，不如給個例子，說明起來方便。借用星雲法師一個故事。
東寺僧人和西寺僧人出門，碰見了。
東寺僧人問：你要去哪裡呀？
西寺僧人說：風吹到哪裡，我就去哪裡。
東寺僧人不知道該怎麼接了。
晚上回去，問住持，住持說，你怎麼不說：要是沒有風，你到哪裡呀？
第二天，又遇見。
東寺僧人問：你要去哪裡呀？
西寺僧人說：腳走到哪裡，我就去哪裡。
東寺僧人一愣，又不會接了。
晚上回去，問住持。住持說，你怎麼這麼笨喲，為什麼不問：腳要是不走，你去哪裡呢？
第三天，又遇見。
東寺僧人問：師兄，要去哪裡呀？
西寺僧人說：去買菜。
實際測試上一節扯遠了，並非要說明高深的道理。星雲大師教人開悟。
1 - 建立一個空倉庫
git init倉庫與目錄同在。不做裸倉庫。
2 - 新建文字檔案 poem
$ cat > poem <<eof
> Someday you will cry for me
> Like I cried for you.
> Someday you"ll miss me
> Like I missed you.
> eof
在命令列內輸入一些文字，使用eof作為開始和結束符。
3 - 檢視狀態
git status4 - 提交這個修改
git add poemgit commit -m "[add]:新增一首小詩"5 - 建立新分支
git checkout -b dev6 - dev 做一些修改
echo "add by dev branch" >> poem
7 - 提交修改
git add poemgit commit -m "[feat]:新增dev特性"8 - 合併到master
合併之前，切換到主分支；比較兩個分支差異；執行合併。
git ckeckout mastergit diff --stat devgit merge dev9 - 接下來怎麼辦
dev用完了，還要接著用嗎？當然可以，不過，線上master程式碼執行過程中，發現了一個bug，要熱修，還拉到dev分支上處理嗎？
其實，像這種臨時的任務，拉一個臨時分支，用完刪掉，更為整潔。強迫症必備。
10 - 新建 bug-fix 分支
首先拉取線上分支到本地新分支。
git fetch origin master:bug-fixgit checkout bug-fix11 - 做一些修改然後提交
在bug-fix分支上修改完畢，提交修改；切換到master分支，合併bug-fix的修改，然後提交到線上。
echo "Do more" >> poemgit add poemgit commit -m "[fix-bug]: 更多"git checkout mastergit diff --stat bug-fixgit merge bug-fixgit push origin master充分合並的分支，bug-fix分支完成了使命，我們轉到dev上開發新功能。
git checkout devgit diff --stat bug-fixgit merge bug-fixgit branch --delete bug-fix結語為了讓題主對分支有更為立體的感覺，小助手用了12步，初步解釋了分支的用法。希望可以幫助題主養成分支處理的好習慣，讓程式碼倉庫更為整潔優秀。
Happy coding :-)
回覆列表
https://medium.freecodecamp.org/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785zhicheng Miya
大部分開發者都有遇到過該用 Merge 還是 Rebase 的問題，網路上的各種相關介紹幾乎都認為：“不要使用 Rebase，因為它會產生各種問題”。這裡我將介紹 merge 和 rebase 的概念，為什麼你應該（或者不應該）使用它們，以及怎麼用。
Git Merge 和 Git Rebase 目的相同，它們都是把不同分支的提交合併到一起。雖然最終目的是一致的，但是其過程卻頗為不同。瞭解它們之間的區別之後，你會成為一個更出色的開發者。
Git 社群對這個問題有很大爭論，一些人堅持應該只用 rebase，另外一些人認為只用 merge，事實上兩種方式各有優勢。
Git Merge
對於使用版本控制系統的開發者來說，Merging 是常規操作。不管建立的分支是用來測試、修復 bug，還是別的什麼原因，可能都會需要把分支的提交 merging 到其它的分支上。具體來說，merging 就是把源分支的提交放到目標分支裡面。在這個過程裡，只有目標分支改變，而源分支保持原樣。
Merge Master->Featuer branch
優點
簡單易上手
保留了提交歷史和時間次序
保留了分支的結構
缺點
提交歷史被大量的 merge 提交汙染了
使用 git bisect 除錯變得更困難了
怎樣做
使用 checkout 和 merge 命令把 master 分支 merge 到 feature 分支。
$ git checkout feature
$ git merge master
(or)
$ git merge master feature
這將會在 feature 分支上建立一個新的 “Merge 提交” 用來保留所有分支的記錄。
Git Rebase
Rebase 是合併兩個分支的另一種方式。Rebase 把所有的提交壓縮成一個 “patch”。然後把 patch 新增到目標分支裡。
和 merging 不同，rebasing 清除了歷史，因為它完全是從一個分支轉移到了另一個分支。在這個過程中，多餘的記錄被移除了。
Rebases 的提交從頂部按次序向下排列，而 merges 則自下而上。
Rebase feature branch into master
優點
把複雜的歷史變成優雅的提交線
操作單個提交變得很簡單（比如，reverting）
避免了龐大的倉庫、海量的分支以及煩人的 merge 提交
線性合併清除了中間的無用提交，對於 DevOps 團隊來說是個好訊息
缺點
Rebase 後 feature 分支間的上下文模糊了
在團隊裡 rebasing 公共分支是高風險的事
工作變多了：feature 分支需要經常更新
Rebasing 到遠端分支需要 force push。最大的問題是人們經常已經 force push 了，才發現忘記了設定 git push 預設值。結果本地遠端所有同名的分支都進行了更新，清理起來很要命。
如果你 rebase 出錯並且很不幸重寫了歷史，很棘手，所以一定要明白操作的意義。
怎樣做
下面的命令把 feature 分支 rebase 到 master 分支上。
$ git checkout feature
$ git rebase master
它把整個 feature 分支的提交移動到了 master 分支上。透過給每個源(feature) 分支建立了一個 brand 來 re-writing 專案的歷史。
Interactive Rebasing
這個命令可以在移動 commit 前改變它們。這比普通的 rebase 更加強大，它提供了對分支提交歷史的完整控制。另外，在合併 feature 分支到 master 前，還可以用它來清理混亂的提交歷史。
$ git checkout feature
$ git rebase -i master
他會開啟編輯器列出將要被移動的提交。
pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3
它清晰地展示了分支在 rebase 後的樣子。透過重新調整，提交歷史可以變成任何你想要的樣子。如，可以把 pick 換成 fixup , squash , edit 等命令。
選哪個
所以，哪個是最好的？有沒有專業的建議呢？很難明確告訴你該選哪一個，畢竟每個團隊的情況不同。但還是有章可循。
團隊在制定他們的 Git rebase vs. merge 策略時需要考慮很多問題。事實證明，工作流之間並無明顯的高下之分，一切都取決於團隊情況。
選擇更直白的 rebasing 還是歷史可塑性更強的 merging，要考慮團隊對 rebasing 的瞭解情況以及 Git 熟悉程度。
最後，決定使用 merging 還是 rebasing 還應該考慮到分支策略。團隊有必要制定一個合適的分支策略。
我的建議
隨著團隊增長，透過 merge 策略很難管理和追蹤到每個提交。為了提交歷史更清晰、更易於理解，使用 Rebase 是一個明智、高效的選擇。
下面是針對不同環境的建議，可以最大限度地發揮 Rebase 的優勢：
本地開發：如果你沒有和別人協同工作，你應該使用 rebasing 而不是 merging ，這樣歷史記錄會很清晰。如果你已經從倉庫拉取了你的個人 fork，並且不準備和別的開發者一起工作，在分支 push 前 rebase 也是可以的。
你的程式碼準備好了被 review： 你建立了 pull request。別人正在 review 你的程式碼，可能把它拉到了本地 review。如果這樣，你最好別 rebase 你的程式碼。你應該建立一個 “rework” 提交來更新你的 feature 分支。它會讓 pull request 的可塑性更強，也能避免歷史突然丟失。
review 已經完成並且已經準備好了合併到目標分支。恭喜！你就要刪除你的 feature 分支了。由於別的開發者不需要拉取、合併這些更改，這是你清理記錄的好機會。你可以改寫記錄，摺疊原始提交、“pr rework” 提交和 "merge"提交，使之成為一整個清晰的提交。作為可選，你還可以給這些提交建立一個明確的 merge，這樣做實際上很有用。它會記錄 feature 併入master 的時間。
結論
希望這些解釋能讓你對 Git merge 和 Git rebase 更瞭解。Merge .vs. rebase 策略之爭永無止境。希望這篇文章可以幫助你掃清迷惑，找到一個適合自己的團隊的方向。