Java技術分享
Git是一個免費的開源的分佈式版本控制系統，具有存儲空間小、暫存區域便捷和多個工作流同時工作等特點。Git的功能雖然強大，但如果不按照規範的流程進行操作的話，很容易使得提交歷史混亂，甚至代碼衝突，而git-flow工程流程就是一種規範。
git-flow 並不是要替代 Git，它僅僅是將標準的 Git 命令用腳本組合了起來。
git-flow 特點：
1、擁有2個長期分支
主分支master和開發分支develop。master 只能用來包含穩定產品代碼，你不能直接提交代碼到 master 分支上；develop 是進行任何新的功能開發的基礎分支，功能開發完後，代碼將合併到develop分支，並且等待被整合到 master 分支中。
2、擁有3個短期分支
分別是功能分支（feature branch）、預發佈分支（release branch）和補丁分支（hotfix branch）。feature分支就是當前正在進行的功能點開發的分支；等所有的功能開發完並且合併到develop分支後，需要打一個release分支，表示即將要發佈了；等我們的產品上線後，如果發現有bug，此時需要建一個hotfix分支來進行修復。這幾個分支一旦完成開發，都會被合併進develop或者master分支，然後被刪除。
git-flow 開發流程
1、項目初始化
當在項目的根目錄執行 “git flow init” 命令時，你會看到有master、develop、feature、release、hotfix分支名稱。
2、開始新功能
產品妹子過來了，說我們要接入蘋果支付，OK，新建分支apple-pay，執行命令“git flow feature start apple-pay"。
3、完成新功能
戴上耳機，噼裡啪啦，1個小時候過後功能開發完了，完成該功能，執行命令“git flow feature finish apple-pay”。
4、準備預發佈
測試同學說，功能已經測試完了，沒有問題，準備發佈更新吧，執行命令“git flow release start V1.1.5”，這個地方最好帶上版本號。
5、完成預發佈
在步驟4的基礎上直接執行命令，“git flow release finish V1.1.5”。
6、發現bug
上線一個小時後，用戶反饋充值沒有到賬，立馬新建一個修復分支V1.1.5-fix，“git flow hotfix start V1.1.5-fix”，摘掉耳機，噼裡啪啦，10分鐘後，bug解決，測試驗證通過，完成修復分支，
“git flow hotfix finish V1.1.5-fix”。
至此，一個簡單的git-flow工作流程就結束了，當然如果你有SourceTree的話，操作起來會更加方便，希望我的回答對大家有所幫助。
程序員小石同學
git merge和git rebase的區別, 切記：永遠用rebase
Git無疑現在已經成為最流行的代碼管理工具之一。其中有兩個命令，對很多程序員造成了很多的困惑，一個是merge，一個是rebase。
這些困惑主要糾結於到底應該用merge還是用rebase。
在繼續深入探討之前，我先拋出我的觀點。如果你想擁有一套穩定的，健壯的代碼, 永遠要使用rebase。
不為別的，就為了rebase可以給你提供一套清晰的代碼歷史。
相反的, merge會給你一套亂七八糟的代碼歷史。當你看到這樣的代碼歷史的時候，我相信你絕對沒有心情去研究每一個歷史對應的代碼。
好，接下來我們就詳細分析一下這兩個命令的作用。假設我們的repo有這麼個主branch: master。
每個程序員在創建自己的代碼之前，要首先創建自己的個人分支，然後代碼修改開始。
假如你有6個程序員一起工作， 你就會有6個程序員的分支， 如果你使用merge, 你的代碼歷史樹就會有六個branch跟這個主的branch交織在一起。
那個畫風我相信對你一定很熟悉。想著那個畫風感覺到一切都好無助， 有個詞兒比較合適，叫做欲仙欲死。
這就是merge命令下生成的代碼分支歷史。
那麼rebase又能做到什麼程度呢？Rebase永遠不會導致多個歷史分支進行交織。它永遠都是一條線。純潔而又幹脆。輕輕爽爽的， 從不拖泥帶水。
那為什麼會這樣呢？
先說一下merge。Merge命令會保留所有commit的歷史時間。每個人對代碼的提交是各式各樣的。儘管這些時間對於程序本身並沒有任何意義。但是merge的命令初衷就是為了保留這些時間不被修改。這樣也就形成了以merge時間為基準的網狀歷史結構。每個分支上都會繼續保留各自的代碼記錄, 主分支上只保留merge的歷史記錄。子分支隨時都有可能被刪除。子分子刪除以後，你能夠看到的記錄也就是，merge某branch到某branch上了。這個歷史記錄描述基本上是沒有意義的。
還有一個比較有意思的是你不能，也不應該去修改這個歷史記錄描述。那是因為這個merge記錄裡面，不僅僅包含你自己的代碼，也包含別人的代碼。到這裡你能想象有多亂吧？
再來說一下rebase, 這個命令會始終把你最新的修改放到最前頭。比如你對主branch進行rebase以後, 你的所有修改就會在主branch當前所有的修改之前。你會更有信心保證你的代碼運行暢通無阻。通過你自己的測試以後, 你就可以放心的把代碼合併到主的branch裡面了。
這裡值得一提的是，rebase通常是發生在自己的個人branch上的。它的基礎就是現有的主branch。這樣做的好處就是保證每個人的代碼都可以運行在當前最新的主branch的代碼上。
這裡再提一個比較有意思的現象。在我工作的這麼多公司之中，只有不多的幾家在使用rebase, 有相當數量的公司還在使用merge。經過觀察我發現, 凡是代碼管理混亂的項目， 或者整個項目組的做決定者不太清楚代碼整潔的重要性， 或者腦子有問題的， 他們都在使用merge。哈哈，我開玩笑呢。
不過， 我還是建議大家去親身體驗一下rebase的好處吧。
