經過 41 個問答方式快速瞭解學習 Git

時間 2019-11-05

標籤經過問答方式快速瞭解學習 git 欄目 Git 简体版

原文原文鏈接

做者：Duomly
譯者：前端小智
來源：dev.to

阿里雲服務器很便宜火爆，今年比去年便宜，10.24~11.11購買是1年86元，3年229元，能夠點擊下面連接進行參與：
https://www.aliyun.com/1111/2...html

爲了保證的可讀性，本文采用意譯而非直譯。前端

1. 你最喜歡的 Git 命令是什麼

我的比較喜歡 git add -p. 這增長了「補丁模式」的變化，這是一個內置的命令行程序。它遍歷了每一個更改，並要求確認是否要執行它們。git

這個命令迫使我們放慢速度並檢查更改文件。做爲開發人員，我們有時經常急於提交，我本身也常常這樣，作完運行 git add . 才發現把調試的代碼也提交上去了。github

2. 爲何你更喜歡直接使用 git 命令

做爲開發人員，我們也常用其它命令來作其它事情，也不差用 git 的命令來作事。npm

此外，git 命令也是很是短的，很是容易學習，而且使用命令能夠了解 git 的工做流程，這樣也間接改進了開發工做流程。segmentfault

3. 如何使用 `stage` 命令

stage是add .的內置別名。瀏覽器

4.如何在分支中保存更改並 `checkout` 到其餘分支

所以，可使用 git stash 臨時存儲更改或提交 WIP,目的是要有未修改前的環境。就我我的而言，我更喜歡使用 WIP 提交而不是 stash，由於它們更容易引用和共享。服務器

WIP = Work in Progress微信

研發中的代碼想存儲起來，可是又避免研發中的代碼被合併，開發就會建立一個WIP的分支app

WIP MR

WIP MR 含義是在工做過程當中的合併請求，是一個咱們在 GitLab 中避免 MR 在準備就緒前被合併的技術。只須要添加 WIP: 在 MR 的標題開頭，它將不會被合併，除非你把 WIP: 刪除。

5.何時使用 git stash

發現有一個類是多餘的，想刪掉它又擔憂之後須要查看它的代碼，想保存它但又不想增長一個髒的提交。這時就能夠考慮 git stash。

6.如何使用 git 命令

對任何命令使用 --help選項，例如，git stash --help。

7. 什麼是「 git flow」？

Git Flow 定義了一個項目發佈的分支模型，爲管理具備預約發佈週期的大型項目提供了一個健壯的框架，是由 Vincent Driessen 提出的一個 git 操做流程標準、解決當分支過多時 , 如何有效快速管理這些分支。

8.什麼是 GitHub flow ？

GitHub flow，顧名思義，就是 GitHub 所推崇的 Workflow。（千萬不要理解成 GitHub 上才能用的 Workflow）, 基本上，GitHub Flow 是master/feature分支工做流程的品牌名稱。

GitHub flow 的核心優點在於其流程帶來的自動化可能性，可以作到其它流程沒法實現的檢查過程，並極大簡化開發團隊的體力勞動，真正發揮自身的價值。

9.你更喜歡哪一種分支策略?

大多數 Git項目都是「Git flow」。這些項目中只有少數須要這種策略，一般是由於它是版本化的軟件。

master/feature 分支策略更易於管理，尤爲是在剛入門時，若是須要，切換到「git flow」很是容易。

10. git open 命令是作啥用的

這是一個單獨的命令，能夠做爲 npm 包使用。

11.當在其餘分支中添加的文件仍然在工做分支中顯示爲未跟蹤或修改時，如何重置分支

這一般是「工做索引」不乾淨時切換分支的結果。

在 git 中沒有內置的方法來糾正這一點。一般經過確保提示符有一個「status」指示符並在每次更改分支時運行諸如 git status 之類的命令來避免這種狀況。這些習慣會讓我們儘早發現這些問題，這樣就能夠在新的分支上 stash 或 commit 這些更改。

12. 如何重命名分支?

git branch -m current-branch-name new-branch-name

13. 如何使用 cherry-pick

git cherry-pick [reference] 請記住，這是一個從新應用的命令，所以它將更改提交 SHA。

14. 若是從一個分支恢復(例如 `HEAD~3`)，是否能夠再次返回到 `HEAD`(好比恢復上一次更新)

在這種狀況下，經過運行 git reset --hard HEAD~1 當即撤消還原提交（即 HEAD 提交）。

15. 何時使用 `git pull` 和 `git fetch`？

git pull將下載提交到當前分支。記住，git pull其實是 fetch 和 merge 命令的組合。

git fetch將從遠程獲取最新的引用。

一個很好的類比是播客播放器或電子郵件客戶端。我們可能會檢索最新的播客或電子郵件(fetch)，但實際上還沒有在本地下載播客或電子郵件附件(pull)。

16. 爲何有時須要使用 `--force` 來強制提交更改

rebase 是一個能夠從新提交的命令，它改變了 SHA1 hash。若是是這樣，本地提交歷史將再也不與其遠程分支保持一致。

