git解决冲突

git报错：Please commit your changes or stash them before you merge. 解决：1.不需要保留本地修改的话，直接将有冲突的文件还原再pull:git checkout [文件路径] 　　 2.需要保留本地修改： 　　　　（1）git stash，这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：其中stash@{0}就是刚才保存的标记。 　　　　（2）git pull，暂存了本地修改之后，就可以pull了。 　　　　（3）git stash pop stash@{0} ，还原暂存的内容 ， 系统提示如下类似的信息：Auto-merging c/environ.c CONFLICT (content): Merge conflict in c/environ.c 　　　　（4）打开冲突的文件自行确定需要的内容 　　　　　　 你会在文件中发现<<<<<<< HEAD ，======= ，>>>>>>> ae9a0f6b7e42fda2ce9b14a21a7a03cfc5344d61这种标记，<<<<<<< HEAD和=======中间的是你自己的代码， ======= 和>>>>>>>中间的是其他人修改的代码 自己确定保留那一部分代码， 　　　　　　 最后删除<<<<<<< HEAD ，=

场景： 用户UserA修改了文件File1，用户UserB也修改了文件File1并成功merge到了服务器上，而UserA和UserB改动了同一个代码块，当UserA拉取代码时git无法merge此改动，就会出现如下错误提示： $ git pull Updating 88b0e2d..af4b152 error: Your local changes to the following files would be overwritten by merge: xxxxx/TuningPool.java Please, commit your changes or stash them before you can merge. Aborting 1、先将本地修改存储起来 Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作 $ git stash 用git stash list可以看到保存的信息，其中stash@{0}就是刚才保存的标记。 $ git stash list stash@{0}: WIP on dev: 88b0e2d Control the thread number 2、pull内容 暂存了本地修改之后，就可以pull了。 $ git pull 3、还原暂存的内容 工作现场还在，Git把stash内容存在某个地方了

1，分支管理 分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，立刻提交，由于代码还没有写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的风险。 现在有了分支，就不能怕了，你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，在一次性合并到原来的分支上，这样，既安全，又不影响别人工作。 Git的分支与其他版本控制系统不同，无论创建，切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。 2，创建与合并分支 在版本回退里，我们已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支（master分支），HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。 ① 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD执行maser，就能确定当前分支，以及当前分支的提交点，每次提交，master分支都会向前一步： ② 当我们创建新的分支，例如dev时，Git创建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev

git命令 一. 克隆，提交，拉取代码 1. 克隆，提交代码 git clone：远端仓库地址 git remote add upstream： 上游远端仓库地址（fork代码的原地址）。添加上游远端仓库 git add -A git commit -m '描述' git push 2. 从上游远端仓库拉取冲突代码，解决冲突 git pull upstream master -r：把冲突部分拉下来，使用rebase合并代码，不会产生合并信息，不使用rebase确实回产生的。pull细节：把工作区的修改暂存起来，把远端代码和上一次提交合并，然后把暂存的修改再合并到分支上 git add -A git rebase --continue：重新提交代码文件，不会产生额外的commit。如果合并的分支中存在多个commit，需要重复处理多次冲突。 只有处理冲突时候才能用这个命令。 git push -f：强制提交代码 3. 修补最近一次的提交 git commit —amend(-a)：修补最近一次push 4. 拉取代码 git pull 等价于 git fetch & git merge：这时从远端拉取代码，回产生一个合并日志，产生分叉 git pull --rebase (-r)：使用 git rebase 合并代码 二. 删除远端误提交代码文件 git rm —cached

目录 git pull如何强制覆盖本地文件 Git如何同时删除本地分支和远程分支 Git如何撤销最近一次提交 Git撤销本地的最后一次提交 Git撤销最近一次远程提交 如何修改提交信息和文件 修改本地提交信息（未推送到远程） 修改远程提交信息 Git如何在提交之前撤销git add Git如何重命令本地分支 如何在Git中添加一个空文件夹 如何在Git中从远程分支克隆到本地 Git如何将本地分支推送到远程 如何在Git中丢弃掉当前工作分支下所有untracked的文件 Git如何从远程拉取并强制覆盖本地文件 Git提交代码时发生冲突不能合入 Git两个分支之间出现冲突如何解决 git pull 如何强制覆盖本地文件 error: Untracked working tree file 'public/images/icon.gif' would be overwritten by merge. 使用 git reset 命令 重要提示：如果您有任何本地更改，将会丢失。无论是否有--hard选项，任何未被推送的本地提交都将丢失。 # 从远程下载最新的，而不尝试合并或rebase任何东西 git fetch -all # 将主分支重置为您刚刚获取的内容 git reset --hard origin/<branch_name>

