用git命令編譯

① git mv命令如何使用

git 命令 (gnu interactive tools)
功能說明：文字模式下的文件管理員。
語 法：git 命令
補充說明：git命令是用來管理文件的程序，它十分類似DOS下的Norton Commander，具有互動式操作界面。它的操作方法和Norton Commander幾乎一樣，略訴如下：
F1 ：執行info指令，查詢指令相關信息，會要求您輸入欲查詢的名稱。
F2 ：執行cat指令，列出文件內容。
F3 ：執行gitview指令，觀看文件內容。
F4 ：執行vi指令，編輯文件內容。
F5 ：執行cp指令，復制文件或目錄，會要求您輸入目標文件或目錄。
F6 ：執行mv指令，移動文件或目錄，或是更改其名稱，會要求您輸入目標文件或目錄。
F7 ：執行mkdir指令，建立目錄。
F8 ：執行rm指令，刪除文件或目錄。
F9 ：執行make指令，批處理執行指令或編譯程序時，會要求您輸入相關命令。
F10 ：離開git文件管理員。

----------------- Git命令具體使用-------------------------------
Git是一個分布式的版本控制工具，本篇文章從介紹Git開始，重點在於介紹Git的基本命令和使用技巧，讓你嘗試使用Git的同時，體驗到原來一個版本控制工具可以對開發產生如此之多的影響，文章分為兩部分：
第一部分，介紹Git的一些常用命令，其中穿插介紹Git的基本概念和原理
第二部分，重點介紹Git的使用技巧，最後會在Git Hub上創建一個開源項目開啟你的Git實戰之旅

Git是什麼
Git 在Wikipedia上的定義：它是一個免費的、分布式的版本控制工具，或是一個強調了速度快的源代碼管理工具。
Git 最初被Linus Torvalds開發出來用於管理linux內核的開發。每一個Git的工作目錄都是一個完全獨立的代碼庫，並擁有完整的歷史記錄和版本追蹤能力，不依賴於網路和中心伺服器。
Git 的出現減輕了許多開發者和開源項目對於管理分支代碼的壓力，由於對分支的良好控制，更鼓勵開發者對自己感興趣的項目做出貢獻。其實許多開源項目包括 Linux kernel、Samba、X.org Server、Ruby on Rails，都已經過渡到使用Git作為自己的版本控制工具。對於我們這些喜歡寫代碼的開發者嘛，有兩點最大的好處，我們可以在任何地點（在上班的地鐵 上）提交自己的代碼和查看代碼版本；我們可以開許許多多個分支來實踐我們的想法，而合並這些分支的開銷幾乎可以忽略不計。

Git 1+1
現在進入本篇文章真正的主題，介紹一下Git的基本命令和操作，會從Git的版本庫的初始化，基本操作和獨有的常用命令三部分著手，讓大家能夠開始使用Git。
Git 通常有兩種方式來進行初始化:
git clone: 這是較為簡單的一種初始化方式，當你已經有一個遠程的Git版本庫，只需要在本地克隆一份
例如：git clone git://github.com/someone/some_project.git some_project
上面的命令就是將'git://github.com/someone/some_project.git'這個URL地址的遠程版本庫完全克隆到本地some_project目錄下面
git init和git remote：這種方式稍微復雜一些，當你本地創建了一個工作目錄，你可以進入這個目錄，使用'git init'命令進行初始化，Git以後就會對該目錄下的文件進行版本控制，這時候如果你需要將它放到遠程伺服器上，可以在遠程伺服器上創建一個目錄，並把 可訪問的URL記錄下來，此時你就可以利用'git remote add'命令來增加一個遠程伺服器端，
例如：git remote add origin git://github.com/someone/another_project.git
上面的命令就會增加URL地址為'git: //github.com/someone/another_project.git'，名稱為origin的遠程伺服器，以後提交代碼的時候只需要使用 origin別名即可

