eclipse 中使用 git pull 后出现红色方块是什么意思

如果你拉去的代码所包含的commit中， 有对你当前变更的文件进行的修改， 他就会报这个错误。如果你本地从的更高没有提交，他是不会自动尝试merge的。（merge只能合并已经提交的修改）

分两种情况：1无冲突，2有冲突无冲突时，本地未提交修改不会被覆盖，能够执行pull。有冲突时，提示“Your local changes to the following files would be overwritten by merge”，本次pull执行失败，并且不会拉取远程代码，不用担心。

从字面意思也可以理解，都是往下拉代码，git clone是克隆，git pull 是拉。但是，也有区别：从远程服务器克隆一个一模一样的版本库到本地,复制的是整个版本库，叫做clone.（clone是将一个库复制到你的本地，是一个本地从无到有的过程）从远程服务器获取到一个branch分支的更新到本地，并更新本地库，叫做pull.（pull是指同步一个在你本地有版本的库内容更新的部分到你的本地库）git pull相当于是从远程获取最新版本并merge（合并）到本地 git pull = git fetch + git merge，git fetch更安全一些git clone是远程操作的第一步，通常是从远程主机克隆一个版本库，eg:$ git clone ## 该命令会在本地主机生成一个目录，与远程主机的版本库同名，如果要是制定不同的目录名，可以将目录名作为git clone 命令的第二个参数。eg：$ git clone #版本库网址# #本地目录名# git clone支持多种协议，除了http（s),还有ssh,git,本地协议。git pull 作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。它的完整格式稍稍有点复杂。eg:$ git pull ##远程主机（origin） #远程分之(next)#：#本地分之(master)#如果远程分支是与当前分支合并，则冒号后面的部分可以省略。eg:$ git pull #远程主机(origin)#　 #远程分之(next)#　相当于1. $ git fetch origin 2.$git merge origin/next 在某些场合，git会自动在本地和远程分之之间，建立一种追踪关系。比如，在git clone 的时候，所有本地分之默认与远程主机的同名分之，建立追踪关系，也就是，本地的master分之自动“追踪”origin/master分之。git 可以手动建立追踪， git branch --set-upstream master origin/next --->指定master分之追踪到origin/next。如果当前分支只有一个追踪分支，连远程主机名都可以省略。$ git pull 表示当前分之自动与唯一一个追踪分之进行合并。

git fetch:相当于是从远程获取最新版本到本地。 git pull:命令的作用是,取回远程主机某个分支的更新,再与本地的指定分支合并。 git fetch获取最新版本后，会覆盖本地计算机的版本，旧版本的信息会被删除。

那是因为你上次有提交没有提交到服务器，你可以先git push或者git stash ，然后再git pull下试试！git pull <remote> <branch>要把远程哪个分支的内容down下来？执行：git pull origin master 之后，就会把远程的origin库下的master分支down到本地

你好，你是要问gitpull需要切换到主分支吗？gitpull需要切换到主分支。当主分支远端有需要gitpull的内容时,更新本地对应的主分支是要切换到本地主分支的，所以gitpull需要切换到主分支。

注意到你这一行日志：libexec/git-core/git-sh-setup: line 83: /bin/sed: Bad file number我看是缺少sed可执行程序，或者sed不在这个路径下。sed是个行编辑器，可以用来批量替换啥的。如果真是这个导致的，安一个sed就行了。此外还有一个：/bin/tr您是在windows下通过什么环境使用git的？ windows往往都没有sed tr这些工具。

如果只是想回到 pull 之前当前分支所在的commit位置，则可以。比方说你在 master 分支上，可以用 git reflog master 查看 master 分支历史变动记录，其中应该有一个就是你 pull 之前的那个commit， 你可以用 git reset --hard <COMMIT_ID> 来恢复。比如下面的，假定你 pull 之前处在 xxxxxx 那个位置，那么可以用 git reset --hard master@{1} 恢复。 但是无论如何，没有commit并被 git reset --hard 清掉的本地改动是无法通过git恢复的。$ git reflog master3b4946a master@{0}: merge origin/master9187e70 master@{1}: xxxxxxx3b4946a master@{2}: yyyyyyy

git fetch 只取回远端的更新，但不会对本地分支执行merge操作。而 git pull 则在git fetch的基础上做了merge。 简单说： git pull 等于 git fetch + git merge 特别的： git pull --rebase 等于 git fetch + git rebase

　　处理的方式非常简单，主要是使用git stash命令进行处理，分成以下几个步骤进行处理。　　1、先将本地修改存储起来　　$ git stash　　这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：　　git stash暂存修改　　其中stash@{0}就是刚才保存的标记。　　2、pull内容　　暂存了本地修改之后，就可以pull了。　　$ git pull　　3、还原暂存的内容　　$ git stash pop stash@{0}　　系统提示如下类似的信息：　　Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c　　意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。　　4、解决文件中冲突的的部分　　打开冲突的文件，会看到类似如下的内容：　　git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。　　解决完成之后，就可以正常的提交了。