當這種狀況發生時，push 會被拒絕。只有在被拒絕時，才應該考慮使用 git push --force。這樣作將用本地提交歷史覆蓋遠程提交歷史。因此能夠回過頭來想一想，想一想爲何要使用 --force。

17. 可使用分支合併多個分支，而後將該分支發送給 `master` 嗎？

固然能夠，在大多數 git 工做流下，分支一般會累積來自多個其餘分支的更改,最終這些分支會被合併到主分支。

18. 應該從一個很是老的分支作一個 `rebase` 嗎？

除非是無可奈何。

根據你的工做流，能夠將舊的分支合併到主分支中。

若是你須要一個最新的分支，我更喜歡 rebase。它只提供更改且更清晰的歷史記錄，而不是來自其餘分支或合併的提交。

然而，儘管老是可能的，可是使用 rebase 多是一個痛苦的過程，由於每次提交都要從新應用。這可能會致使多重衝突。若是是這樣，我一般使用rebase --abort 並使用 merge 來一次性解決全部衝突。

19. 使用 `rebase -i` 時，`squash` 和 `fixup` 有什麼區別

squash 和 fixup 結合兩個提交。squash 暫停 rebase 進程，並容許我們調整提交的消息。fixup 自動使用來自第一次提交的消息。

20. 一般，當使用 `master` 從新創建功能分支時，對於每次提交都須要解決衝突？

是的。因爲每次提交的更改都會在 rebase 期間從新應用，因此必須在衝突發生時解決它們。

這意味着在提交以前就已經有了提交衝突，若是沒有正確地解決它，那麼下面的許多提交也可能發生衝突。爲了限制這一點，我常用 rebase -i 來壓縮提交歷史記錄，以便更輕鬆地使用它。

若是許多提交之間仍然存在衝突，可使用 merge。

21.在與 master 合併以前，有必要更新個人分支嗎

根據你的工做流，能夠將舊的分支合併到主分支中。若是你的工做流僅使用 "fast-forward"合併，那麼有必要在合併以前更新你的分支。

Git fast forward 提交

多人協同開發，使用 Git 常常會看到警告信息包含術語：fast forward, 這是何義？

簡單來講就是提交到遠程中心倉庫的代碼必須是按照時間順序的。

好比 A 從中心倉庫拿到代碼後，對文件 f 進行了修改。而後 push 到中心倉庫。

B 在 A 以前就拿到了中心倉庫的代碼，在 A push 成功以後也對 f 文件進行了修改。這個時候 B 也運行 push 命令推送代碼。

會收到一個相似下面的信息：