Git 的基本命令
現在我們有了本地和遠程的版本庫，讓我們來試著用用Git的基本命令：
git pull：從其他的版本庫（既可以是遠程的也可以是本地的）將代碼更新到本地，例如：'git pull origin master'就是將origin這個版本庫的代碼更新到本地的master主枝，該功能類似於SVN的update
git add：是 將當前更改或者新增的文件加入到Git的索引中，加入到Git的索引中就表示記入了版本歷史中，這也是提交之前所需要執行的一步，例如'git add app/model/user.rb'就會增加app/model/user.rb文件到Git的索引中，該功能類似於SVN的add
git rm：從當前的工作空間中和索引中刪除文件，例如'git rm app/model/user.rb'，該功能類似於SVN的rm、del
git commit：提交當前工作空間的修改內容，類似於SVN的commit命令，例如'git commit -m story #3, add user model'，提交的時候必須用-m來輸入一條提交信息，該功能類似於SVN的commit
git push：將本地commit的代碼更新到遠程版本庫中，例如'git push origin'就會將本地的代碼更新到名為orgin的遠程版本庫中
git log：查看歷史日誌，該功能類似於SVN的log
git revert：還原一個版本的修改，必須提供一個具體的Git版本號，例如'git revert '，Git的版本號都是生成的一個哈希值

上面的命令幾乎都是每個版本控制工具所公有的，下面就開始嘗試一下Git獨有的一些命令：
git branch：對分支的增、刪、查等操作，例如'git branch new_branch'會從當前的工作版本創建一個叫做new_branch的新分支，'git branch -D new_branch'就會強制刪除叫做new_branch的分支，'git branch'就會列出本地所有的分支
git checkout：Git的checkout有兩個作用，其一是在不同的branch之間進行切換，例如'git checkout new_branch'就會切換到new_branch的分支上去；另一個功能是還原代碼的作用，例如'git checkout app/model/user.rb'就會將user.rb文件從上一個已提交的版本中更新回來，未提交的內容全部會回滾
git rebase：用下面兩幅圖解釋會比較清楚一些，rebase命令執行後，實際上是將分支點從C移到了G，這樣分支也就具有了從C到G的功能

git reset：將當前的工作目錄完全回滾到指定的版本號，假設如下圖，我們有A-G五次提交的版本，其中C的版本號是 ，我們執行了'git reset '那麼結果就只剩下了A-C三個提交的版本

git stash：將當前未提交的工作存入Git工作棧中，時機成熟的時候再應用回來，這里暫時提一下這個命令的用法，後面在技巧篇會重點講解
git config：利用這個命令可以新增、更改Git的各種設置，例如'git config branch.master.remote origin'就將master的遠程版本庫設置為別名叫做origin版本庫，後面在技巧篇會利用這個命令個性化設置你的Git，為你打造獨一無二的 Git
git tag：可以將某個具體的版本打上一個標簽，這樣你就不需要記憶復雜的版本號哈希值了，例如你可以使用'git tag revert_version '來標記這個被你還原的版本，那麼以後你想查看該版本時，就可以使用 revert_version標簽名，而不是哈希值了
Git 之所以能夠提供方便的本地分支等特性，是與它的文件存儲機制有關的。Git存儲版本控制信息時使用它自己定義的一套文件系統存儲機制，在代碼根目錄下有一個.git文件夾，會有如下這樣的目錄結構：

有 幾個比較重要的文件和目錄需要解釋一下：HEAD文件存放根節點的信息，其實目錄結構就表示一個樹型結構，Git採用這種樹形結構來存儲版本信息，那麼 HEAD就表示根；refs目錄存儲了你在當前版本控制目錄下的各種不同引用（引用指的是你本地和遠程所用到的各個樹分支的信息），它有heads、 remotes、stash、tags四個子目錄，分別存儲對不同的根、遠程版本庫、Git棧和標簽的四種引用，你可以通過命令'git show-ref'更清晰地查看引用信息；logs目錄根據不同的引用存儲了日誌信息。因此，Git只需要代碼根目錄下的這一個.git目錄就可以記錄完 整的版本控制信息，而不是像SVN那樣根目錄和子目錄下都有.svn目錄。那麼下面就來看一下Git與SVN的區別吧