很长时间没用了，突然发现git pull没有任何反应，也不报错。打印git log，发现commitId也不对。 记录一下最后解决的办法： 所以，应该是公钥过期了 Git配置的一些常见错误： windows: mac: 添加本地分支与远程分支的关联： origin/<branch>是本地分支对应的远程分支；<local_branch>是当前的本地分支

　　git pull 不加参数的话 只是针对当前分支与远程库进行同步更新， 想想看如果5个分支都有更新且merge会有冲突的话，如果一个git pull 直接全部都merge 出来冲突了 那是多么的可怕啊

拉取远程仓库：$ git pull [remoteName] [localBranchName]git pull：从其他的版本库（既可以是远程的也可以是本地的）将代码更新到本地，例如："git pull origin master"就是将origin这个版本库的代码更新到本地的master主枝，该功能类似于SVN的update

使用 Git 作为代码版本管理，早已是现在开发工程师必备的技能。可大多数工程师还是只会最基本的保存、拉取、推送，遇到一些commit管理的问题就束手无策，或者用一些不优雅的方式解决。 本文分享我在开发工作中实践过的实用命令。这些都能够大大提高工作效率，还能解决不少疑难场景。下面会介绍命令，列出应用场景，手摸手教学使用，让同学们看完即学会。 官方文档 git 教程 stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。 我猜你心里一定在想：为什么要变干净？ 应用场景：某一天你正在 feature 分支开发新需求，突然产品经理跑过来说线上有bug，必须马上修复。而此时你的功能开发到一半，于是你急忙想切到 master 分支，然后你就会看到以下报错： 因为当前有文件更改了，需要提交commit保持工作区干净才能切分支。由于情况紧急，你只有急忙 commit 上去，commit 信息也随便写了个“暂存代码”，于是该分支提交记录就留了一条黑 历史 ...(真人真事，看过这种提交) 如果你学会 stash，就不用那么狼狈了。你只需要： 就这么简单，代码就被存起来了。 当你修复完线上问题，切回 feature 分支，想恢复代码也只需要： 当有多条 stash，可以指定操作stash，首先使用stash list 列出所有记录： 应用第二条记录： pop，drop 同理。 stash 代码 填写备注内容，也可以不填直接Enter 在STASHES菜单中可以看到保存的stash 先点击stash记录旁的小箭头，再点击 apply 或者 pop 都可恢复 stash 官方文档 git 教程 回退你已提交的 commit，并将 commit 的修改内容放回到暂存区。 一般我们在使用 reset 命令时，git reset --hard 会被提及的比较多，它能让 commit 记录强制回溯到某一个节点。而 git reset --soft 的作用正如其名，--soft (柔软的) 除了回溯节点外，还会保留节点的修改内容。 回溯节点，为什么要保留修改内容？ 应用场景1：有时候手滑不小心把不该提交的内容 commit 了，这时想改回来，只能再 commit 一次，又多一条“黑 历史 ”。 应用场景2：规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。本来属于两块不同功能的修改，一起 commit 上去，这种就属于不规范。这次恰好又手滑了，一次性 commit 上去。 学会 reset --soft 之后，你只需要： reset --soft 相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。 以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该命令，不过再次 push 时，由于远程分支和本地分支有差异，需要强制推送 git push -f 来覆盖被 reset 的 commit。 还有一点需要注意，在 reset --soft 指定 commit 号时，会将该 commit 到最近一次 commit 的所有修改内容全部恢复，而不是只针对该 commit。 举个栗子： commit 记录有 c、b、a。 reset 到 a。 此时的 HEAD 到了 a，而 b、c 的修改内容都回到了暂存区。 官方文档 git cherry-pick 教程 将已经提交的 commit，复制出新的 commit 应用到分支里 commit 都提交了，为什么还要复制新的出来？ 应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来，单独处理。 应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit 复制到新分支。 现在有一条feature分支，commit 记录如下： 需要把 b 复制到另一个分支，首先把 commitHash 复制下来，然后切到 master 分支。 当前 master 最新的记录是 a，使用 cherry-pick 把 b 应用到当前分支。 完成后看下最新的 log，b 已经应用到 master，作为最新的 commit 了。可以看到 commitHash 和之前的不一样，但是提交时间还是保留之前的。 以上是单个 commit 的复制，下面再来看看 cherry-pick 多个 commit 要如何操作。 上面的命令将 commit1 和 commit2 两个提交应用到当前分支。 上面的命令将 commit1 到 commit2 这个区间的 commit 都应用到当前分支（包含commit1、commit2），commit1 是最早的提交。 在 cherry-pick 多个commit时，可能会遇到代码冲突，这时 cherry-pick 会停下来，让用户决定如何继续操作。下面看看怎么解决这种场景。 还是 feature 分支，现在需要把 c、d、e 都复制到 master 分支上。先把起点c和终点e的 commitHash 记下来。 切到 master 分支，使用区间的 cherry-pick。可以看到 c 被成功复制，当进行到 d 时，发现代码冲突，cherry-pick 中断了。这时需要解决代码冲突，重新提交到暂存区。 然后使用 cherry-pick --continue 让 cherry-pick 继续进行下去。最后 e 也被复制进来，整个流程就完成了。 以上是完整的流程，但有时候可能需要在代码冲突后，放弃或者退出流程： 回到操作前的样子，就像什么都没发生过。 不回到操作前的样子。即保留已经 cherry-pick 成功的 commit，并退出 cherry-pick 流程。 官方文档 将现有的提交还原，恢复提交的内容，并生成一条还原记录。 应用场景：有一天测试突然跟你说，你开发上线的功能有问题，需要马上撤回，否则会影响到系统使用。这时可能会想到用 reset 回退，可是你看了看分支上最新的提交还有其他同事的代码，用 reset 会把这部分代码也撤回了。由于情况紧急，又想不到好方法，还是任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技术形象在同事眼里一落千丈。 学会 revert 之后，立马就可以拯救这种尴尬的情况。 现在 master 记录如下： revert 掉自己提交的 commit。 因为 revert 会生成一条新的提交记录，这时会让你编辑提交信息，编辑完后 :wq 保存退出就好了。 再来看下最新的 log，生成了一条 revert 记录，虽然自己之前的提交记录还是会保留着，但你修改的代码内容已经被撤回了。 在 git 的 commit 记录里，还有一种类型是合并提交，想要 revert 合并提交，使用上会有些不一样。 现在的 master 分支里多了条合并提交。 使用刚刚同样的 revert 方法，会发现命令行报错了。 为什么会这样？在官方文档中有解释。 我的理解是因为合并提交是两条分支的交集节点，而 git 不知道需要撤销的哪一条分支，需要添加参数 -m 指定主线分支，保留主线分支的代码，另一条则被撤销。 -m 后面要跟一个 parent number 标识出"主线"，一般使用 1 保留主分支代码。 还是上面的场景，在 master 分支 revert 合并提交后，然后切到 feature 分支修复好 bug，再合并到 master 分支时，会发现之前被 revert 的修改内容没有重新合并进来。 因为使用 revert 后， feature 分支的 commit 还是会保留在 master 分支的记录中，当你再次合并进去时，git 判断有相同的 commitHash，就忽略了相关 commit 修改的内容。 这时就需要 revert 掉之前 revert 的合并提交，有点拗口，接下来看操作吧。 现在 master 的记录是这样的。 再次使用 revert，之前被 revert 的修改内容就又回来了。 官方文档 如果说 reset --soft 是后悔药，那 reflog 就是强力后悔药。它记录了所有的 commit 操作记录，便于错误操作后找回记录。 应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到远程分支，这时因为分支只有你的最新提交，就想着使用 reset --hard，结果紧张不小心记错了 commitHash，reset 过头，把同事的 commit 搞没了。没办法，reset --hard 是强制回退的，找不到 commitHash 了，只能让同事从本地分支再推一次（同事瞬间拳头就硬了，怎么又是你）。于是，你的技术形象又一落千丈。 分支记录如上，想要 reset 到 b。 误操作 reset 过头，b 没了，最新的只剩下 a。 这时用 git reflog 查看 历史 记录，把错误提交的那次 commitHash 记下。 再次 reset 回去，就会发现 b 回来了。 对我这种喜欢敲命令而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率。下面介绍两种设置短命令的方式。 方式一 方式二 打开全局配置文件 写入内容 使用 本文主要分享了5个在开发中实用的 Git 命令和设置短命令的方式。 文中列举的应用场景有部分不太恰当，只是想便于同学们理解，最重要的是要理解命令的作用是什么，活学活用才能发挥最大功效。 如果你也有一些实用的 Git 命令也欢迎在评论区分享~

