欧美一区观看,欧洲福利电影,国产精品二区影院

首頁 > 數碼 > 內容頁

資訊：版本控制工具GIT使用指南

2023-01-04 15:12:55 來源：51CTO博客

前言：git是分布式版本控制系統，由linux創始人親自設計，目前是最廣泛使用的版本控制工具。本文介紹了版本控制系統的發展和GIT歷史，并針對GIT安裝和常用命令給出了試驗。最后還列舉了比較全面的指令供參考。

1.歷史簡介

1.1什么是版本控制

版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。我們對保存著軟件源代碼的文件作版本控制，但實際上，你可以對任何類型的文件進行版本控制。

(資料圖片僅供參考)

如果你是UI或網頁設計師，可能會需要保存某一幅圖片或頁面布局文件的所有修訂版本（這或許是你非?？释麚碛械墓δ埽捎冒姹究刂葡到y（VCS）是個明智的選擇。有了它你就可以將選定的文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，你可以比較文件的變化細節，查出最后是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。使用版本控制系統通常還意味著，就算你亂來一氣把整個項目中的文件改的改刪的刪，你也照樣可以輕松恢復到原先的樣子。但額外增加的工作量卻微乎其微。

1.2本地版本控制系統

許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這么做唯一的好處就是簡單，但是特別容易犯錯。有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。

為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的數據庫來記錄文件的歷次更新差異。

其中最流行的一種叫做RCS?，F今許多計算機系統上都還看得到它的蹤影。RCS的工作原理是在硬盤上保存補丁集（補丁是指文件修訂前后的變化）；通過應用所有的補丁，可以重新計算出各個版本的文件內容。

1.3集中化的版本控制系統

接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？于是，集中化的版本控制系統（Centralized Version Control Systems，簡稱 CVCS）應運而生。這類系統，諸如 CVS、Subversion （即SVN）以及Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。多年以來，這已成為版本控制系統的標準做法。

這種做法帶來了許多好處，特別是相較于老式的本地VCS來說。現在，每個人都可以在一定程度上看到項目中的其他人正在做些什么。而管理員也可以輕松掌控每個開發者的權限，并且管理一個CVCS要遠比在各個客戶端上維護本地數據庫來得輕松容易。

事分兩面，有好有壞。這么做最顯而易見的缺點是中央服務器的單點故障。如果宕機一小時，那么在這一小時內，誰都無法提交更新，也就無法協同工作。如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問你將丟失所有數據——包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。

1.4分布式版本控制系統

?于是，分布式版本控制系統（Distributed Version Control System，簡稱 DVCS）面世了。在這類系統中，像Git、Mercurial、Bazaar以及Darcs 等，客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來，包括完整的歷史記錄。這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。

更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。這樣就可以在同一個項目中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。

1.5 GIT的產生

同生活中的許多偉大事物一樣，Git 誕生于一個極富紛爭大舉創新的年代。

Linux 內核開源項目有著為數眾多的參與者。絕大多數的 Linux 內核維護工作都花在了提交補丁和保存歸檔的繁瑣事務上（1991－2002年間）。到 2002 年，整個項目組開始啟用一個專有的分布式版本控制系統 BitKeeper 來管理和維護代碼。

到了2005 年，開發BitKeeper 的商業公司同Linux內核開源社區的合作關系結束，他們收回了Linux 內核社區免費使用BitKeeper 的權力。這就迫使Linux開源社區（特別是 Linux 的締造者Linus Torvalds）基于使用BitKeeper 時的經驗教訓，開發出自己的版本系統。他們對新的系統制訂了若干目標：

速度簡單的設計對非線性開發模式的強力支持（允許成千上萬個并行開發的分支）完全分布式有能力高效管理類似Linux內核一樣的超大規模項目（速度和數據量）

自誕生于2005年以來，Git日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。它的速度飛快，極其適合管理大項目，有著令人難以置信的非線性分支管理能力。

1.6GIT是什么？

?那么，簡單地說，Git 究竟是怎樣的一個系統呢？請注意接下來的內容非常重要，若你理解了 Git 的思想和基本工作原理，用起來就會知其所以然，游刃有余。在學習 Git 時，請盡量理清你對其它版本管理系統已有的認識，如 CVS、SVN或Perforce，這樣能幫助你使用工具時避免發生混淆。盡管Git用起來與其它的版本控制系統非常相似，但它在對信息的存儲和認知方式上卻有很大差異，理解這些差異將有助于避免使用中的困惑。

