目錄

列舉作業中常用的幾個git命令？

提交時發生沖突，你能解釋沖突是如何產生的嗎？你是如何解決的？

如果本次提交誤操作，如何撤銷？

如果我想修改提交的歷史資訊，應該用什么命令？

git的4個區域及轉換

你使用過git stash命令嗎？你一般什么情況下會使用它？

git add和git statsh的區別

git add . 和 git add * 區別

git add和git commit的區別

如何查看分支提交的歷史記錄？查看某個檔案的歷史記錄呢？

git reset、git revert 和 git checkout 有什么區別

能不能說一下git fetch和git pull命令之間的區別？

使用過git merge和git rebase嗎？它們之間有什么區別？

能說一下git系統中HEAD、作業樹和索引之間的區別嗎？

GitFlow作業流程分支有哪些

GitFlow主要作業流程

使用過git cherry-pick，有什么作用？

git跟其他版本控制器有啥區別？

我們在本地工程常會修改一些組態檔，這些檔案不需要被提交，而我們又不想每次執行git status時都讓這些檔案顯示出來，我們該如何操作？

如何把本地倉庫的內容推向一個空的遠程倉庫？

如果代碼出現bug,你們是如何解決的?

git rebase的作用?

如何做代碼的review？

列舉作業中常用的幾個git命令？

遠程倉庫中clone代碼到本地：git clone https://github.com/MatchlessHeroVIP/ssmtest.git

新增檔案的命令：git add file或者git add .

提交檔案的命令：git commit –m或者git commit –a

本地倉庫提交到遠程倉庫：git push

查看作業區狀況：git status –s

拉取合并遠程分支的操作：git fetch/git merge或者git pull

查看提交記錄命令：git reflog

切換到主分支： git checkout master

提交時發生沖突，你能解釋沖突是如何產生的嗎？你是如何解決的？

開發程序中，我們都有自己的特性分支，所以沖突發生的并不多，但也碰到過，諸如公共類的公共方法，我和別人同時修改同一個檔案，他提交后我再提交就會報沖突的錯誤，

發生沖突，在IDE里面一般都是對比本地檔案和遠程分支的檔案，然后把遠程分支上檔案的內容手工修改到本地檔案，然后再提交沖突的檔案使其保證與遠程分支的檔案一致，這樣才會消除沖突，然后再提交自己修改的部分，特別要注意下，修改本地沖突檔案使其與遠程倉庫的檔案保持一致后，需要提交后才能消除沖突，否則無法繼續提交，必要時可與同事交流，消除沖突，

發生沖突，也可以使用命令，

通過git stash命令，把作業區的修改提交到堆疊區，目的是保存作業區的修改；

通過git pull命令，拉取遠程分支上的代碼并合并到本地分支，目的是消除沖突；

通過git stash pop命令，把保存在堆疊區的修改部分合并到最新的作業空間中；

如果本次提交誤操作，如何撤銷？

如果想撤銷提交到索引區的檔案，可以通過git reset HEAD file；如果想撤銷提交到本地倉庫的檔案，可以通過git reset –soft HEAD^n恢復當前分支的版本庫至上一次提交的狀態，索引區和作業空間不變更；可以通過git reset –mixed HEAD^n恢復當前分支的版本庫和索引區至上一次提交的狀態，作業區不變更；可以通過git reset –hard HEAD^n恢復當前分支的版本庫、索引區和作業空間至上一次提交的狀態，

如果我想修改提交的歷史資訊，應該用什么命令？

如果修改最近一次提交的歷史記錄，就可以用git commit –amend命令；vim編輯的方式；

如果修改之前提交的歷史記錄，就需要按照下面的步驟：

第一步：首先查看前三次的提交歷史記錄：

$ git log -3
commit a762fcafecbd92bbde088054644e1b0586589c4b (HEAD -> slave)
Author: 18073638 <18073638@cnsuning.com>
Date:   Sat Mar 30 10:58:44 2019 +0800

four commit

commit eedbc93d58780f63dd47f8388f8217892096e89a
Author: 18073638 <18073638@cnsuning.com>
Date:   Thu Mar 28 17:19:52 2019 +0800