在目标目录后面加上.git/git --git-dir=/www/my-web/.git/ pull

1. Pull is not possible because you have unmerged files.症状：pull的时候$ git pullPull is not possible because you have unmerged files.Please, fix them up in the work tree, and then use "git add/rm <file>"as appropriate to mark resolution, or use "git commit -a"应该是因为local文件冲突了解决方法：引用――“1.pull会使用git merge导致冲突，需要将冲突的文件resolve掉 git add -u, git commit之后才能成功pull.2.如果想放弃本地的文件修改，可以使用git reset --hard FETCH_HEAD，FETCH_HEAD表示上一次成功git pull之后形成的commit点。然后git pull.注意：git merge会形成MERGE-HEAD(FETCH-HEAD) 。git push会形成HEAD这样的引用。HEAD代表本地最近成功push后形成的引用。”就我的经验，有时候会莫名其妙地出现这种状况，而且Untracked files 还特别多（实际上自己可能只改了一两个文件），所以只好先保存好自己确定做出的local的修改，然后用git reset --hard FETCH_HEAD回到上次成功pull之后的点，然后再pull就没有问题了2.You are not currently on a branch.症状：有一次pull的时候又出现冲突，这回用“git reset --hard FETCH_HEAD”方法都不行了，出现：$ git pullYou are not currently on a branch, so I cannot use any"branch.<branchname>.merge" in your configuration file.Please specify which remote branch you want to use on the commandline and try again (e.g. "git pull <repository> <refspec>").See git-pull(1) for details.解决方法：首先git checkout -b temp其次git checkout master即可恢复到master repository的状态，然后就可以pull了