1.6.1直接記錄快照，而非差異比較

Git 和其它版本控制系統（包括 SVN和近似工具）的主要差別在于Git對待數據的方式。從概念上來說，其它大部分系統以文件變更列表的方式存儲信息，這類系統（CVS、Subversion、Perforce、Bazaar 等等）將它們存儲的信息看作是一組基本文件和每個文件隨時間逐步累積的差異（它們通常稱作基于差異（delta-based）的版本控制）。如下圖存儲每個文件與初始版本的差異示意圖，其中checkinsOverTime表示入庫時間線。

Git不按照以上方式對待或保存數據。反之，Git更像是把數據看作是對小型文件系統的一系列快照。在Git中，每當你提交更新或保存項目狀態時，它基本上就會對當時的全部文件創建一個快照并保存這個快照的索引。為了效率，如果文件沒有修改，Git不再重新存儲該文件，而是只保留一個鏈接指向之前存儲的文件。 Git對待數據更像是一個快照流。下圖是存儲項目隨時間改變的快照示意圖，其中checkinsOverTime表示入庫時間線。

這是Git與幾乎所有其它版本控制系統的重要區別。因此Git重新考慮了以前每一代版本控制系統延續下來的諸多方面。Git更像是一個小型的文件系統，提供了許多以此為基礎構建的超強工具，而不只是一個簡單的VCS。

1.6.2近乎所有操作都是本地執行

在Git中的絕大多數操作都只需要訪問本地文件和資源，一般不需要來自網絡上其它計算機的信息。如果你習慣于所有操作都有網絡延時開銷的集中式版本控制系統，Git在這方面會讓你感到速度之神賜給了Git超凡的能量。因為你在本地磁盤上就有項目的完整歷史，所以大部分操作看起來瞬間完成。

舉個例子，要瀏覽項目的歷史，Git不需外連到服務器去獲取歷史，然后再顯示出來——它只需直接從本地數據庫中讀取。你能立即看到項目歷史。如果你想查看當前版本與一個月前的版本之間引入的修改，Git會查找到一個月前的文件做一次本地的差異計算，而不是由遠程服務器處理或從遠程服務器拉回舊版本文件再來本地處理。

這也意味著你在離線或者沒有VPN時，幾乎可以進行任何操作。如你在飛機或火車上想做些工作，就能愉快地提交（這里指提交到你的本地副本），直到有網絡連接時再上傳。如你回家后VPN客戶端不正常，那么也仍能工作。使用其它系統的話，做到這些是不可能或很費力的。比如，用Perforce的話，沒有連接服務器時幾乎不能做什么事；而用SVN和CVS 的話，你能修改文件，但不能向數據庫提交修改（因為你的本地數據庫離線了）。

1.6.3 Git 保證完整性

Git 中所有的數據在存儲前都計算校驗和，然后以校驗和來引用。這意味著不可能在 Git 不知情時更改任何文件內容或目錄內容。這個功能建構在 Git 底層，是構成 Git 哲學不可或缺的部分。若你在傳送過程中丟失信息或損壞文件，Git 就能發現。

Git 用以計算校驗和的機制叫做 SHA-1散列（hash）。這是一個由 40 個十六進制字符（0-9 和 a-f）組成的字符串，基于 Git 中文件的內容或目錄結構計算出來。 SHA-1 哈希散列看起來是這樣： 24b9da6552252987aa493b52f8696cd6d3b00373

Git 中使用這種哈希值的情況很多，你將經?？吹竭@種哈希值。實際上，Git 數據庫中保存的信息都是以文件內容的哈希值來索引，而不是文件名。

1.6.4 Git 一般只添加數據?

你執行的Git 操作，幾乎只往Git 數據庫中添加數據。你很難使用Git 從數據庫中刪除數據，也就是說Git 幾乎不會執行任何可能導致文件不可恢復的操作。同別的VCS 一樣，未提交更新時有可能丟失或弄亂修改的內容。但是一旦你提交快照到Git 中，就難以再丟失數據，特別是如果你定期的推送數據庫到其它倉庫的話。