Git與SVN的不同
SVN（Subversion）是當前使用最多的版本控制工具。與它相比較，Git 最大的優勢在於兩點：易於本地增加分支和分布式的特性。
下面兩幅圖可以形象的展示Git與SVN的不同之處

------------

對 於易於本地增加分支，圖中Git本地和伺服器端結構都很靈活，所有版本都存儲在一個目錄中，你只需要進行分支的切換即可達到在某個分支工作的效果。而 SVN則完全不同，如果你需要在本地試驗一些自己的代碼，只能本地維護多個不同的拷貝，每個拷貝對應一個SVN伺服器地址。舉一個實際的例子，以前我所在 的小組使用SVN作為版本控制工具，當我正在試圖增強一個模塊，工作做到一半，由於會改變原模塊的行為導致代碼伺服器上許多測試的失敗，所以並沒有提交代 碼。這時候上級對我說，現在有一個很緊急的Bug需要處理， 必須在兩個小時內完成。我只好將本地的所有修改diff，並輸出成為一個patch文 件，然後回滾有關當前任務的所有代碼，再開始修改Bug的任務，等到修改好後，在將patch應用回來。前前後後要完成多個繁瑣的步驟，這還不計中間代碼 發生沖突所要進行的工作量。可是如果使用Git， 我們只需要開一個分支或者轉回到主分支上，就可以隨時開始Bug修改的任務，完成之後，只要切換到原來的分支就可以優雅的繼續以前的任務。只要你願意，每 一個新的任務都可以開一個分支，完成後，再將它合並到主分支上，輕松而優雅。
分布式對於Git而言，你可以本地提交代碼，所以在上面的圖 中，Git有利於將一個大任務分解，進行本地的多次提交，而SVN只能在本地進行大量的一次性更改，導致將來合並到主幹上造成巨大的風險。Git的代碼日 志是在本地的，可以隨時查看。SVN的日誌在伺服器上的，每次查看日誌需要先從伺服器上下載下來。我工作的小組，代碼伺服器在美國，每次查看小組幾年前所 做的工作時，日誌下載就需要十分鍾，這不能不說是一個痛苦。後來我們遷移到Git上，利用Git日誌在本地的特性，我用Ruby編寫了一個Rake腳本， 可以查看某個具體任務的所有代碼歷史，每次只需要幾秒鍾，大大方便我的工作。當然分布式並不是說用了Git就不需要一個代碼中心伺服器，如果你工作在一個 團隊里，還是需要一個伺服器來保存所有的代碼的。

總結
本篇介紹了Git的基本概念、一些常用命令和原理，大家可以嘗試動手體會一下，下一篇會重點介紹Git命令的使用技巧，Git附帶的工具，最後會在Git Hub上創建一個開源項目，敬請期待

② 自己可以編譯安卓源碼嗎

用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:

sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」

其中[email protected]為你自己的郵箱.

簡要說明

android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.

源碼下載

由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)

repo工具下載及安裝

通過執行以下命令實現repo工具的下載和安裝

mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo

補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:

我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:

這里寫圖片描述

執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.

錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:

通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)

如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.

結束吧

到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.

③ 怎麼才能在windows使用git命令

在windows使用git命令方法如下（以win7為例）：

1、msysgit 是 Windows 版的 Git可以網路搜索Git下載。
2、安裝完成後，開始菜單里找到「Git」->「Git Bash」打開Git。
3、注冊用戶信息：首先配置你的用戶信息的Git命令。
$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"
4、配置完成後使用 $ git config --list查看配置的用戶信息、
5、創建版本庫$ cd d: 和cd MyGit進入新建的Git目錄（什麼是版本庫？版本庫又名倉庫，英文名repository,你可以簡單的理解一個目錄）
6、$ mkdir project # 創建項目目錄 ，$ cd project # 進入到項目目錄.
7、git init # 初始化 git 倉庫。此命令會在當前目錄新建一個 .git 目錄，用於存儲 git 倉庫的相關信息 ,把這個目錄變成git可以管理的倉庫.
8、以上就是Git創建版本庫操作方法

④ 幾個常用的git命令

1.安裝Git

• Linux

• sudo apt-get install git