不是的,<<<<<<<head 是指你本地的分支的<<<<<<< HEADb789=======b45678910>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcchead 到 =======里面的b789是您的commit的内容=========到 >>>>68的是您下拉的内容

冲突的产生很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。冲突的类型逻辑冲突git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。内容冲突两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。树冲突文件名修改造成的冲突，称为树冲突。比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。$ git status added by us: b.c both deleted: origin-name.c added by them: a.c如果最终确定用b.c，那么解决办法如下：git rm a.cgit rm origin-name.cgit add b.cgit commit执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。最后执行git commit提交即可。内容冲突的解决办法发现冲突一般来讲，出现冲突时都会有“CONFLICT”字样：$ git pullAuto-merging test.txtCONFLICT (content): Merge conflict in test.txtAutomatic merge failed; fix conflicts and then commit the result.但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：error: project mini/sample注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：git rebase remote-branch-name冲突解决的一般过程merge/patch的冲突解决先编辑冲突，然后git commit提交。注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。rebase的冲突解决rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：git add -u注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。然后执行下面命令继续rebase：git rebase --continue有冲突继续解决，重复这这些步骤，直到rebase完成。如果中间遇到某个补丁不需要应用，可以用下面命令忽略：git rebase --skip如果想回到rebase执行之前的状态，可以执行：git rebase --abort注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。编辑冲突的方法直接编辑冲突文件冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：a123<<<<<<< HEADb789=======b45678910>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dccc其中：冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。此时，还没有任何其它垃圾文件产生。最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

1.1 配置环境 当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息。该用户信息和GitHub上注册的远程仓库的相关信息没有任何关系。 git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --list 配置信息保存在用户目录下的.giitconfig文件中 1.2 获取Git仓库 要使用Git对我们的代码进行版本控制，首先需要获得Git仓库 获取Git仓库通常有两种方式： 执行步骤如下： 1、在电脑的任意位置创建一个空目录作为我们的本地Git仓库 2、进入这个目录中，点击右键打开Git bash 窗口 3、执行命令git init 可以通过Git提供的命令从远程仓库进行克隆，将远程仓库克隆到本地的命令形式为： git clone 远程Git仓库地址 1.3 工作目录、暂存区以及版本库概念 版本库：.git隐藏文件就是版本库，版本库存储了很多配置信息、日志信息和文件版本信息等 工作目录（工作区）：包含.git文件夹的目录就是工作目录，主要用于存放开发的代码 暂存区：.git文件夹中有很多文件，其中一个index文件就是暂存区，也可以叫做stage。暂存区是一个临时保存修改文件的地方 1.4 Git工作目录下文件的两种状态 Git工作目录下的文件存在两种状态： Unmodified 未修改状态 Modified 已修改状态 Staged 已暂存状态 这些文件的状态会随着我们执行Git的命令发生变化 1.5 本地仓库操作 git status 查看文件状态 也可以使用git status -s使输出信息更简洁 git add 将未跟踪的文件加入暂存区，将已经修改的文件加入暂存区也是通过这个命令 git reset 将暂存区文件取消暂存 git commit -m “你的说明” 将暂存区文件提交到本地仓库 git rm 删除文件 说明：这种操作是直接将文件加入到暂存区里面，直接提交到本地仓库生效，而直接删除的话没有进入到暂存区，需要先把文件加入到暂存区之后，再提交到本地仓库。 将文件添加至忽略列表 一般我们总会有些文件无需纳入Git的管理，也不希望他们总出现在未跟踪文件列表。通常这些都是自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以在工作目录中创建一个名为.gitnore的文件（文件名称固定），列出忽略的文件模式。下面是一个示例：#代表注释 由于windows无法创建不含文件名的文件，因此我们需要在bash窗口中用如下命令创建。 git log 查看日记记录 1.6 远程仓库操作 如果想查看已经配置的远程仓库服务器，可以运行git remote 命令。它会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少可以看见origin，这是Git克隆的仓库服务器的默认名字 git remote -v 可以查看对远程仓库详细一点的说明 git remote show origin 可以查看对origin更详细的远程仓库的说明 运行git remote add 添加一个远程Git仓库，同时指定一个可以引用的简写 如果你想获得一份已经存在了的Git仓库的拷贝，这时需要用到 git clone 命令。Git克隆的是Git仓库服务器上的几乎所有数据（包括日志信息、 历史 记录等），而不仅仅是复制工作所需要的文件。当你执行git clone 命令的时候，默认配置下Git仓库中的每一个文件的每一个版本都将被拉取下来。 如果因为一些原因想要移除一个远程仓库，可以使用git remote rm 注意：此命令只是从本地移除远程仓库的记录，并不会影响到远程仓库 git fetch 是从远程仓库获取最新版本到本地仓库，不会自动merge 说明：如果使用fetch命令，拉取的文件会放到版本库里面，不会自动整合到工作区，如果需要整合到工作区，需要使用 git merge 远程仓库别名/远程仓库分支 git pull 是从远程仓库获取最新版本并merge到本地仓库 注意：如果本地仓库不是从远程仓库克隆，而是本地创建的仓库，并且仓库中存在文件，此时再从远程仓库中拉取文件的时候会报错（fatal：refusing to merge unrelated histories），解决此我呢提可以在git pull 命令后加入参数 --allow-unrelated-histories git push 1.7 Git分支 几乎所有的版本控制系统都是以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。Git的master是一个特殊分支。它跟其它分支没有区别。之所以每一个仓库都有mater分支，是因为git init默认创建它，并且大多数人都懒得去改动它。 # 列出所有本地分支 $ git branch #列出所有远程分支 $ git branch -r #列出所有本地分支和远程分支 $git branch -a git branch 分支名称 git checkout 分支名称 git push 远程仓库别名 远程仓库分支 git merge 分支名称 说明：在当前分支下合并其他分支 注意：如果两个分支存在同样的文件名且同行的内容不一样，那么会产生矛盾，需要自己手动修改产生矛盾后的文件，然后添加到暂存区然后提交。 git branch -d 分支名称 如果要删除的分支中进行了一些开发动作，此时执行上面的删除命令并不会删除分支，可以将命令中的-d参数改为-D 如果要删除远程仓库中的分支，可以使用命令git push origin -d branchName 1.8 Git标签 像其他版本控制系统一样，Git可以给 历史 中的某一给提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布结点（v1.0、v1.2等）。标签指的是某个分支某个特定时间点的状态。通过标签，可以很方便地切换到标记时的状态。 #新建一个tag $ git tag [tagName] $ git tag #新建一个分支，指向某个tag $ git checkout -b [branch] [tag] #删除本地tag $git tag -d[tag] #删除远程tag $git push origin :refs/tags/[tag]

