git與svn不同,git是分布式版本控制工具,有本地倉庫以及遠端倉庫之分
本地倉庫閉環分析:
首先我們要初始化乙個git的本地倉庫,一般來說我們可以直接在乙個資料夾下 git init 便可以得到我們的本地倉庫
而工作區就是我們要使用git進行管理的**區域,
當我們在工作區進行了**的修改之後,就可以通過 git add 來先將我們的**新增到快取區,然後再commit到本地倉庫
當然我們也可以將本地倉庫的**檢出(check out)到我們的工作區,這樣就形成了乙個本地倉庫所在的閉環
整個流程
當我們的**提交到了本地倉庫之後,由於是分布式開發,我們需要與其他人進行**的分工協作,所以我們需要將**
在遠端倉庫中進行協作,即共享到遠端倉庫
此時我們就需要執行 push 將**推送到遠端倉庫.當我們需要與遠端倉庫保持一致的時候,需要pull(這個過程相當於
fetch獲取 與 merge合併)
而當我們作為新加入專案的人時候,我們第一次從遠端倉庫獲取**的時候,可以直接執行git clone ,這就是遠端倉庫
與本地的閉環
在每次準備寫**的時候,要首先進行git pull(這個過程是 fetch and merge 的過程)
把專案從遠端倉庫中拉取到本地的工作區,再進行編碼,在push的時候再進行一次pull,進行衝突的解決.
這樣會一定程度的減少提交之後對**的衝突
在網上看到乙個問答,覺得很有道理,就記錄下來了
git支援很多種工作流程，我們採用可以是這樣，
遠端建立乙個主分支，本地每人建立乙個功能的分支，流程如下：
每個人在自己的工作分支
$ git checkout self
編碼提交工作分支的修改
$ git commit -a
回到主分支
$ git checkout master
獲取遠端最新的修改，此時不會產生衝突
$ git pull
回到工作分支
$ git checkout work
用rebase合併主幹的修改，如果有衝突在此時解決
$ git rebase master
回到主分支
$ git checkout master
合併工作分支的修改，此時不會產生衝突。
$ git merge work
提交到遠端主幹
$ git push
這樣做的好處是，遠端主幹上的歷史永遠是線性的。每個人在本地分支解決衝突，不會在主幹上產生衝突。
Git協作流程
協作必須有乙個規範的流程，讓大家有效地合作，使得專案井井有條地發展下去。協作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文的三種協作流程，有乙個共同點 都採用 功能驅動式開發 feature drive...
git使用流程
說一下使用git做版本控制的時候的工作流程 1 2 3 4 git add a 需要新增到版本庫中的檔案 a 就代表著所有檔案 除開了 gitignore忽略掉的檔案 git commit m 本次提交的備註 git pull 將遠端的庫和本地的庫版本同步一下,因為遠端庫可能發生了修改 多人合作開發...
git 使用流程
去自己的工作分支 git checkout work 工作.提交工作分支的修改 git commit a 回到主分支 git checkout master 獲取遠端最新的修改，此時不會產生衝突 git pull 回到工作分支 git checkout work 用rebase合併主幹的修改，如果有...