gitmerge指定文件夾

❶ git合並分支時禁止合並特定文件

1.在日常開發過程中經常會遇到多環境，但是環境文件不同的情況，導致每次切換git環境時候非常麻煩，可能會提交上來不需要提交的文件，一個文件來回提交修改。

1. Git 多分支 配置文件不同 忽略特定的文件

1.定義策略 ours：

在git 根目錄執行命令行：

git config --global merge.ours.driver true

2.git根目錄新建 文件 .gitattributes 在需要忽略的文件名稱後面 + merge=ours 且一個文件一行

❷ Git 指令，看這個就夠了，趕緊收藏，方便查閱

1.初始化Git本地倉庫:

git init

2.Git添加遠程倉庫:

git remote add origin 你的遠程倉庫地址>

3.Git 克隆遠程倉庫:

git clone 需要克隆的遠程倉庫地址>

4.添加文件到Git倉庫:

git add 需要添加的文件>

或:

git add . (PS:"add ." 表示把當前路徑下的所有文件都添加到Git倉庫)

5.把文件提交到Git倉庫(PS:提交之前,需要先添加):

git commit -m"你的提交說明>"

6.把本地提交的文件推送到遠程倉庫:

git push -u origin 你的分支>

如果之前提交有時間使用 "-u",則可以使用:

git push

7.查看所有分支:

git branch

PS:如下表示有兩個分支,master分支和dev分支,*表示當前分支

*master

dev

8.創建新分支:

git branch 分支名稱>

9.切換分支:

git checkout 分支名稱>

10.創建分支且切換到新分支:

git checkout -b 分支名稱>

PS: 等價於

git branch 分支名稱>

git checkout 分支名稱>

11.刪除分支:

git branch -d 分支名稱>

12.合並指定分支到當前分支:

git merge 指定分支名稱>

13.Git 變基:

git rebase 指定分支名稱>

14.基於最新的提交創建標簽:

git tag 標簽名稱>

15.刪除指定標簽:

git tag -d 指定標簽名稱>

16.列出所有的本地標簽:

git tag

17.查看所有的提交 歷史 :

git log

18.查看指定文件的提交 歷史 :

git log -p 指定文件>

19.以列表方式查看指定文件的所有提交 歷史 :

git blame 指定文件>

20.隱藏工作現場, 工作內容暫不提交:

git stash

PS:在臨時需要處理緊急bug,當前代碼又不想提交的情況下,使用該條指令較為方便

21.恢復之前隱藏的工作現場:

git stash apply

PS:恢復工作現場之後,stash的內容並不會刪除

22.刪除工作現場(在恢復工作現場之後使用):

git stash drop

23.恢復工作現場並刪除stash內容

git stash pop

24.版本回退到上一個版本:

git reset --hard HEAD^

PS:^的個數表示回退版本的個數,例如回退3個版本:

git reset --hard HEAD^^^

25.版本回退到指定版本:

git re set --hard 指定版本號>

PS:可以通過git log 可以查看版本號,回退是,指定版本號可以不寫全,寫前幾位即可

26.查看遠程版本庫信息:

git remote -v

28.查看指定遠程版本庫信息:

git remote show 指定版本庫>

29.從遠程倉庫獲取代碼:

git fetch 遠程倉庫>

30.下載遠程倉庫代碼並合並到本地:

git pull 遠程倉庫> 遠程分支>

31.上傳所有標簽:

git push --tags

32.狀態查詢:

git status

❸ git merge 的奧秘

Git 合並兩個分支時，如果順著一個分支走下去可以到達另一個分支的話，那麼 Git 在合並兩者時，只會簡單地把指針右移，叫做「快進」（fast-forward），比如下圖：

快進式合並會把 feature 的提交歷史混入到 master 中,如果某一次 master 出現了問題，你需要回退到上個版本的時候，比如上例，你就會發現退一個版本到了 B，而不是想要的 F

由於 --no-ff 禁止了快進，所以會生成一個新的提交，master 指向 G。

git merge --squash 是用來把一些不必要commit進行壓縮，比如說，你的feature在開發的時候寫的commit很亂，那麼我們合並的時候不希望把這些歷史commit帶過來，於是使用 --squash 進行合並，此時文件已經同合並後一樣了，但不移動HEAD，不提交。需要進行一次額外的commit來「總結」一下，然後完成最終的合並。

❹ git常用操作

