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的合并原理