chenshu@sloop2:~/work/189/appengine$ git pushTo 
ssh://csfreebird@10.112.18.189:29418/appengine.git ! [rejected]       
master -> master (non-fast-forward)error: failed to push some refs to 
'ssh://csfreebird@10.112.18.189:29418/appengine.git'To prevent you from losing 
history, non-fast-forward updates were rejectedMerge the remote changes (e.g. 'git 
pull') before pushing again.  See the'Note about fast-forwards' section of 'git push --help' for details.

提醒你非快進方式的更新被拒絕了，須要先從中心倉庫pull到最新版本，merge後再 push.

fast forward 可以保證不會強制覆蓋別人的代碼，確保了多人協同開發。儘可能不要使用 non fast forward方法提交代碼。

22. 須要使用 GitKraken 這種可視化工具嗎

我比較喜歡用命令方式使用 git，由於這使我可以徹底控制管理變動，就像使用命令來改進個人開發過程同樣。

固然，某些可視化操做(如管理分支和查看文件差別)在GUI中老是更好。我我的認爲在合併過程當中在瀏覽器中查看這些內容就足夠了。

23. 當提交已經被推送時，能夠作一個 `--amend` 修改嗎？

能夠，git commit –amend 既能夠對上次提交的內容進行修改，也能夠修改提交說明。

24.在作迭代內容時，當完成一個小功能須要先拉一個 `pull request` 請求，仍是都作完這個迭代內容後在拉一個 `pull request` 請求

我們一般作法是，完成一個迭代的內容後在拉一個 pull request。然而，若是你某個任務上花了很長時間，先合併作的功能多是有益的。這樣作能夠防止對分支的依賴或過期，因此作完一個拉一個請求，仍是所有作完在拉一個請求，這決於你正在進行的更改的類型。

25. 在將分支合併到 `master` 以前，須要先建立一個 `release` 分支嗎？

這在很大程度上取決於大家公司的部署過程。建立 release 分支對於將多個分支的工做分組在一塊兒並將它們合併到主分支以前進行總體測試是有益的。

因爲源分支保持獨立和未合併，因此在最後的合併中擁有更大的靈活性。

26. 如何從 master 獲取一些提交?比方說，我不想執行最後一次提交，而是進行一次 `rebase`。

假設 master 分支是我們的主分支，我們不但願有選擇地從它的歷史記錄中提取提交，這會之後引發衝突。

我們想要 merge 或 rebase 分支的全部更改。要從主分支以外的分支提取選擇提交，可使用 git cherry-pick。

27. 如何在 git 終端配置顏色

默認狀況下git 是黑白的。

git config --global color.status auto 
git config --global color.diff auto 
git config --global color.branch auto 
git config --global color.interactive auto

配置以後，就有顏色了。

28. 有沒有更好的命令來替代 git push -force ?

實際上，沒有其餘方法能夠替代 git push—force。雖然這樣，若是正確地使用 merge 或 rebase 更新分支，則無需使用 git push --force。

只有當你運行了更改本地提交歷史的命令時，才應該使用 git push --force。

29. 當我在 `git rebase -` 選擇`drop`時，是否刪除了與該提交相關的代碼？

是的。要恢復這段代碼，須要在 reflog 的 rebase 以前找到一個狀態。

30. 如何自動跟蹤遠程分支

一般，當你 checkout 或建立分支時，Git 會自動設置分支跟蹤。

若是沒有，則能夠在下一次使用如下命令進行更新時：git push -u remote-name branch-name。

或者可使用如下命令顯式設置它：git branch --set-upstream-to = remote-name / branch-name

31. 在 `rebase` 分支以前更新分支，是一個好的習慣嗎？

我認爲是這樣的，緣由很簡單，用git rebase -i 組織或壓縮提交，首先在更新過程當中提供更多的上下文。

32. 有沒有一種方法能夠將提交拆分爲更多的提交（與 `fixup/squash` 相反）？

能夠在rebase -i過程當中使用 exec 命令來嘗試修改工做索引並拆分更改。還可使用 git reset 來撤消最近的提交，並將它們的更改放入工做索引中，而後將它們的更改分離到新的提交中。

33.有沒有辦法查看已修復的提交？

git log

查看日誌，找到對應的修改記錄，可是這種查找只能看到文件，而不是文件的內容。

git blame 文件名

查看這個文件的修改記錄，默認顯示整個文件，也能夠經過參數 -L <start>,<end>來檢查須要修改的某幾行。

若是查看以前提交的內容可使用 git show commitId。

34. rebase --skip 做用是啥？

我們知道 rebase 的過程首先會產生 rebase 分支（master）的備份，放到（no branch ）臨時分支中。再將支線分支（branch）的每一次提交修改，以補丁的形式，一個個的從新應用到主幹分支上。這個過程是一個循環應用補丁的過程，期間只要補丁產生衝突，就會中止循環，等待手動解決衝突。這個衝突指的是上一個合併後版本與補丁之間的衝突。

git rebase --skip 命令，能夠跳過某一次補丁（存在上一輪衝突的解決方案中，已經包含了這一輪的補丁內容，這樣會使補丁無效，須要跳過），這個命令慎用。

35. 如何刪除遠程分支？

可使用:git push origin:branch-name-to-remove 或使用 -d選項:git push -d origin someother -branch-2 來刪除遠程分支。

要刪除對遠程分支的本地引用，能夠運行:git remote prune origin。

36. `checkout` 和 `reset` 有什麼區別

這兩個命令均可以用來撤銷更改。checkout 可能更健壯，由於它不只容許撤消當前更改，並且還容許經過檢索文件的舊版本撤消一組更改。

默認狀況下，reset更適合於更改工做索引中更改的狀態。所以，它實際上只處理當前的變化。

git checkout -- file；撤銷對工做區修改；這個命令是以最新的存儲時間節點（add和commit）爲參照，覆蓋工做區對應文件file；這個命令改變的是工做區。

git reset HEAD -- file；清空 add 命令向暫存區提交的關於 file 文件的修改（Ustage）；這個命令僅改變暫存區，並不改變工做區，這意味着在無任何其餘操做的狀況下，工做區中的實際文件同該命令運行以前無任何變化

37. 在正常的工做流程中應該避免使用哪些命令

一些可能會破壞歷史記錄的內容，例如：

git push origin master -f (千萬不要這樣作)
git revert
git cherry-pick (changes from master)

在正常的工做流程下，儘可能避免直接使用git merge，由於這一般是經過拉請求(pull requests)構建到流程中的。

38. 若是我有一個分支(B)指向另外一個分支(A)，而我又有另外一個分支(C)，它須要(A)和(B)及 mast 分支的代碼，怎麼個流程才能更新(C)？

這取決於幾件事：

若是 A 和 B 能夠合併到 master，剛能夠將 A 和 B 合併到 master 中，而後用master的更新 C。

若是 A 和 B 不能合併到 master，能夠簡單地將 B 合併到 C 中，由於 B 已經包含了 A 的變動。

在極端的狀況下，能夠將 A、B 和 master 合併到 C 中。然而，爲了不衝突，合併的順序可能很重要。

39. 你使用的別名有哪些

我經常使用的一些 git 別名以下：

alias.unstage reset HEAD --
alias.append commit --amend --no-edit
alias.wip commit -m "WIP"
alias.logo log --oneline
alias.lola log --graph --oneline --decorate --all