third commit third commit

commit 05396135eba85140602107e01e5c211d74f6c739
Author: 18073638 <18073638@cnsuning.com>
Date:   Thu Mar 28 16:56:19 2019 +0800

second commit

注意：這里我們想把053961的committer物件資訊修改為“second commit second commit”.

第二步：執行命令git rebase –i HEAD~3，會把前3次的提交記錄按照倒敘列出來；

pick 0539613 second commit
pick eedbc93 third commit third commit
pick a762fca four commit

# Rebase c8d7ad7..a762fca onto c8d7ad7 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

這里把第一行的‘pick’修改為‘edit’，然后esc + :wq退出vim編輯器；

$ git rebase -i HEAD~3
Stopped at 0539613...  second commit
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

第三步：根據提示，執行git commit –amend命令，進入vim編輯器并修改提交資訊，

$ git commit --amend
[detached HEAD 20fe643] second commit second commit
 Date: Thu Mar 28 16:56:19 2019 +0800
 1 file changed, 1 insertion(+)

第四步：然后執行git rebase –continue命令

$ git rebase --continue
Successfully rebased and updated refs/heads/slave.

查看修改結果

$ git log -3
commit 9024049ef990e79fa61295d5c2b64d70017cf412 (HEAD -> slave)
Author: 18073638 <18073638@cnsuning.com>
Date:   Sat Mar 30 10:58:44 2019 +0800

    four commit

commit 79cb4e26dd300591e6352d0488802f43b65c8ba2
Author: 18073638 <18073638@cnsuning.com>
Date:   Thu Mar 28 17:19:52 2019 +0800

    third commit third commit

commit 20fe643cbf80cdcc649d732065e8ebf4caf773c7
Author: 18073638 <18073638@cnsuning.com>
Date:   Thu Mar 28 16:56:19 2019 +0800

    second commit second commit

修改成功，

git的4個區域及轉換

Git本地有三個作業區域：作業目錄（Working Directory）、暫存區(Stage/Index)、資源庫(Repository或Git Directory)，如果在加上遠程的git倉庫(Remote Directory)就可以分為四個作業區域，檔案在這四個區域之間的轉換關系如下：

Workspace：作業區，就是你平時存放專案代碼的地方;

Index / Stage：暫存區，用于臨時存放你的改動，事實上它只是一個檔案，保存即將提交到檔案串列資訊,一般存放在 .git 目錄下的 index 檔案（.git/index）中，所以我們把暫存區有時也叫作索引（index）;

Repository：倉庫區（或本地倉庫），就是安全存放資料的位置，這里面有你提交到所有版本的資料，其中HEAD指向最新放入倉庫的版本;

Remote：遠程倉庫，托管代碼的服務器，可以簡單的認為是你專案組中的一臺電腦用于遠程資料交換;

本地的三個區域確切的說應該是git倉庫中HEAD指向的版本：

Directory：使用Git管理的一個目錄，也就是一個倉庫，包含我們的作業空間和Git的管理空間，

WorkSpace：需要通過Git進行版本控制的目錄和檔案，這些目錄和檔案組成了作業空間，

.git：存放Git管理資訊的目錄，初始化倉庫的時候自動創建，

Index/Stage：暫存區，或者叫待提交更新區，在提交進入repo之前，我們可以把所有的更新放在暫存區，

Local Repo：本地倉庫，一個存放在本地的版本庫；HEAD會只是當前的開發分支（branch），

你使用過git stash命令嗎？你一般什么情況下會使用它？

命令git stash是把作業區修改的內容存盤在堆疊區，

以下幾種情況會使用到它：

解決沖突檔案時，會先執行git stash，然后解決沖突；

遇到緊急開發任務但目前任務不能提交時，會先執行git stash，然后進行緊急任務的開發，然后通過git stash pop取出堆疊區的內容繼續開發；

切換分支時，當前作業空間內容不能提交時，會先執行git stash再進行分支切換；

git add和git statsh的區別

