Git版本控制與工做流

時間 2019-11-19

標籤 git 版本控制欄目 Git 简体版

原文原文鏈接

這篇文章是針對git版本控制和工做流的總結，若是有些朋友以前還沒使用過git，對git的基本概念和命令不是很熟悉，能夠從如下基本教程入手：html

基本概念

Git是什麼？

Git是分佈式版本控制系統，與SVN相似的集中化版本控制系統相比，集中化版本控制系統雖然可以令多個團隊成員一塊兒協做開發，但有時若是中央服務器宕機的話，誰也沒法在宕機期間提交更新和協同開發。甚至有時，中央服務器磁盤故障，恰巧又沒有作備份或備份沒及時，那就可能有丟失數據的風險。git

但Git是分佈式的版本控制系統，客戶端不僅是提取最新版本的快照，並且將整個代碼倉庫鏡像複製下來。若是任何協同工做用的服務器發生故障了，也可以用任何一個代碼倉庫來恢復。並且在協做服務器宕機期間，你也能夠提交代碼到本地倉庫，當協做服務器正常工做後，你再將本地倉庫同步到遠程倉庫。github

爲何要使用Git

可以對文件版本控制和多人協做開發
擁有強大的分支特性，因此可以靈活地以不一樣的工做流協同開發
分佈式版本控制系統，即便協做服務器宕機，也能繼續提交代碼或文件到本地倉庫，當協做服務器恢復正常工做時，再將本地倉庫同步到遠程倉庫。
當團隊中某個成員完成某個功能時，經過pull request操做來通知其餘團隊成員，其餘團隊成員可以review code後再合併代碼。

Git有哪些特性

文件三種狀態(modified, staged, committed)
直接記錄快照，而非差別比較
多數操做僅添加操做
近乎全部操做都是本地執行
時刻保持數據完整性

有關以上特性的詳細解釋，請查看Pro git的git基礎章節服務器

Git基本工做流程

在git版本控制的目錄下修改某個文件
使用git add命令對修改後的文件快照，保存到暫存區域
使用git commit命令提交更新，將保存在暫存區域的文件快照永久轉儲到 Git 目錄中

Git基本技巧

自動補全
Git 命令別名

關於具體如何使用自動補全和命名別名技巧，請查看Pro git的技巧和竅門分佈式

Git版本控制

建立倉庫

git init
git clone
git config

保存修改

git add
git commit

查看倉庫

git status
git log –oneline

撤銷修改

查看以前的commit

git checkout <commit> <file>
git checkout <commit>
git checkout <branch>

撤銷公共修改

git revert <commit>

撤銷本地修改

git reset
git clean

重寫Git歷史記錄

git commit –amend
git rebase
git reflog

Git協做開發

分支

git branch
git checkout
git merge

倉庫同步

git remote
git fetch
git pull
git push

Git工做流

因爲git擁有強大的分支特性，它的工做流比較靈活而缺少約束，因而參考Atlassian Git Tutorial的Comparing Workflows章節提供四種Git工做流：ide

Centralized Workflow
Feature Branch Workflow
Gitflow Workflow
Forking Workflow

以上工做流只是參考指南，而不是具體規則。你能夠根據本身實際狀況來選擇適合本身的工做流或微調來知足本身的須要。學習

Centralized Workflow

過渡到分佈式版本控制系統看起來像一個艱鉅的任務，但若是你充分利用好git的話，你沒必要改變你既有的工做流，你的團隊能夠採用與以前使用SVN同樣的方式來開發項目。測試

如何工做

Centralized Workflowfetch

從遠程倉庫(central repository)克隆工程到本地倉庫(local repository) — git clone
在本地倉庫編輯文件和提交更新 — git add和git commit
fetch遠程倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面 —git fetch和git rebase 或 git pull --rebase
push本地主分支(master branch)到遠程倉庫 — git push

管理衝突

File Conflictsui

什麼時候發生衝突：在開發者發佈它們功能以前，他們須要fetch遠程倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面。有時，本地提交與遠程提交會發生衝突，git會暫停rebase過程來讓你手動解決衝突。
如何解決衝突：你可使用git status和git add來手動解決合併時衝突。

Feature Branch Workflow

Feature Branch Workflow的主要思想就是在開發每一個功能時都應該建立一個獨立的分支而不僅是使用主分支。因爲每一個分支是獨立且互不影響，這就意味着主分支不會包含broken code，對持續集成環境是頗有幫助的。

如何工做

Feature Branch Workflow

仍然使用遠程倉庫(central repository)和主分支(master branch)仍記錄官方工程的歷史
開發者每次開發新功能時都建立一個新分支 — git checkout -b
Feature branches應該推送到遠程倉庫(central repository) — git push
發送pull request來請求管理員可否合併到主分支(master branch)
發佈新功能到遠程倉庫(central repository)

Pull Request

Pull request是一種當開發者完成一個新功能後向其餘團隊成員發送通知的機制。它的使用過程以下：

開發者能夠經過Github或Bitbucket發送pull request

Pull request on Github

其餘的團隊成員審查、討論和修改代碼
項目維護者合併新增功能分支到主分支(master branch)，而後關閉pull request

Gitflow Workflow

Feature Branch Workflow是一種很是靈活的開發方式。對於一些規模比較大的團隊，最好就是給特定的分支賦予不一樣的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨立的分支來準備發佈(preparing)，維護(maintaining), 和記錄版本(recording releases)。下面我會逐個介紹這個幾個分支：Historical Branches、Feature Branches、Release Branches和Maintenance Branches。

Historical Branches

master分支保存官方發佈歷史
develop分支衍生出各個feature分支

Feature Branches

feature分支使用develop分支做爲它們的父類分支
當其中一個feature分支完成後，它會合並會develop分支
feature分支應該從不與master分支直接交互

Release Branches

release分支主要用來清理釋放、測試和更新文檔
一旦develop分支得到足夠的功能來發布時，你能夠從develop衍生出一個release分支
一旦準備好上架，release合併到master分支而且標記一個版本號
另外，還須要合併回develop分支

Maintenance Branches

Maintenance Branches.png

maintenance分支用來快速給已發佈產品修復bug或微調功能
它從master分支直接衍生出來
一旦完成修復bug，它應該合併回master分支和develop分支
master應該被標記一個新的版本號

標記Tags

使用兩個命令來給master分支標記版本號：

git tag -a 0.1 -m "Initial public release" master
git push origin master --tags

Forking Workflow

Forking Workflow與以上討論的工做流很不一樣，一個很重要的區別就是它不僅是多個開發共享一個遠程倉庫(central repository)，而是每一個開發者都擁有一個獨立的服務端倉庫。也就是說每一個contributor都有兩個倉庫：本地私有的倉庫和遠程共享的倉庫。

Forking Workflow

Forking Workflow這種工做流主要好處就是每一個開發者都擁有本身的遠程倉庫，能夠將提交的commits推送到本身的遠程倉庫，但只有工程維護者纔有權限 push提交的commits到官方的倉庫，其餘開發者在沒有受權的狀況下不能push。Github不少開源項目都是採用Forking Workflow工做流。