從這篇開始技術(shù)博客之行吧岔留。
先前的項目的版本控制都用的是svn庵佣，各版本之間分界很不明顯，有可能1.0.0版本寫好了準(zhǔn)備發(fā)版婿斥，突然來了新需求劝篷，加了新代碼，而且這個新功能跟之前的代碼有比較嚴(yán)重的耦合民宿，上線前突然又說功能不要了娇妓，先要隱藏，當(dāng)時還是菜鳥活鹰，對版本控制的理解非常淺薄哈恰，所以只能從代碼里清理……過程不想再說，非常痛苦志群。
后來為了避免這種情況着绷，很笨拙的每個版本結(jié)項的時候，都會把整個項目的代碼打包放到svn……如果之前版本的代碼有bug锌云，就把之前那個包打開改荠医，然后覆蓋之前代碼，非常笨拙。
來到新公司接觸到了git彬向，學(xué)習(xí)了一下兼贡，現(xiàn)在覺得git flow這種工作流很科學(xué)，現(xiàn)在簡述一下目前的基本操作娃胆，如果有初學(xué)者遍希，從大概念上理解這種工作流程會在使用起來更得心應(yīng)手。部分內(nèi)容參考或許是介紹Android Studio使用Git最詳細(xì)的文章 - 簡書里烦，在此感謝原作者凿蒜。
git flow
Git flow是廣泛采用的一種工作流程
他的主要特點有兩個：
1.首先，項目存在兩個長期分支
????- 主分支master
? ? - 開發(fā)分支dev
前者用于存放對外發(fā)布的版本胁黑，任何時候在這個分支拿到的篙程，都是穩(wěn)定的分布版；后者用于日常開發(fā)别厘，存放最新的開發(fā)版。
2.其次拥诡，項目存在三種短期分支
? ? - 功能分支（feature branch）
? ? - 補(bǔ)丁分支（hotfix branch）
? ? - 預(yù)發(fā)分支（release branch）
用到我個人項目里來說：
開發(fā)的初始版本就是主分支master触趴，可能就是AS默認(rèn)的項目，或者是從前面同事clone下來的項目代碼渴肉，這個就是最基礎(chǔ)的版本冗懦，可以作為1.0.0版本，然后最重要的東西來了仇祭，那就是記住一句話：
“master分支里的代碼永遠(yuǎn)都不是手寫進(jìn)去的披蕉，永遠(yuǎn)是其他分支merge進(jìn)來的”
merge這個功能，簡單說來就是你在廣場拼零件乌奇，拼好了最后全部懟到車間里没讲，而master分支就是那個車間，master分支的產(chǎn)出永遠(yuǎn)都是成品礁苗。
剩余的dev分支爬凑，就是自己開辟的廣場了，你可以在在上面拼你想要的東西
留個坑试伙，明天來填嘁信。
20190819填坑…………
經(jīng)過了學(xué)習(xí)和驗證，現(xiàn)在終于有資格來填坑了疏叨。
首先必須要明白一個git的基準(zhǔn)點潘靖，即，
“每個提交其實都是一個引用”
會有一個隨機(jī)分配的hash碼蚤蔓，對應(yīng)這次提交的代碼"改動”卦溢，也就是說每次的分支切換，只是記錄了引用之間的聯(lián)系和區(qū)別。比如從branch1 切換到branch2既绕，整個代碼完全沒有任何變化或者復(fù)制粘貼啄刹，還是原來的代碼，但是此時的HEAD節(jié)點凄贩，指向了一個新的引用誓军，來回切換的話也是切換HEAD節(jié)點。這樣的話怎樣解決文章開頭的難題呢疲扎？
簡單還原一下情景：
首先master上是有代碼的
? ? this is master 1.
? ??this is master 2.
????this is master 3.
這時我們從master new 一個branch 出來叫 develop
現(xiàn)在develop分支上的代碼跟master相同
現(xiàn)在繼續(xù)在develop上開發(fā)昵时，開發(fā)完畢后master沒變，develop分支變成了
????this is master 1.
????this is master 2.
????this is master 3.
????this is develop 1.
????this is develop?2.
開發(fā)到這里椒丧，master版本上線后出現(xiàn)了bug,現(xiàn)在需要修改壹甥，同時希望修改完以后，正在測試中的develop版本也能把這個bug修復(fù)掉壶熏，遇到這種情況句柠，如果在develop分支上改，然后merge進(jìn)master棒假，那develop版本的新功能會被merge進(jìn)去溯职，如果在master上改，就違反了mastere只能從別的分支merge進(jìn)來的規(guī)則帽哑。通過學(xué)習(xí)和驗證谜酒，現(xiàn)在終于有了一個比較簡單兩全的辦法：
切換到master分支，以master分支為基礎(chǔ)new 一個 bug_fix分支妻枕，在bug_fix分支上做出修改僻族，最終bug_fix分支的代碼如下：
????this is master 1.
????this is master 2.
????this is master 3.
????this is bug_fix 1.
????this is?bug_fix?2.
????this is?bug_fix 3.
修改完，進(jìn)行一次commit屡谐，使這次改動獨自占用一個分支和引用述么，然后分別切換到master和develop，把此bug_fix分支merge進(jìn)來愕掏，最終master與bug_fix一致碉输，develop可能會有沖突，經(jīng)過處理后亭珍，develop為
????this is master 1.
????this is master 2.
????this is master 3.
????this is develop 1.
????this is?develop?2.
????this is bug_fix 1.
????this is?bug_fix?2.
????this is?bug_fix 3.
此時把bug_fix分支刪掉即可敷钾。
