git編譯命令

① gitlab-CI中使用tag作為版本號硬編譯進程序中

在使用gitlab過程中,我發現如果能直接將gitlab的tag與自動生成的軟體版本做成一致的話,在後續的維護上會更加方便.於是研究了一番如何將tag作為版本號硬編譯進程序中的方法.主要是一下幾個方面:

指定只對tag生效

可以使用類似c++的方式,生成version.go文件來實現,也可以編譯命令中直接修改源文件中指定的值,比如:

version.go中:

那麼在gitlab-ci.yml中就可以

即可將Version修改為當前tag

② 為什麼Linux上查看git版本會提示-bash: No such file or directory

你這路徑不對啊 圖的上路徑應該是/usr/local/bin 命令提示符的時/usr/bin

你創建一個軟鏈接過去

③ 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，這提供了一個在 歷史 被意外更改情況下的安全網。

④ 如何在CentOS 7中安裝Git

工具：機器上安裝有CentOS 7系統以及一個帳戶具有root許可權

1.

安裝Git -從源代碼編譯

可以打開CentOS7終端，運行以下命令。

拿到root許可權

su root

使用下面的命令

sudo yum install "Development Tools"

⑤ Git 不要只會 pull 和 push，試試這 5 條提高效率的命令

使用 Git 作為代碼版本管理，早已是現在開發工程師必備的技能。可大多數工程師還是只會最基本的保存、拉取、推送，遇到一些commit管理的問題就束手無策，或者用一些不優雅的方式解決。

本文分享我在開發工作中實踐過的實用命令。這些都能夠大大提高工作效率，還能解決不少疑難場景。下面會介紹命令，列出應用場景，手摸手教學使用，讓同學們看完即學會。

官方解釋：當您想記錄工作目錄和索引的當前狀態，但又想返回一個干凈的工作目錄時，請使用git stash。該命令將保存本地修改，並恢復工作目錄以匹配頭部提交。

stash 命令能夠將還未 commit 的代碼存起來，讓你的工作目錄變得干凈。

我猜你心裡一定在想：為什麼要變干凈？

應用場景：某一天你正在 feature 分支開發新需求，突然產品經理跑過來說線上有bug，必須馬上修復。而此時你的功能開發到一半，於是你急忙想切到 master 分支，然後你就會看到以下報錯：

因為當前有文件更改了，需要提交commit保持工作區干凈才能切分支。由於情況緊急，你只有急忙 commit 上去，commit 信息也隨便寫了個「暫存代碼」，於是該分支提交記錄就留了一條黑 歷史 …(真人真事，看過這種提交)

如果你學會 stash，就不用那麼狼狽了。你只需要：

就這么簡單，代碼就被存起來了。

當你修復完線上問題，切回 feature 分支，想恢復代碼也只需要：

當有多條 stash，可以指定操作stash，首先使用stash list 列出所有記錄：

應用第二條記錄：

pop，drop 同理。

stash 代碼

填寫備注內容，也可以不填直接Enter

在STASHES菜單中可以看到保存的stash

先點擊stash記錄旁的小箭頭，再點擊 apply 或者 pop 都可恢復 stash

完全不接觸索引文件或工作樹（但會像所有模式一樣，將頭部重置為）。這使您的所有更改的文件更改為「要提交的更改」。

回退你已提交的 commit，並將 commit 的修改內容放回到暫存區。

一般我們在使用 reset 命令時， git reset --hard 會被提及的比較多，它能讓 commit 記錄強制回溯到某一個節點。而 git reset --soft 的作用正如其名， --soft (柔軟的) 除了回溯節點外，還會保留節點的修改內容。

回溯節點，為什麼要保留修改內容？

應用場景1：有時候手滑不小心把不該提交的內容 commit 了，這時想改回來，只能再 commit 一次，又多一條「黑 歷史 」。

