git日常開發常用命令彙總
git常用命令
目錄前言
概述git的基本使用方法
使用git管理專案的方式
主分支支援分支
總結圖總結
記得剛工作的時候根本不知道什麼是版本管理工具，有一次和別人聊天，人家問你們公司**用什麼版本管理工具？我說啥是版本管理工具，我們一般用u盤拷貝，然後人家就顧左右而言他了。後來我知道了有個東西叫svn,後來又知道了還有個東西叫git。所以說剛畢業的同學一定要優先進入專業的大公司，就像年輕時候應該去大城市闖兩年一樣，眼界以及你遇到的牛人會大大加快你以後成功的程序。
本文主要是介紹一種在具體實踐中使用git來管理專案開發的一種成功的方式，其實主要思想**於這篇文章 a successful git branching model，網上大部分教程都是致敬這篇文章。
關於git的基本教程，強烈建議閱讀廖雪峰老師的git教程，對初學者非常友好。
在實際開發中如何使用git沒有乙個標準答案，使用方式也是各式各樣，很多基本上都是把git當svn來用。下面介紹的是一種經過實踐的執行比較良好的管理方式。
實際開發中，乙個倉庫（通常只放乙個專案）主要存在兩條主分支：master與develop分支。這個兩個分支的生命週期是整個專案週期。就是說，自建立出來就不會刪除，會隨著專案的不斷開發不斷的往裡面新增**。master分支是建立git倉庫時自動生成的，隨即我們就會從master分支建立develop分支，如下圖所示。
例如王二狗向master分支合併了**，那就意味著王二狗完成了此專案的乙個待發布的版本，專案經理可以認為，此專案已經準備好發布新版本了。所以master分支不是隨隨便便就可以簽入**的地方，只有計畫發布的版本功能在develop分支上全部完成，而且測試沒有問題了才會合併到master上。
例如王二狗要開發乙個註冊功能，那麼他就會從develop分支上建立乙個feature分支 fb-register（後面講），在fb-register分支上將註冊功能完成後，將**合併到develop分支上。這個fb-register就完成了它的使命，可以刪除了。專案經理看王二狗效率很高啊，於是：「二狗你順帶把登入功能也做了吧」。二狗心中暗暗罵道：日了個狗的，但是任務還的正常做，二狗就會重複上面的步驟：從develop分支上新建立乙個名為fb-login的分支，喝杯咖啡繼續開發，1個小時後登入功能寫好了，二狗又會將這個分支的**合併回develop分支後將其刪除。
通過以上分析可以發現，我們可以使用git hook 指令碼自動發布發布新的版本，具體就是每當有**從develop分支合併到master分支的時候，指令碼就會自動觸發，編譯發布新的版本。
這些分支都是為了程式設計師協同開發，以及應對專案的各種需求而存在的。這些分支都是為了解決某乙個具體的問題而設立，當這個問題解決後，**會合併回主分支develop或者master後刪除，一般我們會人為分出三種分支。
必須從develop分支建立，完成後合併回develop分支
如下圖所示。
具體事例可以參考上面王二狗完成登入註冊功能時的做法。
從develop分支建立，完成後合併回develop與master分支。
這個分支上可以做一些非常小的bug修復，當然，你也可以禁止在這個分支做任何bug的修復工作，而只做版本發布的相關操作，例如設定版本號等操作，那樣的話那些發現的小bug就必須放到下乙個版本修復了。如果在這個分支上發現了大bug，那麼也絕對不能在這個分支上改，需要featrue分支上改，走正常的流程。
例項：王二狗開發完了登入註冊功能後決定發乙個版本v0.1，那麼他先從develop分支上建立乙個release 分支release-v0.1，然後二狗在這個分支上把版本號等做了修改。正準備編譯發布了，專案經理說：「二狗啊，你那個登入框好像向右偏移量1個畫素，你可以調一下嗎？」二狗心中有暗暗罵道：日了個狗，但是。。。你們懂得，功能還的正常改。不過二狗發現這個bug特別小，對專案其他部分不造成不可預知的問題，所以直接在release分支上改了，然後愉快的發布了版本1.0.版本上線後，二狗將這個分支分別合併回了develop與master分支，然後刪除了這個分支。
必須從master分支建立，完成後合併回develop與master分支。
如下圖所示：
這個分支主要是解決線上版本的緊急bug修復的，例如突然版本v0.1上有乙個致命bug，必須修復。那麼我們就可以從master 分支上發布這個版本那個時間點 例如 tag v0.1（一般**發布後會及時在master上打tag），來建立乙個 hotfix-v0.1.1的分支，然後在這個分支上改bug，然後發布新的版本。最後將**合併回develop與master分支。
上面的講解最後匯成一張圖
希望廣大程式設計師不要有王二狗的悲慘遭遇，最後希望廣大「王二狗媳婦」可以理解廣大「王二狗」的苦衷。
參考文章：a successful git branching model
git專案版本管理
今天閒來無事 其實是不想動 就打算將最近學習的東西以基本專案案例的形式記錄實踐下來，但是，又不想簡簡單單寫個工程，所以打算自己還是像正規專案那樣，能有個版本控制工具，由於以前的專案都是用的svn，所以，這次我打算換一換，嘗試用現在主流的git作為專案版本管理工具。在想要放專案的資料夾 當前的整個路徑...
用GIT管理專案版本
建立乙個遠端git伺服器，伺服器內為每個專案建立單獨的倉庫。各個客戶端完成開發工作後，預設把自己的master合併遠端倉庫的master.遠端倉庫初始化 git bare init 遠端倉庫一定要初始化為裸倉庫，原因是，這樣做，每次任何人提交 後，其他人可以看到。非裸倉庫，如果遠端倉庫當時的work...
版本管理 Git
4.一直回車，直到生成公鑰私鑰。預設位址c users linxz.ssh 5.在github上的選擇setting ssh and gpg keys,新增新的ssh key new ssh key tittle隨便寫，key是在c users lianjiu.ssh中id rsa.pub 公鑰 6...