在回答這個問題之前需要先了解 git 倉庫的三個組成部分：作業區（Working Directory）、暫存區（Stage）和歷史記錄區（History）：

作業區：在 git 管理下的正常目錄都算是作業區，我們平時的編輯作業都是在作業區完成，

暫存區：臨時區域，里面存放將要提交檔案的快照，

歷史記錄區：git commit 后的記錄區，

然后是這三個區的轉換關系以及轉換所使用的命令：

然后我們就可以來說一下 git add 和 git stage 了，其實，他們兩是同義的，所以，驚不驚喜，意不意外？這個問題竟然是個陷阱…

引入 git stage 的原因其實比較有趣：

是因為要跟 svn add 區分，兩者的功能是完全不一樣的，svn add 是將某個檔案加入版本控制，而 git add 則是把某個檔案加入暫存區，因為在 git 出來之前大家用 svn 比較多，所以為了避免誤導，git 引入了git stage，然后把 git diff –staged 做為 git diff –cached 的相同命令，基于這個原因，我們建議使用 git stage 以及 git diff –staged，

git add . 和 git add * 區別

git add . 會把本地所有untrack的檔案都加入暫存區，并且會根據.gitignore做過濾，但是git add * 會提示已被忽略的內容，但不會直接加入

git add和git commit的區別

要想弄明白git add和git commit的區別，首先我們需要知道三個概念：作業區(Working Directory)、版本庫(Repository)、暫存區(Stage or index)，

作業區

當你在開發一個專案時，主目錄就是你的作業區，

版本庫

作業區中有一個隱藏目錄.git，這個就是git的版本庫了，

暫存區

Git的版本庫里存了很多檔案，其中包括稱為Stage或index的暫存區，還有一個git為我們自動創建的第一個分支master，以及指向master的一個指標HEAD，
下面就是三個區的示意圖：圖片來著廖雪峰老師的 博客，

三個區的示意圖三個區的示意圖

git add和git commit的區別就在于：

git add把檔案添加進去，實際上就是把檔案修改添加到暫存區；

git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支，

因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，git commit就是往master分支上提交更改，

你可以簡單理解為，需要提交的檔案修改通通放到暫存區，然后，一次性提交暫存區的所有修改，

所以要想將修改提交到master中一定要先git add到暫存區中，再git commit到master分支，

如何查看分支提交的歷史記錄？查看某個檔案的歷史記錄呢？

查看分支的提交歷史記錄：

命令git log –number：表示查看當前分支前number個詳細的提交歷史記錄；

命令git log –number –pretty=oneline：在上個命令的基礎上進行簡化，只顯示sha-1碼和提交資訊；

命令git reflog –number: 表示查看所有分支前number個簡化的提交歷史記錄；

命令git reflog –number –pretty=oneline：顯示簡化的資訊歷史資訊；

如果要查看某檔案的提交歷史記錄，直接在上面命令后面加上檔案名即可，

注意：如果沒有number則顯示全部提交次數，

git reset、git revert 和 git checkout 有什么區別

這個問題同樣也需要先了解 git 倉庫的三個組成部分：作業區（Working Directory）、暫存區（Stage）和歷史記錄區（History），

首先是它們的共同點：用來撤銷代碼倉庫中的某些更改，

然后是不同點：

首先，從 commit 層面來說：

git reset 可以將一個分支的末端指向之前的一個 commit，然后再下次 git 執行垃圾回收的時候，會把這個 commit 之后的 commit 都扔掉，git reset 還支持三種標記，用來標記 reset 指令影響的范圍：

–mixed：會影響到暫存區和歷史記錄區，也是默認選項；
–soft：只影響歷史記錄區；
–hard：影響作業區、暫存區和歷史記錄區，

注意：因為 git reset 是直接洗掉 commit 記錄，從而會影響到其他開發人員的分支，所以不要在公共分支（比如 develop）做這個操作，

git checkout 可以將 HEAD 移到一個新的分支，并更新作業目錄，因為可能會覆寫本地的修改，所以執行這個指令之前，你需要 stash 或者 commit 暫存區和作業區的更改，