同步代码最好用gitfetch不要用gitpull如果你本地有修改，那么用pull后，默认把冲突的文件进行合并处理了。

如果是git clone中途断了，只能重新下。如果已经有库，只是git fetch或是git pull，重新执行命令下的是差分。

答案对人有帮助，有参考价值0答案没帮助，是错误的答案，答非所问这个message默认是vi的方式打开的，按esc，输入:wq 表示保存，就完成了merge message的提交。只想拉取分支而不merge，请用git fetch

拉取远程仓库：$ git pull [remoteName] [localBranchName]git pull：从其他的版本库（既可以是远程的也可以是本地的）将代码更新到本地，例如："git pull origin master"就是将origin这个版本库的代码更新到本地的master主枝，该功能类似于SVN的update

这种情况一般是本地有未提交的更改，或者网络无法连通等。 具体要看输出的错误详细信息。

如果本地分支已经关联远程的主版本，直接pull即可否则，可用gitpullorigin远程主分支名:本地分支名进行拉取

在使用git pull代码时，经常会碰到有冲突的情况，提示如下信息：error: Your local changes to "c/environ.c" would be overwritten by merge. Aborting.Please, commit your changes or stash them before you can merge.这个意思是说更新下来的内容和本地修改的内容有冲突，先提交你的改变或者先将本地修改暂时存储起来。处理的方式非常简单，主要是使用git stash命令进行处理，分成以下几个步骤进行处理。1、先将本地修改存储起来$ git stash这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：git stash暂存修改其中stash@{0}就是刚才保存的标记。2、pull内容暂存了本地修改之后，就可以pull了。$ git pull3、还原暂存的内容$ git stash pop stash@{0}系统提示如下类似的信息：Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。4、解决文件中冲突的的部分打开冲突的文件，会看到类似如下的内容：git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。解决完成之后，就可以正常的提交了。

可以知乎搜索张哥专栏 从零开始学习Github系列 作为入门

使用该功能 主要是设计也是通过git来管理设计图的 启用了 git LFS 管理 但是其他协助人员只需要拉取 jpg、png 等预览图 就可以，所以需要指定拉取目录 1、在项目目录下git 初始化 2、修改.git文件夹里面的 config 文件 .git/config 启用 sparse checkout（稀疏检出） 3、在 .git/info 创建 sparse-checkout 文件,在文件里面指定需要拉取的目录或内容 4、开始拉取 git pull （需要输入账号密码）

先commit再pull自动合并有什么不好呢……

git clone是把整个git项目拷贝下来，包括里面的日志信息，git项目里的分支，你也可以直接切换、使用里面的分支等等git pull相当于git fetch和git merge。其意思是先从远程下载git项目里的文件，然后将文件与本地的分支进行merge。

