遠程操作

創(chuàng)建遠程倉庫

可以看到此時已經創(chuàng)建好了一個遠程倉庫，倉庫下會有兩個默認的README文件，一個是中文版另一個是英文版，是用來介紹你這個倉庫是用來干什么的。

將倉庫設置為開源。

克隆遠程倉庫

HTTPS

??直接使用git clone https://... 將倉庫克隆到本地。

SSH

??SSH協(xié)議使用了公鑰加密和公鑰登錄機制，體現了實用性和安全性，使用此協(xié)議的時候需要將我們的公鑰放在服務器上，由Git服務器進行管理。使用HTTPS協(xié)議沒有要求，直接就能克隆到本地。

直接使用SSH協(xié)議克隆遠程倉庫到本地是不行的。所以要遵循以下步驟：

• 在用戶目錄下創(chuàng)建.ssh目錄(如果存在就不用創(chuàng)建，并且如果有id_rsa 和 id_rsa.pub 兩個文件可以直接跳過下一步，將 id_rsa.pub 中的內容添加到Git服務器上即可)，生成SSH密鑰對。
  ssh-keygen -t rsa -C "git服務器綁定的郵箱"生成密鑰對(一路回車就可以)。
  

• 將公鑰添加到遠程倉庫。
  
  
  此時就能夠成功克隆遠程倉庫到本地
  

??當我們把遠程倉庫克隆到本地后，Git會將遠程倉庫的master分支和本地倉庫的master分支對應起來，遠程倉庫的名稱默認是origin(使用git remote 查看)。

或者使用git remote -v查看更詳細的信息

向遠程倉庫推送

例如：創(chuàng)建一個文件，然后同步到遠程倉庫。

在推送到遠程倉庫之前一定要配置一下本地倉庫的user.name 和 user.email 保持與遠程倉庫一致。

git push <遠程主機名> <本地分?名>:<遠程分?名>
# 如果本地分?名與遠程分?名相同，則可以省略冒號：
git push <遠程主機名> <本地分?名>

拉取遠程倉庫

例如：在遠程倉庫進行一次修改，然后同步到本地倉庫(這是為了實驗，不要在遠程倉庫做修改)。

git pull <遠程主機名> <遠程分?名>:<本地分?名>
# 如果遠程分?是與當前分?合并，則冒號后?的部分可以省略。
git pull <遠程主機名> <遠程分?名>

.gitignore文件

??如果創(chuàng)建倉庫時沒有勾選.gitignore文件，可以自己創(chuàng)建。寫在.gitignore文件中的文件，會被git忽略掉。

例如：忽略掉 .i 和 .o為結尾的文件：

??在工作區(qū)創(chuàng)建以.i和.o為結尾的文件，使用git status查看倉庫的狀態(tài)。

可以看到這兩個文件確實被git忽略掉了，證明.gitignore文件已經生效了。

特殊情況：

• 如果想添加某個文件，但是這個文件已經被忽略掉了，可以使用git add filename -f強制添加
• 你想添加某個以.i結尾的文件，返現該文件被忽略了，你想可能是.gitignore文件內容寫錯了，可以使用git check-ignore -v 進行檢查
  
  顯示在.gitignore文件的第三行，表明了忽略掉以.i為結尾的所有文件
• 想要忽略某一類文件，但是不想忽略掉這一類中的某一個或幾個文件。例如：忽略掉所有以.開頭的文件，但是不想忽略掉.gitignore文件，這樣的情況可以在.gitignore文件中特殊標注。

.* #表示忽略掉所有以.開頭的文件
!.gitignore #表示不忽略.gitignore文件

給git指令起別名

git config [--global] alias.別名 原本名稱

??例如，給status起別名為st，這樣以后查看倉庫狀態(tài)就可以使用git st了。

Issues

該功能作用就是，當某個人發(fā)現代碼存在bug時，可以創(chuàng)建一個Issues來告訴倉庫的人員代碼存在bug，讓他們進行修復。

對于倉庫人員，修復完問題后可以將此Issues的狀態(tài)進行修改。

Pull Requests