Git是目前世界上最先进的分布式版本控制系统。 创始人：Linus Torvalds林纳斯·托瓦兹 经典的集中管理型（CVS、VSS、SVN） 版本管理系统： 1、版本管理的服务器一旦崩溃，硬盘损坏，代码如何恢复？ 2、程序员上传到服务器的代码要求是完整版本，但是程序员开发过程中想做小版本的管理，以便追溯查询，怎么破？ 3、系统正在上线运行，时不时还要修改bug，要增加好几个功能要几个月，如何管理几个版本？ 4、如何管理一个分布在世界各地、互不相识的大型开发团队？ 1、命令行工具：Git for windows Git是分布式版本控制系统，所以需要填写用户名和邮箱作为一个标识。 　　C:\Users\admin路径下的.gitconfig文件里面可以看到 　　--global 表示全局属性，所有的git项目都会共用属性 1）填写用户名和邮箱Administrator@PC201803221826 MINGW64 /e/git-space $ git config --global user.name "kris" Administrator@PC201803221826 MINGW64 /e/git-space $ git config --global user.email "kris073@aliyun.com" ##全局是每个项目都是这个名； 非全局是针对这个项目

一、分支 1.git中如何保存版本 在我们以往使用文件来进行版本控制的时候，都是将上一个版本复制一份，然后在其基础上进行修改。 但在git中，git只保存当前版本和上一个版本之间的差异，这样可以节省存储空间， 在生成版本的时候速度也会更快。 2.Master主线 如下图所示： 当只有一条主线Master时，新版本都是在上一个版本的基础上进行修改的，例如Version2在Version1的100个文件基础上，新增了20个文件，并修改了其中10个文件。 也就是说Version2只需要保存新增的20个文件，以及修改的10个文件的修改信息，当我们需要Version2的时候，git再去Version1中拿未修改的90个文件。 同理，Version3、Version4也是如此。 3.分支概念 当我们需要已某个版本作为基准，同时开发多个新功能，则可能在该基准版本处产生分支，如下图所示： 处理线上系统的紧急BUG： 例如，Version3是已上线的版本， 我们在Version3的基础上开发新功能： Version3突然出现紧急BUG，需要修复，怎么办？我们可以在Version3的基础上新开一个分支，专门用作BUG修复，修复完后合并到主分支： 而负责新功能开发的分支，可以继续研发新功能，不受影响。等到新功能开发测试完毕后，也可以合并到主分支Master中去。 4.创建分支（开发新功能） 1

几乎所有的版本控制都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 Git的分支模型成称为它的“必杀技特性”，也正因为这一特性，使得Git从众多版本控制系统中脱颖而出。Git处理分支的方式是难以置信的轻量，创建新的分支这一操作是秒级完成的，并且在不同分支之间的切换操作也是一样便捷。 Git的分支，其实本质上仅仅是指向提交对象的可变指针。Git的默认分支是master。在多次提交操作之后，其实我们已经有一个指向最后那个提交对象的master分支。他会在每次的提交操作中自动向前移动。 实际工作中我们可能会遇到一个下面这个情况： 开发某个网站。 为实现某个新的需求，创建一个分支。 在这个分支上开展工作。 正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理： 切换到你的线上分支（production branch）。 为这个紧急任务新建一个分支，并在其中修复它。 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。 修改后切换回你最初工作的分支上，继续工作。 1、初始化一个目录并声明用户及邮箱地址 [root@git /]# mkdir /git [root@git /]# cd git/ [root@git git]# git init Initialized empty Git

多人协作 当你从远程仓库克隆时，实际上Git自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是 origin 。 要查看远程库的信息，用 git remote ： $ git remote origin 或者，用 git remote -v 显示更详细的信息： $ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push) 上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限，就看不到push的地址。 推送分支 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上： $ git push origin master 如果要推送其他分支，比如 dev ，就改成： $ git push origin dev 但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？ master 分支是主分支，因此要时刻与远程同步； dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； bug分支只用于在本地修复bug，就没必要推到远程了

当你从远程仓库克隆时，实际上Git自动把 本地的 master 分支 和 远程的 master 分支 对应起来 了，并且，远程仓库的默认名称是 origin 。 要查看远程库的信息，用 git remote ： $ git remote origin 或者，用 git remote -v 显示更详细的信息： $ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push) 上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限，就看不到push的地址。 推送分支 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上： $ git push origin master 如果要推送其他分支，比如 dev ，就改成： $ git push origin dev 但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？ master 分支是主分支，因此要时刻与远程同步； dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； bug分支只用于在本地修复bug，就没必要推到远程了