應用場景2：規范些的團隊，一般對於 commit 的內容要求職責明確，顆粒度要細，便於後續出現問題排查。本來屬於兩塊不同功能的修改，一起 commit 上去，這種就屬於不規范。這次恰好又手滑了，一次性 commit 上去。

學會 reset --soft 之後，你只需要：

reset --soft 相當於後悔葯，給你重新改過的機會。對於上面的場景，就可以再次修改重新提交，保持干凈的 commit 記錄。

以上說的是還未 push 的commit。對於已經 push 的 commit，也可以使用該命令，不過再次 push 時，由於遠程分支和本地分支有差異，需要強制推送 git push -f 來覆蓋被 reset 的 commit。

還有一點需要注意，在 reset --soft 指定 commit 號時，會將該 commit 到最近一次 commit 的所有修改內容全部恢復，而不是只針對該 commit。

舉個例子：

commit 記錄有 c、b、a。

reset 到 a。

此時的 HEAD 到了 a，而 b、c 的修改內容都回到了暫存區。

給定一個或多個現有提交，應用每個提交引入的更改，為每個提交記錄一個新的提交。這需要您的工作樹清潔（沒有從頭提交的修改）。

將已經提交的 commit，復制出新的 commit 應用到分支里

commit 都提交了，為什麼還要復制新的出來？

應用場景1：有時候版本的一些優化需求開發到一半，可能其中某一個開發完的需求要臨時上，或者某些原因導致待開發的需求卡住了已開發完成的需求上線。這時候就需要把 commit 抽出來，單獨處理。

應用場景2：有時候開發分支中的代碼記錄被污染了，導致開發分支合到線上分支有問題，這時就需要拉一條干凈的開發分支，再從舊的開發分支中，把 commit 復制到新分支。

復制單個

現在有一條feature分支，commit 記錄如下：

需要把 b 復制到另一個分支，首先把 commitHash 復制下來，然後切到 master 分支。

當前 master 最新的記錄是 a，使用 cherry-pick 把 b 應用到當前分支。

完成後看下最新的 log，b 已經應用到 master，作為最新的 commit 了。可以看到 commitHash 和之前的不一樣，但是提交時間還是保留之前的。微信搜索公眾號：java後端編程，回復：java 領取資料 。

復制多個

以上是單個 commit 的復制，下面再來看看 cherry-pick 多個 commit 要如何操作。

上面的命令將 commit1 和 commit2 兩個提交應用到當前分支。

上面的命令將 commit1 到 commit2 這個區間的 commit 都應用到當前分支（包含commit1、commit2），commit1 是最早的提交。

在 cherry-pick 多個commit時，可能會遇到代碼沖突，這時 cherry-pick 會停下來，讓用戶決定如何繼續操作。下面看看怎麼解決這種場景。

還是 feature 分支，現在需要把 c、d、e 都復制到 master 分支上。先把起點c和終點e的 commitHash 記下來。

切到 master 分支，使用區間的 cherry-pick 。可以看到 c 被成功復制，當進行到 d 時，發現代碼沖突， cherry-pick 中斷了。這時需要解決代碼沖突，重新提交到暫存區。

然後使用 cherry-pick --continue 讓 cherry-pick 繼續進行下去。最後 e 也被復制進來，整個流程就完成了。

以上是完整的流程，但有時候可能需要在代碼沖突後，放棄或者退出流程：

回到操作前的樣子，就像什麼都沒發生過。

不回到操作前的樣子。即保留已經 cherry-pick 成功的 commit，並退出 cherry-pick 流程。

給定一個或多個現有提交，恢復相關提交引入的更改，並記錄一些這些更改的新提交。這就要求你的工作樹是干凈的（沒有來自頭部的修改）。

將現有的提交還原，恢復提交的內容，並生成一條還原記錄。