??在實際的開發(fā)中，開發(fā)者都是在dev分支上進行開發(fā)，然后再合并到master分支上的，但是并不是隨意就能合并到master分支上的，要在合并之前給倉庫的管理員提交合并分支的申請，在申請得到同意后才能夠進行合并。這個Pull Requests就是提交申請用的。

標簽管理

操作標簽

??標簽就相當于對某一次commit起一個別名，其作用有：

• 在項目中發(fā)布某個版本的時候，針對最后一次commit起一個v1.0這樣的標簽來標識v1.0版本已經完成，具有里程碑意義。
• 對于commit id來說是比較讓人記住的，tag能很好的解決這個問題，tag更容易被人記住，所以在tag起名字的時候一定要容易記住并且有一定的意義。當我們要回退到某個重要的版本的時候，可以直接通過tag定位到那個版本。

??創(chuàng)建標簽

• git tag v1.0 默認是給最后一次提交打上v1.0的標簽
  
• git tag v0.5 commit id 指定某次提交打一個標簽
  
  
• git tag -a v0.6 -m"" commit id 可以在打標簽的時候寫一些備注信息
  
  這樣是看不到tag的備注信息的。
  git show 標簽名 來查看標簽的詳細信息
  
  ?? 查看有哪些標簽
• git tag
  

??在本地刪除標簽

• git tag -d 標簽名 刪除標簽
  

推送標簽

在遠程倉庫也是有標簽的，所以我們可以將本地倉庫的標簽提交的遠程倉庫中。

??推送標簽

• git push origin v1.0 將此標簽推送到遠程倉庫
  
  
• git push origin --tags 將本地所有標簽推送到遠程倉庫
  
  
• git push origin :v1.0 將本地刪除的v1.0標簽推送的遠程倉庫

	git tag -d v1.0

多人協(xié)作

場景一

兩個開發(fā)人員A和B同時開發(fā)一個文件file.txt，A在文件中寫入aaa的內容，B在文件中寫入bbb的內容，最終推送到遠程的master分支上。
在這里就用Windows端和Linux端替代兩個開發(fā)人員。

??首先，在Windows端先將倉庫克隆到本地。

??將Windows端的開發(fā)人員給予倉庫的提交權限。

??開發(fā)一個新的文件肯定是不能在master分支上進行開發(fā)的，所以要先創(chuàng)建一個dev分支。


??開發(fā)人員A使用git pull拉取倉庫信息。

git branch -r 查看遠程的分支

??開發(fā)人員A在本地創(chuàng)建dev分支，并與遠程的dev分支建立鏈接關系git checkout -b dev origin/dev(建立鏈接關系后可以直接使用git pull 或者 git push 進行分支上數據的拉取與推送)。

git branch -vv查看本地分支與遠程分支的鏈接關系。

??對于開發(fā)者B也要在本地創(chuàng)建dev分支，并且和遠端的dev分支建立鏈接關系。

??開發(fā)人員A在本地開發(fā)file文件，然后push到遠程倉庫。

??開發(fā)人員B也在file文件下開發(fā)，開發(fā)完后推送到遠程的dev分支。

可以看到在開發(fā)人員B提交自己開發(fā)的代碼時候，push會報錯。這是因為此時B人員的本地倉庫中dev分支已經不是最新狀態(tài)了，要先git pull拉取最新的分支信息。

git pull 后提示出現沖突，所以要手動的修改這個沖突。

??開發(fā)人員B解決完沖突后，重新推送。

??在遠程倉庫的dev分支下已經達到了想要的成果。

??最后還要將dev分支合并到master分支上，可以選擇走pull requests，也可以在本地先完成合并再推送到遠端上，最終再刪除dev分支。下面展示讓開發(fā)人員A在本地合并好后在推送到遠程倉庫。

• 在dev分支下git pull拉取最新的dev分支信息。
  
• 切換到master分支，保證master分支處于最新狀態(tài)。
  
• 方式在master分支上合并dev分支出現合并沖突，先在dev分支上合并master分支，出現問題在dev分支上解決。
  
• 再切換到master分支上，合并dev分支。
  
• 將本地master分支最新狀態(tài)推送到遠程倉庫。
  
  
• 刪除dev分支
  

場景二

