问题一：推送配置文件到远程仓库，如何删除远程仓库中的配置文件，并在本地使用这个文件。这种操作错误比较常见。一般是这样解决的：gitrm--cachedfilenameechofilename>>.gitignore先说明第二步，本地需要，远程仓库不需要。它必须写入.gitignore文件。否则，稍后将被删除。第一步是从git的暂存区中删除该文件。暂存区是索引区。看亲戚：git三个区，gitrmfilename，会删除工作区的工作目录和暂存区的暂存区的文件。如果你想在本地使用它，你不能这样做。gitrm--cachedfilename，将文件从暂存区StagingArea中删除，保留工作区，也就是我们平时编辑时看到的。本例中，已经提交，生成快照，文件进入版本库的提交历史，然后推送，远程版本库与本地版本库同步。这个时候直接push到remote是无效的。因为没有新的snapshot，也就是没有新的commitid。本地和远程历史日志是一致的。修改文件，add然后commit，push提交，就可以生效了。问题二：git如何解决代码冲突？三链接gitstashgitpullgitstashpop操作是隐藏你修改的代码，然后拉下远程仓库中的代码，然后释放你已经隐藏和修改的代码，让git自动合并。然后找<<<<<<<，有冲突的地方改一下。如果你想让代码库中的文件完全覆盖本地版本，gitreset--hardcommitidgitpull效果很好。场景是在合作的远程仓库上，别人做了一些改动。我没有commit，然后拉别人的commit。向下。刚进公司的时候，没办法。我经常做同样的事情。然后增强版来了。场景是在合作的远程仓库上，别人做了一些改动，我也在本地做了一些commit，然后拉下别人的commit。然后添加我的更改。然后找<<<<<<<，有冲突的地方改一下。这个时候先查看最新的commoncommitid。gitresetcommitidgitstashgitpullgitstashpopgitresetcommitid我本地仓库和合作的远程仓库是取消临时文件。将HEAD的指针指向commitid，修改暂存区StagingArea和repositoryCommitHistory，保持工作区沙箱的工作目录不变。亲们来了，看图加深理解：gitresetcommitid就是gitreset-mixedcommitid，移动HEAD，更新索引，也就是更新暂存区。将HEAD分支移动到指向，使索引看起来像HEAD。实际上，取消commitid后，加上commit.gitreset--softcommitid就是移动HEAD。移动HEAD分支的指向实质上撤消了最后一个gitcommit命令。当您运行gitcommit时，Git会创建一个新的提交并将HEAD指向的分支移动到该提交。当您将它重置回HEAD~（HEAD的父级）时，您实际上是在将分支移回到它原来的位置，而不更改索引或工作目录。gitreset--hardcommitid，移动HEAD，更新索引，更新工作目录。这三件事都完成了。前面两点已经说了。更新工作目录使其看起来像索引。从效果上看，就是当所有的修改都被撤销，本地文件的状态和commitid一样。问题三：什么时候合并分支用gitrebase而不是gitmerge？gitrebase和gitmerge都可以用来合并分支，从feature分支获取新的提交，然后应用到master分支（当然应用到其他分支分支也可以）。但方式不同。Merge是合并，rebase是rebase。怎么换底座？从图中可以看出：gitrebase是有移动基的，改变合并基的操作很直观：gitrebase做的是先移动指针，再移动结点。先移动指针：master分支之前分离出来的feature分支的commitid是feature分支的base。当在feature分支上执行gitrebasemaster时，feature分支的basebase被移动到master分支最新的commitid。再次移动节点：将新添加的commitid放到新基节点后面的feature分支上。更准确的说，是将feature分支上新的修改操作重新应用到master分支的HEAD节点上。例如：合并分支前：A<-B<-C[master]^\D<-E[branch]根节点为A，初始为A，在A的状态下，branchbranchgitmerge是这样合并的：A<-B<-C^^\\D<-E<-F提交给C的master分支，提交给E的branch分支，直接合并，一般合并到master，有冲突就解决。从图中可以看出：如果在不改变原来的commitid的情况下使用gitmerge，会生成一个新的commitcommitid。该项目中有许多协作成员。通常，您需要使用gitrebase。如果你用gitmerge，很可能是这样的。这样看很不舒服。需要用gitrebase修改历史：gitrebase是这样合并的：A<-B<-C<-`D`<-`E`将feature分支（示例中的branch分支）的commits移动到主分支顶部。使用变基看起来更好更直观。历史是一条没有分支的直线。从图中可以看到：使用rebase后，在feature分支上带来commit后，commitid发生了变化。并且没有合并的公共节点提交ID。有些团队使用gitrebase工作流程，有些团队使用gitmerge工作流程。gitrebase工作流程需要对git有更深入的了解，更多的商业用途。如果功能准备就绪，请使用gitrebasemerge。如何以这种方式添加功能从日志中更清楚。不然看日志，上一个特征A，下一个特征B，不是很专业的程序员。gitrebase工作流程一般就是这么实用。在feature分支上gitrebasemaster后，切到master分支后，gitmergefeature，此时merge什么都不做，只是将master分支的HEAD节点移动到feature的HEAD节点，state此时两个分支的同步。gitmerge工作流程非常适合民用。它的设计非常直观。在github上玩开源比较合适。因为多人在写，所以gitflow工作流程不是很统一。如果您使用gitrebase工作流程，您团队的其他人将不会知道。如果这样做，提交ID会被修改，并且与本地库不匹配。你对你的意见可能比较大。毕竟git使用分支，就是不冒犯别人的代码。