1.6.5三種狀態

Git 有三種狀態，你的文件可能處于其中之一： 已提交（committed）、已修改（modified）和 已暫存（staged）。

已修改表示修改了文件，但還沒保存到數據庫中。?已暫存表示對一個已修改文件的當前版本做了標記，使之包含在下次提交的快照中。?已提交表示數據已經安全地保存在本地數據庫中。

這會讓我們的Git 項目擁有三個階段：工作區（working directory）、暫存區(staging area)以及倉庫區（.git directory）,下圖是示意圖。

工作區是對項目的某個版本獨立提取出來的內容。這些從Git 倉庫的壓縮數據庫中提取出來的文件，放在磁盤上供你使用或修改。

暫存區是一個文件，保存了下次將要提交的文件列表信息，一般在Git 倉庫目錄中。按照Git 的術語叫做“索引”，不過一般說法還是叫“暫存區”。

倉庫區是Git 用來保存項目的元數據和對象數據庫的地方。這是Git 中最重要的部分，從其它計算機克隆倉庫時，復制的就是這里的數據。

基本的Git 工作流程如下：

在工作區中修改文件。將你想要下次提交的更改選擇性地暫存，這樣只會將更改的部分添加到暫存區。提交更新，找到暫存區的文件，將快照永久性存儲到倉庫區。

如果倉庫區中保存著特定版本的文件，就屬于已提交狀態。如果文件已修改并放入暫存區，就屬于已暫存狀態。如果自上次檢出后，作了修改但還沒有放到暫存區域，就是已修改狀態。

2安裝和配置

2.1服務器安裝配置

（1）下載???https://bitbucket.org/sdorra/scm-manager/downloads/??

獲得源碼sdorra-scm-manager-39150d7e6dfc.zip

解壓到：D:\sdorra-scm-manager-39150d7e6dfc

???https://www.scm-manager.org/download/??

獲得windows安裝文件：scm-server-1.60-app.zip

解壓到：D:\scm-server（2）安裝對于源碼，使用mvn clean install 編譯后使用java –jar 運行。對于安裝文件，使用scm-server.bat install安裝服務，使用net start scm-server啟動服務。默認用戶名和密碼都是scmadmin（3）配置修改%userprofile%\.scm\config\server-config.xml文件：（a）端口改為8000，以免和其他web沖突（b）增加用戶使用http://localhost:8000/進入管理門戶，進入users菜單，點按鈕Add：

2.2客戶端安裝?配置

（1）git安裝下載??https://git-scm.com/???文件：Git-2.18.0-64-bit.exe，安裝到e:\git若只是使用命令行，則這個夠用了，否則需要安裝TortoiseGit。（2）TortoiseGit安裝下載??https://tortoisegit.org/download/???文件：TortoiseGit-2.7.0.0-64bit.msi，安裝到：C:\Program Files\TortoiseGit

3.管理流程最佳實踐

3.1常用操作

下面針對最常使用的操作進行試驗：（1）啟動仿linux外殼執行開始菜單“git bash”，然后進入指定目錄或者先進入指定目錄后，執行右鍵菜單“git bash here”

（2）把目錄添加到本地版本庫?

依次執行：?

git init?

git add .?

git commit -m “new, purpose: starting project”?

（3）在遠程庫上增加倉庫Repository?

添加后找到地址：??http://localhost:8000/scm/git/setting???

（4）新增本地分支并切換過去?

依次執行：?

git branch #查看本地分支?

git branch -r #查看遠程分支?

git branch “setting” #新建本地分支setting?

git checkout “setting” #切換到本地分支setting?

git branch #查看本地分支?

一步到位為的指令：?

Git checkout -b “setting”?

（5）上傳本地倉庫到遠程倉庫?

依次執行：?

git remote add origin ??http://localhost:8000/scm/git/config?? #新增遠程倉庫origin?

git branch -r #查看遠程倉庫?

git push -u origin setting #同步本地倉庫setting到遠程倉庫origin?

重新修改遠程倉庫：?

3.2單主干管理流程