開發(fā)人員A和B共同開發(fā)一個項目，A負責funcA功能，B負責funcB功能，這個場景中與上個場景不同之處在于針對每個功能都創(chuàng)建一個獨立的分支去完成，不是在一個dev分支下完成開發(fā)的。

??開發(fā)人員A在本地創(chuàng)建一個分支feature-A分支，進行開發(fā)。

由于在推送到遠程倉庫時，遠程倉庫中并沒有feature-A分支，更沒有與本地的feature-A分支建立鏈接關系，所以直接使用git push是不可以的，要使用git push origin feature-A，這樣在遠程倉庫中會自動創(chuàng)建feature-A分支

??開發(fā)人員B也在本地創(chuàng)建一個分支feature-B分支，進行開發(fā)。


??但是B突發(fā)情況，有一些急事要去處理，所以他先將完成的這部分代碼推送到遠程。

??此時B的工作交給A來繼續(xù)開發(fā)，所以A要先pull拉取feature-B分支，然后再繼續(xù)在B的基礎上開發(fā)func2。


在本地創(chuàng)建feature-B分支，并與遠程的feature-B分支建立起鏈接關系。
git branch --set-upstream-to=origin/feature-B feature-B建立鏈接關系。
git pull拉取feature-B分支的最新狀態(tài)。


??在A的幫助下又開發(fā)了三分之一，此時B又回到崗位繼續(xù)開發(fā)了。所以A要將最新的狀態(tài)提交到遠程。

??開發(fā)人員B需要從遠程倉庫拉取feature-B分支的最新狀態(tài)，繼續(xù)開發(fā)，完成后推送到遠程倉庫。



??此時在遠程倉庫的featrue-A分支和feature-B分支已經達到了預想的效果。

??將兩個分支合并到master分支上。

• 在將feature-A分支合并到master分支之前，為了防止合并沖突，先將master分支合并到feature-A分支上，如果出現沖突現在本地解決。然后提交pull requests請求。
  
  
  
  
  
  
  
• 在將feature-B分支合并到master的時候，可能會發(fā)生沖突(如果A和B設計同時開發(fā)統(tǒng)一文件時)，所以與上面做法一致先將master合并到feature-B上，出現沖突后現在本地解決，然后再將feature-B合并到master分支上。
  先將最新的master分支狀態(tài)拉取到本地

將master分支合并到feature-B分支上

將feature-B分支合并到master分支，采用提PR的方式



完成合并后刪除沒用的分支

??解決在遠程倉庫刪除分支后，在本地使用git branch -r還能查看到已經刪除的分支。

使用命令 git remote show origin，可以查看remote地址，遠程分?，還有本地分?與之相對應關系等信息。

git remote prune origin移除已經刪除的分支還能在本地顯示。

開發(fā)模型

??在實際的項目開發(fā)中主要會經歷三個重要的階段：開發(fā)階段 測試階段 運維階段，開發(fā)階段主要涉及項目的規(guī)劃，寫代碼，構建等工作，測試階段主要涉及項目的測試工作，運維階段主要涉及項目的發(fā)布，部署，維護工作。針對不同的階段，都會有與之匹配的工作環(huán)境。

??系統(tǒng)的開發(fā)環(huán)境：

• 開發(fā)環(huán)境：開發(fā)環(huán)境是程序猿們專門用于日常開發(fā)的服務器。為了開發(fā)調試方便，?般打開全部錯誤報告和測試?具，是最基礎的環(huán)境。
• 測試環(huán)境：?個程序在測試環(huán)境工作不正常，那么肯定不能把它發(fā)布到生產機上。該環(huán)境是開發(fā)環(huán)境到生產環(huán)境的過渡環(huán)境。
• 預發(fā)布環(huán)境：該環(huán)境是為避免因測試環(huán)境和線上環(huán)境的差異等帶來的缺陷漏測而設立的?套環(huán)境。其配置等基本和生產環(huán)境?致，目的是能讓我們發(fā)正式環(huán)境時更有把握！所以預發(fā)布環(huán)境是你的產品質量最后?道防線，因為下?步你的項目就要上線了。要注意預發(fā)布環(huán)境服務器不在線上集成服務器范圍之內，為單獨的一些機器。
• 生產環(huán)境：是指正式提供對外服務的線上環(huán)境，例如我們?前在移動端或PC端能訪問到的APP都是?產環(huán)境。