由于Git对于项目的管理很高效，因此现在使用Git的公司很多，在Java开发中，我们经常使用的IDEA和Eclipse都可以很好的集成Git;在IDEA中，天然集成Git插件，因此我们不需要再额外的进行操作，只需要在本地中安装Git就可以。首先我们需要从远程仓库将代码克隆到本地：git clone https://github.com/test, clone后面跟随远程仓库的链接地址当我们打开本地的Git仓库项目之后，我们可以在项目中右击进行Git操作，其中包含提交，拉去，推送等命令。当我们修改完成代码之后，可以在Git下一级菜单中选择commit的选项进行提交，其中可以选择修改过的文件，添加commit message(提交说明)，以及每个文件修改的地方。确认无误之后，可以点击commit进行提交，对应的Git命令：git commit filename -m ‘test"参数介绍：filename:需要提价的文件，多个文件用空格隔开，如果是所有文件可以使用参数-a代替-m message，后面跟提交说明修改完成之后，可以选择git->repository->push可以将代码推送到远程分支对应的git命令git push我们也可以在git->repository->pull将代码从远程仓库拉取下来进行更新对应命令 git pullGit基本命令简介克隆远程仓库到本地：git clone https://github.com/test [myproject]，将远程代码克隆到本地并重命名myproject(可选)Git查看远程仓库地址： git remote -v查看修改过的文件列表：git status查看每个文件的修改对比： git diff提交文件： git commit -m ‘提交信息" filename查看提交日志：git log查看创建新分支：git branch [name] 如果name不为空则创建一个新的分支name切换分支： git checkout name 需要切换的分支名name撤销对文件的修改： git checkout filename 将filename(文件名)的修改内容撤销拉取远程仓库代码： git pull origin/name 如果之前拉取过这个分支，直接使用git pull就可以将代码推送到远程仓库： git push.gitignore文件介绍有时候我们在上传代码的时候，只需要将主要的文件上传即可，对于一些编译后的文件，我们并不需要上传，因此我们可以在.gitignore讲我们不需要的文件进行过滤;a.txt 忽略指定文件a.txttarget/ 忽略target路径下的所有文件*.class 忽略所有以.class结尾的文件/project/build/ 路径在project/build下的所有文件**/build/ 忽略所有build下的文件希望以上内容对您有所帮助，点击这里领取我们线上学习免费课程。更多Java干货可以持续关注浙江优就业官方网站以及浙江优就业公众号具体了解哦。如果大家有时间的话，最好是能到我们线下基地进行实地考察。

处理的方式非常简单，主要是使用git stash命令进行处理，分成以下几个步骤进行处理。1、先将本地修改存储起来 $ git stash 这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息： git stash暂存修改 其中stash@{0}就是刚才保存的标记。 2、pull内容 暂存了本地修改之后，就可以pull了。 $ git pull 3、还原暂存的内容 $ git stash pop stash@{0} 系统提示如下类似的信息： Auto-merging c/environ.c CONFLICT (content): Merge conflict in c/environ.c 意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。 4、解决文件中冲突的的部分 打开冲突的文件，会看到类似如下的内容： git冲突内容 其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。 解决完成之后，就可以正常的提交了。

在使用git pull代码时，经常会碰到有冲突的情况，提示如下信息：error: Your local changes to "c/environ.c" would be overwritten by merge. Aborting.Please, commit your changes or stash them before you can merge.这个意思是说更新下来的内容和本地修改的内容有冲突，先提交你的改变或者先将本地修改暂时存储起来。处理的方式非常简单，主要是使用git stash命令进行处理，分成以下几个步骤进行处理。1、先将本地修改存储起来$ git stash这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：git stash暂存修改其中stash@{0}就是刚才保存的标记。2、pull内容暂存了本地修改之后，就可以pull了。$ git pull3、还原暂存的内容$ git stash pop stash@{0}系统提示如下类似的信息：Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。4、解决文件中冲突的的部分打开冲突的文件，会看到类似如下的内容：git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。解决完成之后，就可以正常的提交了。

1、先将本地修改存储起来$ git stash这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：git stash暂存修改其中stash@{0}就是刚才保存的标记。2、pull内容暂存了本地修改之后，就可以pull了。$ git pull3、还原暂存的内容$ git stash pop stash@{0}系统提示如下类似的信息：Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。4、解决文件中冲突的的部分打开冲突的文件，会看到类似如下的内容：git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。解决完成之后，就可以正常的提交了。

1. git fetch：相当于是从远程获取最新版本到本地，不会自动mergeGit fetch origin mastergit log -p master..origin/mastergit merge origin/master 以上命令的含义： 首先从远程的origin的master主分支下载最新的版本到origin/master分支上 然后比较本地的master分支和origin/master分支的差别 最后进行合并 上述过程其实可以用以下更清晰的方式来进行：git fetch origin master:tmpgit diff tmp git merge tmp 从远程获取最新的版本到本地的test分支上 之后再进行比较合并2. git pull：相当于是从远程获取最新版本并merge到本地git pull origin master上述命令其实相当于git fetch 和 git merge在实际使用中，git fetch更安全一些因为在merge前，我们可以查看更新情况，然后再决定是否合并