• Window:到Git官網下載安裝：https://git-scm.com/downloads

2.配置全局用戶Name和E-mail

• $ git config --global user.name "Your Name"


• $ git config --global user.email "[email protected]"



3.初始化倉庫

• git init



4.添加文件到Git倉庫

• git add <file>



提示：可反復多次使用，添加多個文件；

5.提交添加的文件到Git倉庫

• git commit



然後會彈出一個Vim編輯器輸入本次提交的內容；

或者

• git commit -m "提交說明"



6.查看倉庫當前的狀態

• git status



7.比較當前文件的修改

• $ git diff <file>



8.查看歷史提交記錄

• git log



或者加上參數查看就比較清晰了

• $ git log --pretty=oneline



9.回退版本

• $ git reset --hard HEAD^



說明：在Git中，用HEAD表示當前版本，上一個版本就是HEAD^，上上一個版本就是HEAD^^，以此類推，如果需要回退幾十個版本，寫幾十個^容易數不過來，所以可以寫，例如回退30個版本為：HEAD~30。

如果你回退完版本又後悔了，想回來，一般情況下是回不來的，但是如果你可以找到你之前的commit id的話，也是可以的，使用如下即可：

• $ git reset --hard + commit id



提示：commit id不需要寫全，Git會自動查找；

補充說明：Git中，commit id是一個使用SHA1計算出來的一個非常大的數字，用十六進製表示，你提交時看到的一大串類似3628164...882e1e0的就是commit id（版本號）；

在Git中，版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向回退的版本，然後順便刷新工作區文件；

10.查看操作的歷史命令記錄

• $ git reflog



結果會將你之前的操作的commit id和具體的操作類型及相關的信息列印出來，這個命令還有一個作用就是，當你過了幾天，你想回退之前的某次提交，但是你不知道commit id了，通過這個你可查找出commit id,就可以輕松回退了，用一句話總結：穿越未來，回到過去，so easy！

11.diff文件

• git diff HEAD -- <file>



說明：查看工作區和版本庫裡面最新版本文件的區別，也可以不加HEAD參數；

12.丟棄工作區的修改

• $ git checkout -- <file>



說明：適用於工作區修改沒有add的文件

13.丟棄暫存區的文件

• $ git reset HEAD <file>



說明：適用於暫存區已經add的文件，注意執行完此命令，他會將暫存區的修改放回到工作區中，如果要想工作區的修改也丟棄，就執行第12條命令即可；

14.刪除文件

• $ rm <file>



然後提交即可；

如果不小心刪錯了，如果還沒有提交的話使用下面命令即可恢復刪除，注意的是它只能恢復最近版本提交的修改，你工作區的修改是不能被恢復的！

• $ git checkout -- <file>

⑤ idea從gitlab拉項目到本地怎麼編譯

隨意打開一個項目，選擇file，點擊Settings。先選擇虧碼VersionControl，再點擊Git，把安裝的git位置找到，再點點擊Test，配置git成功，任意打開一個項目後，點擊File點擊NeProjectfromVersionControl，點擊Git，彈出對話框，URL：git地址，Directory：拉取代碼到本地目錄，將獲取到的git地址復制到URL裡面，再點擊Test，點擊Test將會彈出以下模態者晌框，輸入申請的git賬號、密碼，點擊LogIn，再點擊Clone，就是拉取代碼，再點擊Clone，就是拉取代碼，彈出以下框，點擊NewWindow大功告成。
按照上述步驟操作即可，需要注意的是，過程中可能會出現一些問題：比如彈出gitlab賬號密碼輸入框，解決辦法：自定義token名，勾選許可權，生成token，該token作為密碼輸入，賬號仍為gitlab登錄名，登陸成功。
代碼是程序員用開發銷嫌哪工具所支持的語言寫出來的源文件，是一組由字元、符號或信號碼元以離散形式表示信息的明確的規則體系。

⑥ 45 個 Git 經典操作場景，專治不會合代碼-

git 對於大家應該都不太陌生，熟練使用git已經成為程序員的一項基本技能，盡管在工作中有諸如 Sourcetree 這樣牛X的客戶端工具，使得合並代碼變的很方便。但找工作面試和一些需彰顯個人實力的場景，仍然需要我們掌握足夠多的git命令。