git revert 和 git reset 的目的是一樣的，但是做法不同，它會以創建新的 commit 的方式來撤銷 commit，這樣能保留之前的 commit 歷史，比較安全，另外，同樣因為可能會覆寫本地的修改，所以執行這個指令之前，你需要 stash 或者 commit 暫存區和作業區的更改，

然后，從檔案層面來說：

git reset 只是把檔案從歷史記錄區拿到暫存區，不影響作業區的內容，而且不支持 –mixed、–soft 和 –hard，

git checkout 則是把檔案從歷史記錄拿到作業區，不影響暫存區的內容，

git revert 不支持檔案層面的操作，

回答關鍵點：

對于 commit 層面和檔案層面，這三個指令本身功能差別很大，

git revert 不支持檔案層面的操作，

不要在公共分支做 git reset 操作，

能不能說一下git fetch和git pull命令之間的區別？

git pull 命令從中央存盤庫中提取特定分支的新更改或提交，并更新本地存盤庫中的目標分支，

git fetch 也用于相同的目的，但它的作業方式略有不同，當你執行 git fetch 時，它會從所需的分支中提取所有新提交，并將其存盤在本地存盤庫中的新分支中，如果要在目標分支中反映這些更改，必須在 git fetch 之后執行git merge，只有在對目標分支和獲取的分支進行合并后才會更新目標分支，

為了方便起見，請記住以下等式：

git pull = git fetch + git merge

使用過git merge和git rebase嗎？它們之間有什么區別？

簡單的說，git merge和git rebase都是合并分支的命令，

git merge branch會把branch分支的差異內容pull到本地，然后與本地分支的內容一并形成一個committer物件提交到主分支上，合并后的分支與主分支一致；

git rebase branch會把branch分支優先合并到主分支，然后把本地分支的commit放到主分支后面，合并后的分支就好像從合并后主分支又拉了一個分支一樣，本地分支本身不會保留提交歷史，

能說一下git系統中HEAD、作業樹和索引之間的區別嗎？

HEAD檔案包含當前分支的參考（指標）；

作業樹是把當前分支檢出到作業空間后形成的目錄樹，一般的開發作業都會基于作業樹進行；

索引index檔案是對作業樹進行代碼修改后，通過add命令更新索引檔案；GIT系統通過索引index檔案生成tree物件；

GitFlow作業流程分支有哪些

GitFlow可以用來管理分支，GitFlow作業流中常用的分支有下面幾類：

master分支：最為穩定功能比較完整的隨時可發布的代碼，即代碼開發完成，經過測驗，沒有明顯的bug，才能合并到 master 中，請注意永遠不要在 master 分支上直接開發和提交代碼，以確保 master 上的代碼一直可用；

develop分支；用作平時開發的主分支，并一直存在，永遠是功能最新最全的分支，包含所有要發布 到下一個 release 的代碼，主要用于合并其他分支，比如 feature 分支； 如果修改代碼，新建 feature 分支修改完再合并到 develop 分支，所有的 feature、release 分支都是從 develop 分支上拉的，

feature分支；這個分支主要是用來開發新的功能，一旦開發完成，通過測驗沒問題（這個測驗，測驗新功能沒問題），我們合并回develop 分支進入下一個 release

release分支；用于發布準備的專門分支，當開發進行到一定程度，或者說快到了既定的發布日，可以發布時，建立一個 release 分支并指定版本號(可以在 finish 的時候添加)，開發人員可以對 release 分支上的代碼進行集中測驗和修改bug，（這個測驗，測驗新功能與已有的功能是否有沖突，兼容性）全部完成經過測驗沒有問題后，將 release 分支上的代碼合并到 master 分支和 develop 分支

hotfix分支；用于修復線上代碼的bug，**從 master 分支上拉，**完成 hotfix 后，打上 tag 我們合并回 master 和 develop 分支，

GitFlow主要作業流程

1.初始化專案為gitflow , 默認創建master分支 , 然后從master拉取第一個develop分支

2.從develop拉取feature分支進行編碼開發(多個開發人員拉取多個feature同時進行并行開發 , 互不影響)