1、先将本地修改存储起来$ git stash这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：git stash暂存修改git stash暂存修改其中stash@{0}就是刚才保存的标记。2、pull内容暂存了本地修改之后，就可以pull了。$ git pull3、还原暂存的内容$ git stash pop stash@{0}系统提示如下类似的信息：Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。4、解决文件中冲突的的部分

Git中从远程的分支获取最新的版本到本地有这样2个命令：1. git fetch：相当于是从远程获取最新版本到本地，不会自动mergegit fetch origin mastergit log -p master..origin/mastergit merge origin/master 以上命令的含义： 首先从远程的origin的master主分支下载最新的版本到origin/master分支上 然后比较本地的master分支和origin/master分支的差别 最后进行合并 上述过程其实可以用以下更清晰的方式来进行：git fetch origin master:tmpgit diff tmp git merge tmp 从远程获取最新的版本到本地的test分支上 之后再进行比较合并2. git pull：相当于是从远程获取最新版本并merge到本地git pull origin master上述命令其实相当于git fetch 和 git merge在实际使用中，git fetch更安全一些因为在merge前，我们可以查看更新情况，然后再决定是否合并

1、用gitlog查看上次du上库的版本，把commit复制出来。2、用gitreset–hard到上一个zhi版本，然后再gitpull2、把冲突dao的目录移走即可恢复。

两种办法：1、先用gitlog查看上次上库的版本，把commit复制出来，在用gitreset--hard到上一个版本，然后再gitpull2、把冲突的目录移走（需要备份的话，不需要备份的话直接删除），然后再gitpull确保你fetch的是需要下载的服务器。

gitpull之后无法编辑某些文件：保留本地修改:先封存保留原有本地文件的修改,从远端拉取后,再把封存的修改还原。

　处理的方式非常简单，主要是使用git stash命令进行处理，分成以下几个步骤进行处理。　　1、先将本地修改存储起来　　$ git stash　　这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：　　git stash暂存修改　　其中stash@{0}就是刚才保存的标记。　　2、pull内容　　暂存了本地修改之后，就可以pull了。　　$ git pull　　3、还原暂存的内容　　$ git stash pop stash@{0}　　系统提示如下类似的信息：　　Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c　　意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。　　4、解决文件中冲突的的部分　　打开冲突的文件，会看到类似如下的内容：　　git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。　　解决完成之后，就可以正常的提交了。

报错信息： 原因：如果有未提交的更改 解决： 先执行git stash,提交后 再执行git pull –rebase

因为专业的机子是不会的，你肯以使用360老帮你解决所有问题.

Git fetch 从远程分支获取最新版本到本地，并不会自动mergeGit pull从远程分支获取最新版本到本地，并且merge，所以实际上Git pull 执行了两个步骤，Git fetch将FETCH_HEAD的内容取下来Git merge FETCH_HEAD

gitfetch只取回远端的更新，但不会对本地分支执行merge操作。而gitpull则在gitfetch的基础上做了merge。简单说：gitpull等于gitfetch+gitmerge特别的：gitpull--rebase等于gitfetch+gitrebase

冲突的产生很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。冲突的类型逻辑冲突git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。内容冲突两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。树冲突文件名修改造成的冲突，称为树冲突。比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。$ git status added by us: b.c both deleted: origin-name.c added by them: a.c如果最终确定用b.c，那么解决办法如下：git rm a.cgit rm origin-name.cgit add b.cgit commit执行前面两个git rm时，会告警逗file-name : needs merge地，可以不必理会。树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。最后执行git commit提交即可。内容冲突的解决办法发现冲突一般来讲，出现冲突时都会有逗CONFLICT地字样：$ git pullAuto-merging test.txtCONFLICT (content): Merge conflict in test.txtAutomatic merge failed; fix conflicts and then commit the result.但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：error: project mini/sample注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：git rebase remote-branch-name冲突解决的一般过程merge/patch的冲突解决先编辑冲突，然后git commit提交。注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。rebase的冲突解决rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：git add -u注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。然后执行下面命令继续rebase：git rebase --continue有冲突继续解决，重复这这些步骤，直到rebase完成。如果中间遇到某个补丁不需要应用，可以用下面命令忽略：git rebase --skip如果想回到rebase执行之前的状态，可以执行：git rebase --abort注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。编辑冲突的方法直接编辑冲突文件冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：a123<<<<<<< HEADb789=======b45678910>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dccc其中：冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。此时，还没有任何其它垃圾文件产生。最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