Git分支設計規(guī)范

??一般來說，針對上面不同的環(huán)境來設計不同的分支，例如：

??master分支

• master 為主分?，該分?為只讀且唯?分支。?于部署到正式發(fā)布環(huán)境，?般由合并release 分?得到。
• 主分支作為穩(wěn)定的唯?代碼庫,任何情況下不允許直接在 master 分支上修改代碼。
• 產品的功能全部實現后，最終在master分支對外發(fā)布，另外所有在master分支的推送應該打標簽（tag）做記錄，方便追溯。
• master 分支不可刪除。

??develop分支

• develop 為開發(fā)分支，基于master分?創(chuàng)建的只讀且唯?分支，始終保持最新完成以及 bug 修復后的代碼?？刹渴鸬介_發(fā)環(huán)境對應集群。
• 可根據需求大小程度確定是由 feature 分支合并，還是直接在上?開發(fā)（非常不建議）。

??feature分支

• feature 分?通常為新功能或新特性開發(fā)分支，以 develop 分支為基礎創(chuàng)建 feature 分支。
• 命名以 feature/ 開頭，建議的命名規(guī)則： feature/user_createtime_feature 。
• 新特性或新功能開發(fā)完成后，開發(fā)?員需合到 develop 分?。
• ?旦該需求發(fā)布上線，便將其刪除。

??release分支

• release 為預發(fā)布分?，基于本次上線所有的 feature 分支合并到 develop 分支之后，基于 develop 分?創(chuàng)建?？梢圆渴鸬綔y試或預發(fā)布集群。
• 命名以 release/ 開頭，建議的命名規(guī)則: release/version_publishtime 。
• release 分?主要用于提交給測試?員進行功能測試。發(fā)布提測階段，會以 release 分支代碼為基準進行提測。
• 如果在 release 分支測試出問題，需要回歸驗證 develop 分支看否存在此問題。
• release 分支屬于臨時分支，產品上線后可選刪除。

??hotfix分支

• hotfix 分?為線上 bug 修復分支或叫補丁分支，主要用于對線上的版本進行 bug 修復。當線上出現緊急問題需要馬上修復時，需要基于 master 分支創(chuàng)建 hotfix 分支。
• 命名以 hotfix/ 開頭，建議的命名規(guī)則: hotfix/user_createtime_hotfix。
• 當問題修復完成后，需要合并到 master 分支和 develop 分支并推送遠程。一旦修復上線，便將其刪除。

使用Gitee的DevOps平臺體驗項目開發(fā)流程

??Gitee企業(yè)版免費版

要使用上面的那種分支模型，選擇生產/開發(fā)分支其他的分支后續(xù)創(chuàng)建即可，因為如果選擇了開發(fā)/發(fā)布/缺陷分離模型的話默認提供了feature等分支，但是通常來說是需要多個feature分支的，如果采用這種模型的話是不能再去創(chuàng)建feature分支的，所以選擇生產/開發(fā)模型即可。

??為企業(yè)添加人員


??在項目和倉庫中添加人員。

??模擬開發(fā)流程。

在file文件下進行開發(fā)，增加一個需求。
首先，要從develop分支的基礎上創(chuàng)建處一個feature分支，完成需求后將feature分支合并到develop分支，刪除feature分支。
在develop分支的基礎上創(chuàng)建一個release分支，測試人員在此分支上進行測試工作。
測試完畢后將release分支合并到master分支進行上線。文章來源地址http://www.zghlxwxcb.cn/news/detail-735235.html

• 創(chuàng)建feature分支完成需求的開發(fā)
  
  
  
  
• 將feature分支合并到develop分支。
  
  
  
• 將develop分支合并到release分支(與上面操作一致)。
• 將release分支合并到master分支。
  
  
  如果線上出現問題，可能還需要hotfix分支，在hotfix分支上解決問題后，要將hotfix分支合并到master分支和develop分支上。
在合并完分支后要及時清理那些已經沒用的分支。

到了這里，關于git教程(2)---遠程倉庫操作的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！