單主干的分支實踐（TBD：Trunk-based development）在 SVN 中比較流行，Git也是適用的。Google 和 Facebook 都使用這種方式。trunk 是 SVN 中主干分支的名稱，對應到 Git 中則是 master 分支。TBD 的特點是所有團隊成員都在單個主干分支上進行開發。當需要發布時，先考慮使用標簽（tag），即 tag 某個 commit 來作為發布的版本。如果僅靠 tag 不能滿足要求，則從主干分支創建發布分支。bug 修復在主干分支中進行，再 cherry-pick 到發布分支。下面是 TBD 中分支流程的示意圖，其中commit表示提交，branch表示分支，cherry-pick表示把指定提交合并到當前分支，release表示發布版本。

由于所有開發人員都在同一個分支上工作，團隊需要合理的分工和充分的溝通來保證不同開發人員的代碼盡可能少的發生沖突。持續集成和自動化測試是必要的，用來及時發現主干分支中的bug。因為主干分支是所有開發人員公用的，一個開發人員引入的bug 可能對其他很多人造成影響。不過好處是由于分支所帶來的額外開銷非常小。開發人員不需要頻繁在不同的分支之間切換。

3.3 GitHub管理流程

GitHub流程是GitHub所使用的一種簡單的流程。該流程只使用兩類分支，并依托于 GitHub 的pull request 功能。在 GitHub flow 中，master 分支中包含穩定的代碼。該分支已經或即將被部署到生產環境。master 分支的作用是提供一個穩定可靠的代碼基礎。任何開發人員都不允許把未測試或未審查的代碼直接提交到 master 分支。

對代碼的任何修改，包括bug 修復、hotfix、新功能開發等都在單獨的分支中進行。不管是一行代碼的小改動，還是需要幾個星期開發的新功能，都采用同樣的方式來管理。當需要進行修改時，從master 分支創建一個新的分支。新分支的名稱應該簡單清晰地描述該分支的作用。所有相關的代碼修改都在新分支中進行。開發人員可以自由地提交代碼和push 到遠程倉庫。

當新分支中的代碼全部完成之后，通過GitHub 提交一個新的pull request。團隊中的其他人員會對代碼進行審查，提出相關的修改意見。由持續集成服務器（如Jenkins）對新分支進行自動化測試。當代碼通過自動化測試和代碼審查之后，該分支的代碼被合并到master 分支。再從master 分支部署到生產環境。下面是GitHub流程的示意圖，其中commit表示提交，branch表示分支，merge表示合并到當前分支，release表示發布版本。

GitHub流程的好處在于非常簡單實用。開發人員需要注意的事項非常少，很容易形成習慣。當需要進行任何修改時，總是從流程要求項目有完善的自動化測試、持續集成和部署等相關的基礎設施。每個新分支都需要測試和部署，如果這些不能自動化進行，會增加開發人員的工作量，導致無法有效地實施該流程。這種分支實踐也要求團隊有代碼審查的相應流程。?

3.4長周期管理流程

長周期流程應該是目前流傳最廣的版本控制流程。長周期流程圍繞的核心概念是版本發布（release）。因此長周期流程適用于有較長版本發布周期的項目。

目前推崇的做法是持續集成和即時發布，有的項目甚至可以一天發布很多次，即時發布對于，仍然有大量項目的發布周期是幾個星期甚至幾個月。較長的發布周期可能是由于非技術相關的因素造成的，比如人員限制、管理層決策和市場營銷策略等。

長周期流程中包含5類分支，分別是 master、develop、feature、release和 hotfix。這些分支的作用和生命周期各不相同。五分支的對比表如下：