如果不用"pick"或者"edit"，而是指定"squash"，Git 會同時應用那個變更和它之前的變更並將提交說明歸並。因此，如果想將這三個提交合並為單一提交， 可以將腳本修改成這樣

保存並退出編輯器，Git 會應用全部三次變更然後將送回編輯器來歸並三次提交說明。

然後保存，就會擁有包含前三次提交的全部變更的單一提交 。

註：最頂行pick 不能修改為squash

當你正在進行項目中某一部分的工作，裡面的東西處於一個比較雜亂的狀態，而你想轉到其他分支上進行一些工作。問題是，你不想提交進行了一半的工作，否則以後你無法回到這個工作點。解決這個問題的辦法就是 git stash 命令。

「『儲藏」「可以獲取工作目錄的中間狀態——也就是修改過的被追蹤的文件和暫存的變更——並將它保存到一個未完結變更的堆棧中，隨時可以重新應用。

當追准備切換分支，但是還不想提交你正在進行中的工作；所以儲藏這些變更。為了往堆棧推送一個新的儲藏，只要運行? git stash ：

這時，你可以方便地切換到其他分支工作；你的變更都保存在棧上。要查看現有的儲藏，你可以使用? git stash list ：

git stash apply :重新應用你剛剛實施的儲藏

git stash apply stash@{number} :應用更早的儲藏

只需回到需要合並的源分支，運行 git merge 命令指定要合並進來的分支即可；Git 作了合並，但沒有提交，它會停下來等你解決沖突。要看看哪些文件在合並時發生沖突，可以用 git status 觀察

任何包含未解決沖突的文件都會以未合並（unmerged）的狀態列出。Git 會在有沖突的文件里加入標準的沖突解決標記，可以通過它們來手工定位並解決這些沖突。可以看到此文件包含類似下面這樣的部分：

可以看到 ======= 隔開的上半部分，是? HEAD （即 master 分支，在運行 merge 命令時所切換到的分支）中的內容，下半部分是在 iss53 分支中的內容。解決沖突的辦法無非是二者選其一或者親自整合到一起。比如可以通過把這段內容替換為下面這樣來解決：

在解決了所有文件里的所有沖突後，運行? git add ?將把它們標記為已解決狀態（譯註：實際上就是來一次快照保存到暫存區域。）

pull時為了防止更改後pull Feiled的出現，先執行commit,stash or revert。

❺ Git不同項目代碼分支合並，且僅合並特定提交

使用場景： 項目中同一個服務在2個不同的倉庫中開發，當在2中開發的 部分功能 需要合並到1中時。

操作步驟：

1）在需要合並的目錄打開gitbash，執行

git remote add 遠程別名 遠程地址

2）git fetch 別名 分支名

此處必須使用 git fetch，因為 git pull = git fetch + git merge，會自動合並所有提交，從而導致不需要的提交被合入當前分支。

3）在gitlab commit查看commit的hash值，或者使用git log查看。復制需要合並的單個或多個hash後，執行命令：

4）使用git status確認狀態無誤後，執行git push即完成合並

❻ git merge用法

git merge用法如下：

當前分支合並到另一分支時，如果沒有分歧解決，就會直接移動文件指針。這個過程叫做fastforward。

舉例來說，開發一直在master分支進行，但忽然有一個新的想法，於是新建了一個develop的分支，並在其上進行一系列提交，完成時，回到 master分支，此時，master分支在創建develop分支之後並未產生任何新的commit。此時的合並就叫fast forward。

1、git merge dev

是將dev的分支合並到當前分支，應該默認是fast forward模式

2、git merge dev --no-ff

--no-ff指的是強行關閉fast-forward方式。

ast-forward方式就是當條件允許的時候，git直接把HEAD指針指向合並分支的頭，完成合並。屬於「快進方式」，不過這種情況如果刪除分支，則會丟失分支信息。因為在這個過程中沒有創建commit

3、git merge dev --squash

是用來把一些不必要commit進行壓縮，比如說，你的feature在開發的時候寫的commit很亂，那麼我們合並的時候不希望把這些歷史commit帶過來，於是使用--squash進行合並，此時文件已經同合並後一樣了，但不移動HEAD，不提交。需要進行一次額外的commit來「總結」一下，然後完成最終的合並

❼ git使用：怎樣merge一個分支的某個時間段內的所有提交到另一個分支