首先确保你的本地git工作目录下已经增加了远程分支了使用 git remote -v 查看。如果没有则先使用 git remote add 命令添加一个（假设名为origin，分支为master）。如果已经有了，则使用 git push origin master命令提交当前工作目录下的分支到远程master分支

一、git pullgit pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。完整格式：$ git pull <远程主机名> <远程分支名>:<本地分支名>完整格式举例：比如，取回origin主机的next分支，与本地的master分支合并，需要写成下面这样，（1）$ git pull origin next:master：如果远程分支是与当前分支合并，则冒号后面的部分可以省略。（2）$ git pull origin next：上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。$ git fetch origin$ git merge origin/next在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动”追踪”origin/master分支。Git也允许手动建立追踪关系，git branch --set-upstream master origin/next上面命令指定master分支追踪origin/next分支。如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。$ git pull origin上面命令表示，本地的当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。如果当前分支只有一个追踪分支，连远程主机名都可以省略。

基本上顺序是这样的：你修改好了代码，先要提交git commit -am “commit message"然后有两种方法来把你的代码和远程仓库中的代码合并a. git pull这样就直接把你本地仓库中的代码进行更新但问题是可能会有冲突(conflicts)，个人不推荐b. 先git fetch origin（把远程仓库中origin最新代码取回），再git merge origin/master（把本地代码和已取得的远程仓库最新代码合并），如果你的改动和远程仓库中最新代码有冲突，会提示，再去一个一个解决冲突，最后再从1开始如果没有冲突，git push origin master，把你的改动推送到远程仓库中至于rebase很容易和merge混淆，因为就结果而言，两条命令是类似的，具体请看http://git-scm.com/book/zh/ch3-6.html

在解决gitmerge的冲突时，有时我总忍不住吐槽git实在太不智能了，明明仅仅是往代码里面插入几行，没想到合并就失败了，只能手工去一个个确认。真不知道git的合并冲突是怎么判定的。在一次解决了涉及几十个文件的合并冲突后（整整花了我一个晚上和一个早上的时间！），我终于下定决心，去看一下gitmerge代码里面冲突判定的具体实现。正所谓冤有头债有主，至少下次遇到同样的问题时就可以知道自己栽在谁的手里了。于是就有了这样一篇文章，讲讲gitmerge内部的冲突判定机制。recursivethree-waymerge和ancestorgit的源码先用merge作关键字搜索，看看涉及的相关代码。找了一段时间，找到了gitmerge的时候，比较待合并文件的函数入口：ll_merge。另外还有一份文档，它也指出ll_merge正是合并实现的入口。从函数签名可以看到，mmfile_t应该就代表了待合并的文件。有趣的是，这里待合并的文件并不是两份，而是三份。intll_merge(mmbuffer_t*result_buf,constchar*path,mmfile_t*ancestor,constchar*ancestor_label,mmfile_t*ours,constchar*our_label,mmfile_t*theirs,constchar*their_label,conststructll_merge_options*opts)看过githelpmerge的读者应该知道，ours表示当前分支，theirs表示待合并分支。看得出来，这个函数就是把某个文件在不同分支上的版本合并在一起。那么ancestor又是位于哪个分支呢？倒过来从调用方开始阅读代码，可以看出大体的流程是这样的，gitmerge会找出三个commit，然后对每个待合并的文件调用ll_merge，生成最终的合并结果。按注释的说法，ancestor是后面两个commit（ours和theirs）的公共祖先（ancestor）。另外前面提到的文档也说明，git合并的时候使用的是recursivethree-waymerge。关于recursivethree-waymerge，wikipedia上有个相关的介绍#Recursive_three-way_merge)。就是在合并的时候，将ours，theirs和ancestor三个版本的文件进行比较，获取ours和ancestor的diff，以及theirs和ancestor的diff，这样做能够发现两个不同的分支到底做了哪些改动。毕竟后面git需要判定冲突的内容，如果没有原初版本的信息，只是简单地比较两个文件，是做不到的。鉴于我的目标是发掘git判定冲突的机制，所以没有去看git里面查找ancestor的实现。不过只需肉眼在图形化界面里瞅上一眼，就可以找到ancestorcommit。（比如在gitlab的network界面中，回溯两个分支的commit线，一直到岔路口）有一点需要注意的是，revert一个commit不会改变它的ancestor。所谓的revert，只是在当前commit的上面添加了新的undocommit，并没有改变“岔路口”的位置。不要想当然地认为，revert之后ancestor就变成上一个commit的ancestor了。尤其是在revertmergecommit的时候，总是容易忘掉这个事实。假如你revert了一个mergecommit，在重新merge的时候，git所参照的ancestor将不是merge之前的ancestor，而是revert之后的ancestor。于是就掉到坑里去了。建议所有读者都看一下git官方对于revertmergecommit潜在后果的说法：mit的公共祖先，比较同一个文件分别在ours和theirs下对于公共祖先的差异，然后合并这两组差异。如果双方同时修改了一处地方且修改内容不同，就判定为合并冲突，依次输出双方修改的内容。