柚子快報激活碼778899分享：初識git · 分支管理
柚子快報激活碼778899分享：初識git · 分支管理
目錄
前言：
理解分支
創(chuàng)建 合并 刪除初體驗
合并沖突/模式
前言：
Git分支管理是一種強大的版本控制策略，它允許開發(fā)者在不影響主代碼庫的情況下，進行并行開發(fā)和實驗。以下是Git分支管理的簡單文字介紹：
Git分支是代碼庫中的一條獨立路徑，每個分支都包含了項目的完整歷史記錄和文件。通過創(chuàng)建分支，開發(fā)者可以在不影響主分支（通常稱為main或master）的情況下，進行新功能的開發(fā)或錯誤的修復(fù)。
開發(fā)者通常會在開始一個新功能或修復(fù)時，從主分支創(chuàng)建一個新的特性分支。在這個分支上，他們可以自由地進行開發(fā)、測試和提交更改。一旦特性完成并經(jīng)過測試，它就可以被合并回主分支，從而成為項目的一部分。
除了特性分支外，開發(fā)者還可能使用開發(fā)分支來集成多個特性分支，進行進一步的測試，并最終準(zhǔn)備發(fā)布。開發(fā)分支通常包含了所有即將發(fā)布的功能，但可能還需要進行一些調(diào)整和優(yōu)化。
有時，開發(fā)者可能還需要創(chuàng)建熱修復(fù)分支來處理主分支上的緊急問題。這些分支通常是從主分支直接創(chuàng)建的，并在修復(fù)完成后盡快合并回主分支和開發(fā)分支。
在Git分支管理中，合并分支是一個重要的操作。它允許你將一個分支的更改合并到另一個分支中。在合并之前，Git會自動進行沖突檢測和解決，以確保合并后的代碼是正確和一致的。
那么現(xiàn)在，就進入分支的簡單講解部分。
理解分支
學(xué)習(xí)分支管理之前，我們總得知道什么是分支吧？
我們不妨拿高考舉例子，我們一共有6條學(xué)習(xí)路線，分別學(xué)習(xí)語數(shù)英，物化生，這六條分支學(xué)習(xí)加起來，構(gòu)成了最后高考的我們。
從這個例子，我們可以看出分支管理的強大，即各個分支之間不影響，并且如果一個分支完備了，就變成了我們最后項目的一個部分，這是分支的簡單理解。
創(chuàng)建 合并 刪除初體驗
前文提及，版本庫里面的HEAD指針指向的就是分支，版本回退是通過改變master的指向快速實現(xiàn)的。
而當(dāng)我們第一次創(chuàng)建.git文件的時候，就會默認(rèn)生成master分支：
使用命令cat-file -p可以查看該分支最近一次的commit:
現(xiàn)在先記住這兩個commit id，85e0 7bfe。
首先要創(chuàng)建分支，我們就應(yīng)該查看有哪些分支：
指令git branch就知道目前的分支有哪些，并且*master就是代表目前指向的分支是哪個。
查看之后，我們需要創(chuàng)建分支同樣使用命令git branch [branchname]即可：
此時分支就創(chuàng)建成功了，創(chuàng)建之后，我們?nèi)绾蝿h除該分支呢？使用命令git branch -d即可刪除，但是這里要注意的是不能在當(dāng)前分支刪除當(dāng)前分支，所以我們?nèi)绾芜M行切換呢？
分支切換本質(zhì)就是修改HEAD指針的朝向就可以了，使用命令git checkout dev即可，在上文的撤銷操作上面的git checkout -- [filename]是用來刪除工作區(qū)的內(nèi)容的，這里不用加--,只需要checkout分支就可以了：
此時分支切換成功，同時，我們不妨看看該分支有沒有內(nèi)容：
我們返回最開始打印master分支的時候，出現(xiàn)的兩個git對象也是這個，所以dev分支實際上是基于最近一次commit創(chuàng)建的分支，不然這兩個commit id也不會一樣。
此外，切換之后，我們可以使用git branch查看是否切換成功：
*的改動也就代表了確實修改成功了。
好了，我們目前切換到了dev分支，那么我們在該分支嘗試刪除dev分支，看是否可行呢：
不出意外的報錯了，那么我們就只有切換回去刪除了。
此時，刪除成功了。
那么我們再重新創(chuàng)建一下：
我們再看看git分支狀態(tài)下，對于一個文件的修改所發(fā)生的現(xiàn)象，目前我們在master分支下修改一下file1:
此時切換到dev分支下并查看：
會神奇的發(fā)現(xiàn)沒有我們剛才修改的代碼了，這就是因為沒有合并，此時，我們就需要合并才能讓兩個分支統(tǒng)一了，合并使用的指令是git merge，在master合并就是git merge dev：
那么里面的Fast-forward就是代表快進，因為dev分支是基于最近的一次分支創(chuàng)建的，所以相當(dāng)于直接讓master分支快進到該主線的下一步了。
這是創(chuàng)建 合并 刪除的初體驗。
值得一提的是，如果是沒有add commit，其他分支是能看到該分支修改的文件的（前提是都擁有同一個文件）
合并沖突/模式
首先我們介紹合并沖突，沖突就像，兩個分支修改同一份文件，并且都add commit了，那么比如master分支將文件修改為aaa，dev分支將文件修改為bbb，那么合并的時候，就會沖突，因為git它自己是不知道要保存哪份文件的，所以合并沖突我們都是只能通過自己來解決，那么我們先來看看現(xiàn)象。
對于創(chuàng)建分支來說，我們可以git checkout?-b，即創(chuàng)建新分支的同時將HEAD指針的指向改到為新分支上面去:
我們就現(xiàn)在dev分支下完成對file1的修改并且add commit了：
現(xiàn)在切換分支，然后在master分支下對file1進行修改并add commit：
此時，merge沖突的基本要素已經(jīng)有了，我們merge一下：
也是不出意外的報錯了，那么如何解決合并沖突呢？
我們只需要將沖突的文件手動修改一下就可以了：
此時打開file1是這樣的，<<<到===中間，====到>>>>中間代表的就是沖突的修改，那么我們想要保存哪個就將另一個刪除即可：
此時我們不能直接合并，我們需要將文件add并且commit，git會自動將文件合并的，此時就解決了。?
那么對于合并的具體圖，我們使用log的指令就可以：
git log --graph?--abbrev-commit
git log --graph --abbrev
使用上面的命令就是commit id會變得簡短，下面的更加全面：
此時的圖形化界面就是這樣的。
那么合并之后，dev分支還在合并之前的，master是在合并之后，我們不妨看看：
這是合并沖突。
那么對于合并模式來說，我們前文提到的，F(xiàn)ast-forward模式來說，是快進模式，還存在一種模式是非Fast-forward模式：
先來看現(xiàn)象，第一個紅線，是Fast-forward模式下的merge，而有兩條線的是no-ff下的merge，也就是非快進模式，那么，為什么存在兩種方式呢？
如果是fast模式，提交的時候缺失了一條分支信息，但是這是不利于開發(fā)的，所以存在了非快進模式，可以保證分支信息的完整，即便是我們刪除了dev分支，我們依舊能在提交信息上看到對應(yīng)的分支修改信息。
指令為：
git merge --no--ff -m "xxx" [the other branch]
一般都是推薦非快進模式作為合并模式。
這里簡單引入分支策略。
實際開發(fā)過程中，master分支應(yīng)該是非常穩(wěn)定的，也就是新版本發(fā)布是在上面發(fā)布，而不能在上面進行開發(fā)，所以平常的開發(fā)都是在分支上進行開發(fā)，比如dev分支等：
最上面的是master分支，平常開發(fā)的時候更多的時候就像這樣，如果master分支上面開發(fā)，該軟件或該網(wǎng)站八成都是要崩潰的，畢竟誰開發(fā)沒有bug呢？
那么如果發(fā)現(xiàn)了bug，如何解決呢？是在master主分支上直接解決嗎？當(dāng)然是不可以的，肯定是需要在其他分支上解決，并且合并的，那么用來專門解決bug的分支就叫做bug分支。
比如master分支上出現(xiàn)了bug，但是分支dev的工作區(qū)內(nèi)容并沒有開發(fā)好，所以不能merge，此時就需要將工作區(qū)的內(nèi)容暫時存儲，并且重新創(chuàng)建一個新的分支用于bug修復(fù)，存儲目前工作區(qū)的內(nèi)容是git stash：
對于dev來說，新增的工作區(qū)的內(nèi)容是This is test bug，那么我們需要將該代碼進行臨時存儲：
工作區(qū)的臨時內(nèi)容就已經(jīng)存儲上了。
那么我們需要創(chuàng)建臨時的分支用于解決該bug，但是為什么不直接在dev分支上解決呢？類似于一種備份，我們不能確保在dev上一次性能解決bug，可能改著改著改出來了更多的Bug？創(chuàng)建新分支的意義是確保開發(fā)的安全性。
創(chuàng)建bug修復(fù)分支，應(yīng)該回到master分支上創(chuàng)建，而不是在開發(fā)分支dev上創(chuàng)建:
此時創(chuàng)建好了，我們應(yīng)該打開file1刪除修改對應(yīng)的Bug：
假設(shè)對應(yīng)的Bug是多出來的aaabbbccc那句話，刪除之后，add commit然后no ff合并：
此時合并完成，bug修改成功，我們看看結(jié)構(gòu)圖：
可是現(xiàn)在有一個問題是，dev分支怎么辦？dev里面的bug還沒有修改。
這個我們先別急，我們不是使用了stash命令嗎？我們看看.git：
.git存在了stash，也就是我們存儲的內(nèi)容，我們可以看看存儲了什么：
既然有對應(yīng)的commit id，所以：
這就是存儲的內(nèi)容，那么我們可以通過stash pop放出我們的代碼：
此時就放出來了，但是Bug依舊存在，這里的一個好習(xí)慣是在dev分支下和master分支合并，而不是在master分支上合并dev分支，這肯定是不行的，所以：
但是肯定是合并之后，才放出工作區(qū)的代碼：
放出來之后的情況就是合并沖突的情況，我們合并一下，add就可以了：
那么fix_branch用完了我們刪除了就是。
那么這里的一個小場景是，如果上午開發(fā)了一個功能，在新分支上，突然產(chǎn)品經(jīng)理說不要了，那么此時沒有merge是不能直接刪除的，需要使用git branch -D才能刪除。
對于合并介紹這么多，倘若有錯誤的地方，歡迎指正。
感謝閱讀！
柚子快報激活碼778899分享：初識git · 分支管理
精彩內(nèi)容
本文內(nèi)容根據(jù)網(wǎng)絡(luò)資料整理，出于傳遞更多信息之目的，不代表金鑰匙跨境贊同其觀點和立場。
轉(zhuǎn)載請注明，如有侵權(quán)，聯(lián)系刪除。
Telemart電購網(wǎng)