分類類型?	命名規范?	創建自?	合并到?	備注?
master?	master/*?			用來發布版本?
develop?	develop/*?	master?	master?	最新代碼，日常工作分支?
feature?	feature/*?	develop?	develop?	新功能開發?
release?	release/*?	develop?	develop和master?	測試版本提交?
hotfix?	hotfix/*?	master?	develop和master?	補丁版本提交?

master 分支中包含的是可以部署到生產環境中的代碼，這一點和 GitHub flow 是相同的。develop 分支中包含的是下個版本需要發布的內容。從某種意義上來說，develop 是一個進行代碼集成的分支。當 develop 分支集成了足夠的新功能和 bug 修復代碼之后，通過一個發布流程來完成新版本的發布。發布完成之后，develop 分支的代碼會被合并到 master 分支中。?

對于開發過程中的不同任務，需要在對應的分支上進行工作并正確地進行合并。每個任務開始前需要按照指定的步驟完成分支的創建。?

當開發一個新的功能時，流程大致如下：

從develop分支創建一個新的feature分支，如feature/my-awesome-feature。在該feature分支上進行開發，提交代碼，push到遠端倉庫。當代碼完成之后，合并到develop分支并刪除當前feature分支。

當需要發布新版本時，流程大致如下：

從develop分支創建一個新的release分支，如release/1.4。把release分支部署到持續集成服務器上進行測試。測試包括自動化集成測試和手動的用戶接受測試。對于測試中發現的問題，直接在release分支上提交修改。完成修改之后再次部署和測試。當release分支中的代碼通過測試之后，把release分支合并到develop和master分支，并在master分支上添加相應的tag。

?因為長周期流程比較繁瑣和難以記憶，在實踐中一般使用輔助腳本來完成相關的工作。比如：同樣的開發新功能的任務，可以使用git flow feature start my-awesome-feature 來完成新分支的創建，使用git flow feature finish my-awesome-feature 來結束feature 分支。輔助腳本會完成正確的分支創建、切換和合并等工作。

3.5流程選擇考量?

每個開發團隊都應該根據團隊自身和項目的特點來選擇最適合的管理流程。首先是項目的版本發布周期。如果發布周期較長，則長周期流程是最好的選擇。長周期流程可以很好地解決新功能開發、版本發布、生產系統維護等問題；如果發布周期較短，則單主干流程和流程都是不錯的選擇。GitHub流程的特色在于集成了流程是最佳的選擇。GitHub流程和單主干流程對持續集成和自動化測試等基礎設施有比較高的要求，如果相關的基礎設施不完善，則不建議使用。

4.指令大全

4.1新建代碼庫?

# 在當前目錄新建一個Git代碼庫$ git init # 新建一個目錄，將其初始化為Git代碼庫$ git init [project-name] # 下載一個項目和它的整個代碼歷史$ git clone [url]

4.2配置

Git的設置文件為.gitconfig，它可以在用戶主目錄下（全局配置），也可以在項目目錄下（項目配置）。 # 顯示當前的Git配置$ git config --list # 編輯Git配置文件$ git config -e [--global] # 設置提交代碼時的用戶信息$ git config [--global] user.name "[name]"$ git config [--global] user.email "[email address]"

4.3增加/刪除文件

# 添加指定文件到暫存區$ git add [file1] [file2] ... # 添加指定目錄到暫存區，包括子目錄$ git add [dir] # 添加當前目錄的所有文件到暫存區$ git add . # 添加每個變化前，都會要求確認# 對于同一個文件的多處變化，可以實現分次提交$ git add -p # 刪除工作區文件，并且將這次刪除放入暫存區$ git rm [file1] [file2] ... # 停止追蹤指定文件，但該文件會保留在工作區$ git rm --cached [file] # 改名文件，并且將這個改名放入暫存區$ git mv [file-original] [file-renamed]

4.4代碼提交?

# 提交暫存區到倉庫區$ git commit -m [message] # 提交暫存區的指定文件到倉庫區$ git commit [file1] [file2] ... -m [message] # 提交工作區自上次commit之后的變化，直接到倉庫區$ git commit -a # 提交時顯示所有diff信息$ git commit -v # 使用一次新的commit，替代上一次提交# 如果代碼沒有任何新變化，則用來改寫上一次commit的提交信息$ git commit --amend -m [message] # 重做上一次commit，并包括指定文件的新變化$ git commit --amend [file1] [file2] ...

4.5分支?

# 列出所有本地分支$ git branch # 列出所有遠程分支$ git branch -r # 列出所有本地分支和遠程分支$ git branch -a # 新建一個分支，但依然停留在當前分支$ git branch [branch-name] # 新建一個分支，并切換到該分支$ git checkout -b [branch] # 新建一個分支，指向指定commit$ git branch [branch] [commit] # 新建一個分支，與指定的遠程分支建立追蹤關系$ git branch --track [branch] [remote-branch] # 切換到指定分支，并更新工作區$ git checkout [branch-name] # 切換到上一個分支$ git checkout - # 建立追蹤關系，在現有分支與指定的遠程分支之間$ git branch --set-upstream [branch] [remote-branch] # 合并指定分支到當前分支$ git merge [branch] # 選擇一個commit，合并進當前分支$ git cherry-pick [commit] # 刪除分支$ git branch -d [branch-name] # 刪除遠程分支$ git push origin --delete [branch-name]$ git branch -dr [remote/branch]

4.6標簽?

# 列出所有tag$ git tag # 新建一個tag在當前commit$ git tag [tag] # 新建一個tag在指定commit$ git tag [tag] [commit] # 刪除本地tag$ git tag -d [tag] # 刪除遠程tag$ git push origin :refs/tags/[tagName] # 查看tag信息$ git show [tag] # 提交指定tag$ git push [remote] [tag] # 提交所有tag$ git push [remote] --tags # 新建一個分支，指向某個tag$ git checkout -b [branch] [tag]

4.7查看信息?

# 顯示有變更的文件$ git status # 顯示當前分支的版本歷史$ git log # 顯示commit歷史，以及每次commit發生變更的文件$ git log --stat # 搜索提交歷史，根據關鍵詞$ git log -S [keyword] # 顯示某個commit之后的所有變動，每個commit占據一行$ git log [tag] HEAD --pretty=format:%s # 顯示某個commit之后的所有變動，其"提交說明"必須符合搜索條件$ git log [tag] HEAD --grep feature # 顯示某個文件的版本歷史，包括文件改名$ git log --follow [file]$ git whatchanged [file] # 顯示指定文件相關的每一次diff$ git log -p [file] # 顯示過去5次提交$ git log -5 --pretty --oneline # 顯示所有提交過的用戶，按提交次數排序$ git shortlog -sn # 顯示指定文件是什么人在什么時間修改過$ git blame [file] # 顯示暫存區和工作區的代碼差異$ git diff # 顯示暫存區和上一個commit的差異$ git diff --cached [file] # 顯示工作區與當前分支最新commit之間的差異$ git diff HEAD # 顯示兩次提交之間的差異$ git diff [first-branch]...[second-branch] # 顯示今天你寫了多少行代碼$ git diff --shortstat "@{0 day ago}" # 顯示某次提交的元數據和內容變化$ git show [commit] # 顯示某次提交發生變化的文件$ git show --name-only [commit] # 顯示某次提交時，某個文件的內容$ git show [commit]:[filename] # 顯示當前分支的最近幾次提交$ git reflog # 從本地master拉取代碼更新當前分支：branch 一般為master$ git rebase [branch]

4.8遠程同步

#更新遠程倉儲$ git remote update # 下載遠程倉庫的所有變動$ git fetch [remote] # 顯示所有遠程倉庫$ git remote -v # 顯示某個遠程倉庫的信息$ git remote show [remote] # 增加一個新的遠程倉庫，并命名$ git remote add [shortname] [url] # 取回遠程倉庫的變化，并與本地分支合并$ git pull [remote] [branch] # 上傳本地指定分支到遠程倉庫$ git push [remote] [branch] # 強行推送當前分支到遠程倉庫，即使有沖突$ git push [remote] --force # 推送所有分支到遠程倉庫$ git push [remote] --all

4.9撤銷?

# 恢復暫存區的指定文件到工作區$ git checkout [file] # 恢復某個commit的指定文件到暫存區和工作區$ git checkout [commit] [file] # 恢復暫存區的所有文件到工作區$ git checkout . # 重置暫存區的指定文件，與上一次commit保持一致，但工作區不變$ git reset [file] # 重置暫存區與工作區，與上一次commit保持一致$ git reset --hard # 重置當前分支的指針為指定commit，同時重置暫存區，但工作區不變$ git reset [commit] # 重置當前分支的HEAD為指定commit，同時重置暫存區和工作區，與指定commit一致$ git reset --hard [commit] # 重置當前HEAD為指定commit，但保持暫存區和工作區不變$ git reset --keep [commit] # 新建一個commit，用來撤銷指定commit# 后者的所有變化都將被前者抵消，并且應用到當前分支$ git revert [commit] # 暫時將未提交的變化移除，稍后再移入$ git stash$ git stash pop