沒看懂你表達抄的意思，但基本的合並分支的方法入下：
1.git checkout xxx（切換到你要將其他分支合並到的主分支上,xxx是分支名）
2.git merge xxx （合並操作）
3.git branch -d xxx(刪除已經合並的分支，可選擇不刪除)

❽ 如何 git push 或者 merge 指定的幾個文件

1、首先新建一個文本文件，名字為「.gitignore.txt」。

❾ git合並時忽略某個文件

因為開發現場跟部署的環境不同,有很多 ip 地址每次都要改來改去;於是開兩個分支 master (用來保存部署現場的 ip )和 dev (開發環境的 ip ),開發功能時在 dev 分支,然後使用 master 合並,每個分支都保存著自己的 config 配置文件,不想 dev 分支被 master 合並時 config 文件也合並.

git merge dev

在 dev 分支上的 index.php 就不會被合並了;

❿ git merge原理（遞歸三路合並演算法）

我們知道git 合並文件是以行為單位進行一行一行進行合並的，但是有些時候並不是兩行內容不一樣git就會報沖突，因為smart git 會幫我們自動幫我們進行取捨，分析出那個結果才是我們所期望的，如果smart git 都無法進行取捨時候才會報沖突，這個時候才需要我們進行人工干預。那git 是如何幫我們進行Smart 操作的呢？

Mine 代表你本地修改...
Theirs 代表其他人修改...
假設對於同一個文件，出現你和其他人一起修改，此時如果git來進行合並，git就懵逼了，因為Git既不敢得罪你(Mine)，也不能得罪他們(Theirs) 無理無據，git只能讓你自己搞了，但是這種情況太多了而且也沒有必要…

三路合並就是先找出一個基準，然後以基準為Base 進行合並，如果2個文件相對基準(base)都發生了改變 那git 就報沖突，然後讓你人工決斷。否則，git將取相對於基準(base)變化的那個為最終結果。

下面面的合並就是我們常見的分支graph,結合具體分析：

git merge-base –all commit_id1(Yours/Theirs) commit_id2(Yours/Theirs) 就能找出公共祖先的commitId(Base)

圖雖然復雜 但是核心原理是不變的，下面我們看 另外一個稍微高級一點的核心原理」遞歸三路合並」 也是我們很常見看到 git merge 輸出的 recursive strategy

簡短描述下 如何會出現上面的圖：

從上面我們DAG圖可以知道公共祖先有③和④，那到底選擇哪個呢，我們分別來看：

最終期待的結果是什麼？

所以 我們的最佳公共祖先應該是4，最終結果應該是 /foo.c = C
git 如何選擇公共祖先呢？

你可能會說用 git merge-base ⑥ ⑦ 輸出的是 ④ 但是git 就真的是用 ④ 做祖先嗎 ？答案是No

從git的解釋中，我們就知道 如果有2個都是最佳公共祖先時候，這個時候git 會隨便輸出一個不確定公共祖先。

git 是這樣進行合並的：

當項目中包含多條功能分支時，有時就需要使用 git merge 命令，指定將某個分支的提交合並到當前分支。Git 中有兩個合並策略：fast-forward 和 no-fast-forward。

當merge ② 和 ⑥時候 由於②是公共祖先，所以進行Fast-Forward 合並，直接指向⑥ 不用生成一個新的⑧進行merge了。

no-fast-forward（--no-ff）意為非快進式合並，fast-forward的場景很少遇到，基本是：在當前分支分離出子分支後（比如分支dev），後續會有其他分支合並進來的修改，而分離出的dev分支也做了修改。這個時候再使用git merge，就會觸發 no-fast-forward 策略了。

看懂下面這個例子你就明白了：

現在 f 提交是我們正在合並的提交

如果現在找 e 和 d 的共同祖先，你會發現並不唯一，b 和 c 都是。那麼此時怎麼合並呢？

git 會首先將 b 和 c 合並成一個虛擬的提交 x，這個 x 當作 e 和 d 的共同祖先。

而要合並 b 和 c，也需要進行同樣的操作，即找到一個共同的祖先 a。

我們這里的 a、b、c 只是個比較簡單的例子，實際上提交樹往往更加復雜，這就需要不斷重復以上操作以便找到一個真實存在的共同祖先，而這個操作是遞歸的。這便是「遞歸三路合並」的含義。

這是 git 合並時默認採用的策略。

git官方文檔
git merge原理
git merge的合並原理