下邊我們整理了45個日常用git合代碼的經典操作場景，基本覆蓋了工作中的需求。

如果你用 git commit -a 提交了一次變化(changes)，而你又不確定到底這次提交了哪些內容。你就可以用下面的命令顯示當前 HEAD 上的最近一次的提交(commit):

或者

如果你的提交信息( commit message )寫錯了且這次提交(commit)還沒有推(push), 你可以通過下面的方法來修改提交信息( commit message ):

這會打開你的默認編輯器, 在這里你可以編輯信息. 另一方面, 你也可以用一條命令一次完成:

如果你已經推(push)了這次提交(commit), 你可以修改這次提交(commit)然後強推( force push ), 但是不推薦這么做。

如果這只是單個提交(commit)，修改它：

如果你需要修改所有 歷史 , 參考 'git filter-branch'的指南頁.

通過下面的方法，從一個提交(commit)里移除一個文件:

這將非常有用，當你有一個開放的補丁( open patch )，你往上面提交了一個不必要的文件，你需要強推( force push )去更新這個遠程補丁。

如果你需要刪除推了的提交( pushed commits )，你可以使用下面的方法。可是，這會不可逆的改變你的 歷史 ，也會搞亂那些已經從該倉庫拉取(pulled)了的人的 歷史 。簡而言之，如果你不是很確定，千萬不要這么做。

如果你還沒有推到遠程, 把Git重置(reset)到你最後一次提交前的狀態就可以了(同時保存暫存的變化):

這只能在沒有推送之前有用. 如果你已經推了, 唯一安全能做的是 git revert SHAofBadCommit ， 那會創建一個新的提交(commit)用於撤消前一個提交的所有變化(changes)；或者, 如果你推的這個分支是rebase-safe的 (例如：其它開發者不會從這個分支拉), 只需要使用 git push -f 。

同樣的警告：不到萬不得已的時候不要這么做.

或者做一個 互動式rebase 刪除那些你想要刪除的提交(commit)里所對應的行。

注意, rebasing(見下面)和修正(amending)會用一個 新的提交(commit)代替舊的 , 所以如果之前你已經往遠程倉庫上推過一次修正前的提交(commit)，那你現在就必須強推( force push ) ( -f )。注意 – 總是 確保你指明一個分支!

一般來說, 要避免強推 . 最好是創建和推(push)一個新的提交(commit)，而不是強推一個修正後的提交。後者會使那些與該分支或該分支的子分支工作的開發者，在源 歷史 中產生沖突。

如果你意外的做了 git reset --hard , 你通常能找回你的提交(commit), 因為Git對每件事都會有日誌，且都會保存幾天。

你將會看到一個你過去提交(commit)的列表, 和一個重置的提交。選擇你想要回到的提交(commit)的SHA，再重置一次:

這樣就完成了。

一般來說, 如果你想暫存一個文件的一部分, 你可這樣做:

-p 簡寫。這會打開交互模式， 你將能夠用 s 選項來分隔提交(commit)；然而, 如果這個文件是新的, 會沒有這個選擇， 添加一個新文件時, 這樣做:

然後, 你需要用 e 選項來手動選擇需要添加的行，執行 git diff --cached 將會顯示哪些行暫存了哪些行只是保存在本地了。

git add 會把整個文件加入到一個提交. git add -p 允許互動式的選擇你想要提交的部分.

多數情況下，你應該將所有的內容變為未暫存，然後再選擇你想要的內容進行commit。但假定你就是想要這么做，這里你可以創建一個臨時的commit來保存你已暫存的內容，然後暫存你的未暫存的內容並進行stash。然後reset最後一個commit將原本暫存的內容變為未暫存，最後stash pop回來。

注意1: 這里使用 pop 僅僅是因為想盡可能保持冪等。注意2: 假如你不加上 --index 你會把暫存的文件標記為為存儲。

如果你只是想重置源(origin)和你本地(local)之間的一些提交(commit)，你可以：