應用場景：有一天測試突然跟你說，你開發上線的功能有問題，需要馬上撤回，否則會影響到系統使用。這時可能會想到用 reset 回退，可是你看了看分支上最新的提交還有其他同事的代碼，用 reset 會把這部分代碼也撤回了。由於情況緊急，又想不到好方法，還是任性的使用 reset，然後再讓同事把他的代碼合一遍（同事聽到想打人），於是你的技術形象在同事眼裡一落千丈。

revert 普通提交

學會 revert 之後，立馬就可以拯救這種尷尬的情況。

現在 master 記錄如下：

revert 掉自己提交的 commit。

因為 revert 會生成一條新的提交記錄，這時會讓你編輯提交信息，編輯完後 :wq 保存退出就好了。

再來看下最新的 log，生成了一條 revert 記錄，雖然自己之前的提交記錄還是會保留著，但你修改的代碼內容已經被撤回了。

在 git 的 commit 記錄里，還有一種類型是合並提交，想要 revert 合並提交，使用上會有些不一樣。

現在的 master 分支里多了條合並提交。

使用剛剛同樣的 revert 方法，會發現命令行報錯了。為什麼會這樣？在官方文檔中有解釋。

通常無法 revert 合並，因為您不知道合並的哪一側應被視為主線。此選項指定主線的父編號（從1開始），並允許 revert 反轉相對於指定父編號的更改

我的理解是因為合並提交是兩條分支的交集節點，而 git 不知道需要撤銷的哪一條分支，需要添加參數 -m 指定主線分支，保留主線分支的代碼，另一條則被撤銷。

-m 後面要跟一個 parent number 標識出"主線"，一般使用 1 保留主分支代碼。

還是上面的場景，在 master 分支 revert 合並提交後，然後切到 feature 分支修復好 bug，再合並到 master 分支時，會發現之前被 revert 的修改內容沒有重新合並進來。

因為使用 revert 後， feature 分支的 commit 還是會保留在 master 分支的記錄中，當你再次合並進去時，git 判斷有相同的 commitHash，就忽略了相關 commit 修改的內容。

這時就需要 revert 掉之前 revert 的合並提交，有點拗口，接下來看操作吧。

現在 master 的記錄是這樣的。

再次使用 revert，之前被 revert 的修改內容就又回來了。

此命令管理重錄中記錄的信息。

如果說 reset --soft 是後悔葯，那 reflog 就是強力後悔葯。它記錄了所有的 commit 操作記錄，便於錯誤操作後找回記錄。

應用場景：某天你眼花，發現自己在其他人分支提交了代碼還推到遠程分支，這時因為分支只有你的最新提交，就想著使用 reset --hard ，結果緊張不小心記錯了 commitHash，reset 過頭，把同事的 commit 搞沒了。沒辦法， reset --hard 是強制回退的，找不到 commitHash 了，只能讓同事從本地分支再推一次（同事瞬間拳頭就硬了，怎麼又是你）。於是，你的技術形象又一落千丈。

分支記錄如上，想要 reset 到 b。

誤操作 reset 過頭，b 沒了，最新的只剩下 a。

這時用 git reflog 查看 歷史 記錄，把錯誤提交的那次 commitHash 記下。

再次 reset 回去，就會發現 b 回來了。

對我這種喜歡敲命令而不用圖形化工具的愛好者來說，設置短命令可以很好的提高效率。下面介紹兩種設置短命令的方式。

打開全局配置文件

寫入內容

本文主要分享了5個在開發中實用的 Git 命令和設置短命令的方式。

文中列舉的應用場景有部分不太恰當，只是想便於同學們理解，最重要的是要理解命令的作用是什麼，活學活用才能發揮最大功效。

好啦，今天的分享就到這兒啦，我們下次見啦~

⑥ 華為軟體開發雲#如何使用Git的常用命令

常用命令Git常用命令如表1所示。

⑦ 如何在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 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 來進行。

(8)git編譯命令擴展閱讀

COMMIT（操作指令）

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

用途

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

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

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

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

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

參考資料

COMMIT-網路

⑨ 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上創建一個開源項目，敬請期待