3.feature分支完成后 , 合并到develop(不推送 , feature功能完成還未提測 , 推送后會影響其他功能分支的開發)；合并feature到develop , 可以選擇洗掉當前feature , 也可以不洗掉，但當前feature就不可更改了，必須從release分支繼續編碼修改

4.從develop拉取release分支進行提測 , 提測程序中在release分支上修改BUG

5.release分支上線后 , 合并release分支到develop/master并推送；合并之后，可選洗掉當前release分支，若不洗掉，則當前release不可修改，線上有問題也必須從master拉取hotfix分支進行修改；

6.上線之后若發現線上BUG , 從master拉取hotfix進行BUG修改；

7.hotfix通過測驗上線后，合并hotfix分支到develop/master并推送；合并之后，可選洗掉當前hotfix ，若不洗掉，則當前hotfix不可修改，若補丁未修復，需要從master拉取新的hotfix繼續修改；

8.當進行一個feature時 , 若develop分支有變動 , 如其他開發人員完成功能并上線 , 則需要將完成的功能合并到自己分支上，即合并develop到當前feature分支；

9.當進行一個release分支時 , 若develop分支有變動 , 如其他開發人員完成功能并上線 , 則需要將完成的功能合并到自己分支上，即合并develop到當前release分支 (!!! 因為當前release分支通過測驗后會發布到線上 , 如果不合并最新的develop分支 , 就會發生丟代碼的情況)；

GitFlow的好處

GitFlow為不同的分支分配一個明確的角色，并定義分支之間如何互動以及什么時間互動；可以幫助大型專案理清分支之間的關系，簡化分支的復雜度，

使用過git cherry-pick，有什么作用？

命令git cherry-pick可以把branch A的commit復制到branch B上，

在branch B上進行命令操作：

復制單個提交：git cherry-pick commitId

復制多個提交：git cherry-pick commitId1…commitId3

注意：復制多個提交的命令不包含commitId1.

git跟其他版本控制器有啥區別？

GIT是分布式版本控制系統，其他類似于SVN是集中式版本控制系統，

分布式區別于集中式在于：每個節點的地位都是平等，擁有自己的版本庫，在沒有網路的情況下，對作業空間內代碼的修改可以提交到本地倉庫，此時的本地倉庫相當于集中式的遠程倉庫，可以基于本地倉庫進行提交、撤銷等常規操作，從而方便日常開發，

我們在本地工程常會修改一些組態檔，這些檔案不需要被提交，而我們又不想每次執行git status時都讓這些檔案顯示出來，我們該如何操作？

首先利用命令touch .gitignore新建檔案

$ touch .gitignore
然后往檔案中添加需要忽略哪些檔案夾下的什么型別的檔案

$ vim .gitignore
$ cat .gitignore
/target/class
.settings
.imp
*.ini

注意：忽略/target/class檔案夾下所有后綴名為.settings，.imp的檔案，忽略所有后綴名為.ini的檔案，

如何把本地倉庫的內容推向一個空的遠程倉庫？

首先確保本地倉庫與遠程之間是連同的，如果提交失敗，則需要進行下面的命令進行連通：

git remote add origin XXXX

注意：XXXX是你的遠程倉庫地址，

如果是第一次推送，則進行下面命令：

git push -u origin master

注意：-u 是指定origin為默認主分支

之后的提交，只需要下面的命令：

git push origin master

如果代碼出現bug,你們是如何解決的?

創建一個bug分支,然后進行bug處理,處理完畢后,合并到review分支,組長review成功后才能夠合并到master

合并完成之后洗掉bug分支

回到dev分支繼續開發，

git rebase的作用?

場景：在公司開發忘記提交到github托管，在家里又繼續開發新的功能，

然后到公司昨天的代碼跟你的新功能合并的時候可以用git fecth ---> git rebase

那么他的提交記錄就不會出現分叉,保持了提交記錄的整潔.

如何做代碼的review？

創建review分支,然后再創建自己的個人分支,當你完成自己的業務邏輯的時候,

再合并到review分支.給組長做代碼的review