重置某個特殊的文件, 你可以用文件名做為參數:

如果你想丟棄工作拷貝中的一部分內容，而不是全部。

簽出(checkout)不需要的內容，保留需要的。

另外一個方法是使用 stash ， Stash所有要保留下的內容, 重置工作拷貝, 重新應用保留的部分。

或者, stash 你不需要的部分, 然後stash drop。

這是另外一種使用 git reflog 情況，找到在這次錯誤拉(pull) 之前HEAD的指向。

重置分支到你所需的提交(desired commit):

完成。

先確認你沒有推(push)你的內容到遠程。

git status 會顯示你領先(ahead)源(origin)多少個提交:

一種方法是:

在main下創建一個新分支，不切換到新分支,仍在main下:

把main分支重置到前一個提交:

HEAD^ 是 HEAD^1 的簡寫，你可以通過指定要設置的 HEAD 來進一步重置。

或者, 如果你不想使用 HEAD^ , 找到你想重置到的提交(commit)的hash( git log 能夠完成)， 然後重置到這個hash。使用 git push 同步內容到遠程。

例如, main分支想重置到的提交的hash為 a13b85e :

簽出(checkout)剛才新建的分支繼續工作:

假設你正在做一個原型方案(原文為working spike (see note)), 有成百的內容，每個都工作得很好。現在, 你提交到了一個分支，保存工作內容:

當你想要把它放到一個分支里 (可能是 feature , 或者 develop ), 你關心是保持整個文件的完整，你想要一個大的提交分隔成比較小。

假設你有:

我去可以通過把內容拿到你的分支里，來解決這個問題:

這會把這個文件內容從分支 solution 拿到分支 develop 里來:

然後, 正常提交。

假設你有一個 main 分支， 執行 git log , 你看到你做過兩次提交:

讓我們用提交hash(commit hash)標記bug ( e3851e8 for #21, 5ea5173 for #14).

首先, 我們把 main 分支重置到正確的提交( a13b85e ):

現在, 我們對 bug #21 創建一個新的分支:

接著, 我們用 _cherry-pick_ 把對 bug #21 的提交放入當前分支。這意味著我們將應用(apply)這個提交(commit)，僅僅這一個提交(commit)，直接在HEAD上面。

這時候, 這里可能會產生沖突， 參見互動式 rebasing 章 沖突節 解決沖突.

再者， 我們為bug #14 創建一個新的分支, 也基於 main 分支

最後, 為 bug #14 執行 cherry-pick :

一旦你在github 上面合並(merge)了一個 pull request , 你就可以刪除你fork里被合並的分支。如果你不準備繼續在這個分支里工作, 刪除這個分支的本地拷貝會更干凈，使你不會陷入工作分支和一堆陳舊分支的混亂之中。

如果你定期推送到遠程, 多數情況下應該是安全的，但有些時候還是可能刪除了還沒有推到遠程的分支。讓我們先創建一個分支和一個新的文件:

添加文件並做一次提交

現在我們切回到主(main)分支，『不小心的』刪除 my-branch 分支

在這時候你應該想起了 reflog , 一個升級版的日誌，它存儲了倉庫(repo)裡面所有動作的 歷史 。

正如你所見，我們有一個來自刪除分支的提交hash(commit hash)，接下來看看是否能恢復刪除了的分支。

看! 我們把刪除的文件找回來了。Git的 reflog 在rebasing出錯的時候也是同樣有用的。

刪除一個遠程分支:

你也可以:

刪除一個本地分支:

首先, 從遠程拉取(fetch) 所有分支:

假設你想要從遠程的 daves 分支簽出到本地的 daves

( --track 是 git checkout -b [branch] [remotename]/[branch] 的簡寫)

這樣就得到了一個 daves 分支的本地拷貝, 任何推過(pushed)的更新，遠程都能看到.

你可以合並(merge)或rebase了一個錯誤的分支, 或者完成不了一個進行中的rebase/merge。Git 在進行危險操作的時候會把原始的HEAD保存在一個叫ORIG_HEAD的變數里, 所以要把分支恢復到rebase/merge前的狀態是很容易的。

不幸的是，如果你想把這些變化(changes)反應到遠程分支上，你就必須得強推( force push )。是因你快進( Fast forward )了提交，改變了Git 歷史 , 遠程分支不會接受變化(changes)，除非強推(force push)。

這就是許多人使用 merge 工作流, 而不是 rebasing 工作流的主要原因之一， 開發者的強推(force push)會使大的團隊陷入麻煩。使用時需要注意，一種安全使用 rebase 的方法是，不要把你的變化(changes)反映到遠程分支上, 而是按下面的做:

假設你的工作分支將會做對於 main 的pull-request。一般情況下你不關心提交(commit)的時間戳，只想組合 所有 提交(commit) 到一個單獨的裡面, 然後重置(reset)重提交(recommit)。確保主(main)分支是最新的和你的變化都已經提交了, 然後:

如果你想要更多的控制, 想要保留時間戳, 你需要做互動式rebase (interactive rebase):

如果沒有相對的其它分支， 你將不得不相對自己的 HEAD 進行 rebase。例如：你想組合最近的兩次提交(commit), 你將相對於 HEAD~2 進行rebase， 組合最近3次提交(commit), 相對於 HEAD~3 , 等等。

在你執行了互動式 rebase的命令(interactive rebase command)後, 你將在你的編輯器里看到類似下面的內容:

所有以 # 開頭的行都是注釋, 不會影響 rebase.

然後，你可以用任何上面命令列表的命令替換 pick , 你也可以通過刪除對應的行來刪除一個提交(commit)。

例如, 如果你想 單獨保留最舊(first)的提交(commit),組合所有剩下的到第二個裡面 , 你就應該編輯第二個提交(commit)後面的每個提交(commit) 前的單詞為 f :

如果你想組合這些提交(commit) 並重命名這個提交(commit) , 你應該在第二個提交(commit)旁邊添加一個 r ，或者更簡單的用 s 替代 f :

你可以在接下來彈出的文本提示框里重命名提交(commit)。

如果成功了, 你應該看到類似下面的內容:

--no-commit 執行合並(merge)但不自動提交, 給用戶在做提交前檢查和修改的機會。 no-ff 會為特性分支(feature branch)的存在過留下證據, 保持項目 歷史 一致。

有時候，在將數據推向上游之前，你有幾個正在進行的工作提交(commit)。這時候不希望把已經推(push)過的組合進來，因為其他人可能已經有提交(commit)引用它們了。

這會產生一次互動式的rebase(interactive rebase), 只會列出沒有推(push)的提交(commit)， 在這個列表時進行reorder/fix/squash 都是安全的。

檢查一個分支上的所有提交(commit)是否都已經合並(merge)到了其它分支, 你應該在這些分支的head(或任何 commits)之間做一次diff:

這會告訴你在一個分支里有而另一個分支沒有的所有提交(commit), 和分支之間不共享的提交(commit)的列表。另一個做法可以是:

如果你看到的是這樣:

這意味著你rebase的分支和當前分支在同一個提交(commit)上, 或者 領先(ahead) 當前分支。你可以嘗試:

如果你不能成功的完成rebase, 你可能必須要解決沖突。

首先執行 git status 找出哪些文件有沖突:

在這個例子裡面, README.md 有沖突。打開這個文件找到類似下面的內容:

你需要解決新提交的代碼(示例里, 從中間 == 線到 new-commit 的地方)與 HEAD 之間不一樣的地方.

有時候這些合並非常復雜，你應該使用可視化的差異編輯器(visual diff editor):

在你解決完所有沖突和測試過後, git add 變化了的(changed)文件, 然後用 git rebase --continue 繼續rebase。

如果在解決完所有的沖突過後，得到了與提交前一樣的結果, 可以執行 git rebase --skip 。

任何時候你想結束整個rebase 過程，回來rebase前的分支狀態, 你可以做:

暫存你工作目錄下的所有改動

你可以使用 -u 來排除一些文件

假設你只想暫存某一個文件

假設你想暫存多個文件

這樣你可以在 list 時看到它

或

首先你可以查看你的 stash 記錄

然後你可以 apply 某個 stash

此處， 'n'是 stash 在棧中的位置，最上層的 stash 會是0

除此之外，也可以使用時間標記(假如你能記得的話)。

你需要手動create一個 stash commit ， 然後使用 git stash store 。

如果已經克隆了:

如果你想恢復一個已刪除標簽(tag), 可以按照下面的步驟: 首先, 需要找到無法訪問的標簽(unreachable tag):

記下這個標簽(tag)的hash，然後用Git的 update-ref

這時你的標簽(tag)應該已經恢復了。

如果某人在 GitHub 上給你發了一個 pull request , 但是然後他刪除了他自己的原始 fork, 你將沒法克隆他們的提交(commit)或使用 git am 。在這種情況下, 最好手動的查看他們的提交(commit)，並把它們拷貝到一個本地新分支，然後做提交。

做完提交後, 再修改作者，參見變更作者。然後, 應用變化, 再發起一個新的 pull request 。

在 OS X 和 Linux 下, 你的 Git的配置文件儲存在 ~/.gitconfig 。我在 [alias] 部分添加了一些快捷別名(和一些我容易拼寫錯誤的)，如下:

你可能有一個倉庫需要授權，這時你可以緩存用戶名和密碼，而不用每次推/拉(push/pull)的時候都輸入，Credential helper能幫你。

你把事情搞砸了：你 重置(reset) 了一些東西, 或者你合並了錯誤的分支, 亦或你強推了後找不到你自己的提交(commit)了。有些時候, 你一直都做得很好, 但你想回到以前的某個狀態。

這就是 git reflog 的目的， reflog 記錄對分支頂端(the tip of a branch)的任何改變, 即使那個頂端沒有被任何分支或標簽引用。基本上, 每次HEAD的改變, 一條新的記錄就會增加到 reflog 。遺憾的是，這只對本地分支起作用，且它只跟蹤動作 (例如，不會跟蹤一個沒有被記錄的文件的任何改變)。

上面的reflog展示了從main分支簽出(checkout)到2.2 分支，然後再簽回。那裡，還有一個硬重置(hard reset)到一個較舊的提交。最新的動作出現在最上面以 HEAD@{0} 標識.

如果事實證明你不小心回移(move back)了提交(commit), reflog 會包含你不小心回移前main上指向的提交(0254ea7)。

然後使用 git reset 就可以把main改回到之前的commit，這提供了一個在 歷史 被意外更改情況下的安全網。

⑦ git commit命令是做什麼用的

git commit主要是將暫存區里的改動給提交到本地的版本庫。

每次使用git commit 命令我們都會在本地版本庫生成一個40位的哈希值，這個哈希值也叫commit-id，commit-id在版本回退的時候是非常有用的，它相當於一個快照,可以在未來的任何時候通過與git reset的組合命令回到這里。

git commit-a-m"提交的描述信息"

git commit命令的-a選項可只將所有被修改或者已刪除的且已經被git管理的文檔提交倒倉庫中。如果只是修改或者刪除了已被Git 管理的文檔，是沒必要使用git add命令的。

git add.命令除了能夠判斷出當前目錄（包括其子目錄）所有被修改或者已刪除的文檔，還能判斷用戶所添加的新文檔，並將其信息追加到索引中。

git commit--amend對於已經修改提交過的注釋，如果需要修改，可以藉助 git commit --amend 來進行。

(7)用git命令編譯擴展閱讀

COMMIT（操作指令）

COMMIT命令用於把事務所做的修改保存到資料庫，它把上一個COMMIT或ROLLBACK命令之後的全部事務都保存到資料庫。

用途

使用COMMIT提交當前事務，使事務中執行的變更永久化，所有事務的更改都將為其他事務可見，而且保證當崩潰發生時的可持續性。

通過修改的表，查看事務期間所作的任何更改，但其他用戶不能看到所做的更改。

可以回滾ROLLBACK語句與事務過程中所做的任何更改。

可以使用此語句手動提交疑問在分布式的事務上。

可以使用此語句終止SET TRANSACTION語句的只讀事務。

參考資料

COMMIT-網路