git解决冲突

目录 1.分支介绍 2.基本使用分支 1.查看分支 2.创建一个分支dev并切换到其上进行工作 3.在dev分支中变更已经追踪的文件，并进行提交 4. dev分支的工作完成，可以切换回master分支 5.把dev分支的工作成果合并到master分支上 6.合并完成后删除dev分支了 3.解决冲突 1.查看冲突文件（就是两边都有修改的文件） 2.手动修改冲突文件，再加入缓存区，提交 3.查看状态，在命令行以图的方式查看 4.合并完成后删除dev分支了 3.分支管理策略 1.切换到dev分支下，并新建了一个文件提交到dev版本库 2.切换回master分支，编辑1.txt并进行一个提交 3.合并dev分支的内容到master分支 4.删除dev分支 4.强制禁用fast forward模式 5. Bug分支 1.把当前工作现场“储藏”起来，等以后恢复现场继续工作 2.假定需要在master分支上修复，就从master创建临时分支 3.修复完成提交 4.回到dev分支还原现场 关于作者 @ 1.分支介绍 创建了一个属于自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上 2.基本使用分支 注意 所有的操作都基于已经使用git的文件夹（工程目录） 1.查看分支 git branch 2

Git与GitHub Git简介 Git的基本操作 理解:工作区+暂存区+本地库 设置全局属性：用户名与邮箱地址 1.创建本地版本库 repository：git init 2.提交文件：git status/add/commit 3.查看文件提交记录：git log 4.回退历史：git reset --hard HEAD^ 5.版本穿越：git reflog/reset 6.还原文件（没有add和commit的前提下） 7.删除某个文件 Git分支 1.创建分支：git branch <分支名> 2.切换分支：git checkout <分支名> 3.合并分支：git merge <分支名> 4.合并时冲突：git diff GitHub 1.是什么？ 2.Git与GitHub操作 2.1 GitHub上的操作 2.2 Git上对GitHub的操作 前提 1.Git推送至GitHub：git remote add/git push 2.Git克隆/更新GitHub上的项目：git clone/git pull 2.3 协作冲突 2.4 Git免密登陆GitHub Git工作流 Git简介 Git 是目前世界上最先进的 分布式版本控制系统 。 首先，版本管理系统能干什么： 协同开发 冲突解决 版本记录 历史追查 代码备份 版本还原 权限管理 分支管理 代码审查 而经典的集中管理型

码云和git常用指令 目录： 替代cmd的实用工具cmder 码云的使用 git常用指令的使用 合并分支 码云的辅助文档以及官方联系方式 最近公司一直在使用国内的远程代码托管仓库码云（开源中国的），个人感觉还不错，给大家推荐一下，比github的速度要快很多。中文界面让像我这样英文不太好的小伙伴也更有安全感。 没有用过码云的朋友们可以了解一下喔，真的很不错。 官网 1.先给推荐一个比较实用的工具可以替代cmd控制台 喔！！！ cmder 是一款Windows环境下非常简洁美观易用的cmd替代者，它支持了大部分的Linux命令。cmder可以复制粘贴其中的报错代码。让我们更快的了解报错问题。 官网下载 cmder.net； （注意下载时需要翻墙； 翻墙软件 ， 个人建议不需翻墙时卸载，有的时候和浏览器显示会冲突 ） , 安装教程 cmder使用说明 2.码云的使用 在码云中可分为公有项目和私有项目。 公有项目是大家都可以操作的 私有项目只有开启权限才可以进行操作的 在创建过项目之后也可以进行公有项目和私有项目的切换 码云的代码使分为三种，原来是两种在近期多添加了svn的使用方式（越来越强大了） 第一种，cmd控制台中的操作指令 第二种，ssh方式（具体没使用过，是一种只读的方式，只可以pull和克隆代码） 第三种，svn方式（和自己服务器部署的svn使用方式相同） 3

三、svn的使用 1.直接使用tortoise进行checkout、update、commit 其中 URL我可以在 SVN服务器获取到，我在 myRepositories下右键新建文件 qianduan文件被建立，然后比如我这样右键 --> copy下 即可。 将复制的版本库URL粘贴上,如下图： 注意事项： .svn这个隐藏目录记录着两项关键信息：工作文件的基准版本和一个本地副本最后更新的时间戳，千万不要手动修改或者删除这个.svn隐藏目录和里面的文件!!,否则将会导致你本地的工作拷贝(静态试图)被破坏，无法再进行操作。 1) TortoiseSVN图标介绍 一个新检出的工作复本使用绿色的对勾重载，表示 Subversion状态正常。 在你开始编辑一个文件之后，状态就变成了已修改，而图标重载已变成了红色感叹号。通过这种方式，你可以很容易地看出那些文件从你上次更新工作复本被修改过，且需要提交。 如果在提交的过程中出现了冲突，图标就会变成了黄色感叹号。 加号告诉你有一个文件或者目录已经被计划加入到版本控制中。 2) TortoiseSVN Client基础操作: 1. SVN检出(SVN Checkout) 在文件夹或者目录下单击右键 – > 选择 SVN检出，如下图所示 2. 增加(Add) 在test项目文件下，新建一个b.txt文件，提交到版本库的方法如下2种： 1.

版本控制 说起版本，大家肯定都不会感到陌生，我们经常会看到手机APP的升级提示，这就是该软件的又一新版本的面世。再来说一个大家所熟悉的例子。还记得大学毕业的时候我们被毕业论文折磨的日子吗？导师总是能够帮你发现一个又一个新的错误，不停修改，每次修改都会成为一个版本留存，于是就有了下面的这一幕场景： 毕业论文_初稿.doc 毕业论文_修改1.doc 毕业论文_修改2.doc 毕业论文_修改3.doc 毕业论文_完整版1.doc 毕业论文_完整版2.doc 毕业论文_完整版3.doc 毕业论文_最终版1.doc 毕业论文_最终版2.doc 毕业论文_死也不改版.doc ... 这是我们之前所使用的版本控制方法，修改后也要避免以前文件的丢失，于是只能这样保存一个又一个文件。这种方式虽然可行，但是也有很多缺点： 1、文件数较多，保留所有版本时需要为每个版本保存一个文件以备用 2、如果需要对这些操作进行协同操作，不免要讲这些文件打包之后拷来拷去 3、容易丢失，一旦失手，删除后就无法恢复 于是为了解决上述版本控制的问题，一批版本控制工具应运而生：VSS、CVS、SVN、Git等，而在这其中Git处于绝对的霸主地位。 注意：一般版本控制工具包含两部分 客户端（本地）：本地编写内容以及版本记录 服务端（网盘）：将内容和版本记录同时保存在远程（可有可无） Git介绍 Git

GIT 的常规操作 常规操作也是我自己平时常用的几个命令, 学自于 pro git 这本书中 git 配置文件 git的配置文件位置 针对所有用户：/etc/gitconfig 针对当前用户： ～/.gitconfig 查看配置的方法 git config --list 修改配置的方法 git config --global user.name "wangyubin" (修改的是～/.gitconfig) git config --system user.name "wangyubin" (修改的是/etc/gitconfig) git 基本使用 clone现有仓库 git clone URL (URL支持git，ssh，http，https等各种协议) git中文件的各个状态 unstaged - git仓库中没有此文件的相关记录 modified - git仓库中有这个文件的记录，并且此文件当前有改动 staged - 追加,删除或修改的文件被暂时保存，这些追加,删除和修改并没有提交到git仓库 commited - 追加或修改的文件被提交到本地git仓库（git仓库中大部分都是这种文件，所以git status不显示这些文件） 查看git仓库中各文件状态 git status 初始化一个仓库 git init 在当前文件夹下生成.git目录，完成初始化

我是使用一台电脑测试， 然后在本地电脑创建了两个工作目录。专门用来模拟两个人提交代码。假设a、b两个人。只使用一个master分支做测试， 没有建立其他的分支。 主要就是为了研究冲突的解决方式。感觉git pull总是强制覆盖。 a修改了代码并且提交master分支。 　　　　1） 测试一： 远程master分支已改变，然后b现在也修改了代码。不过b还没有提交，直接git pull ，不能拉取代码。报错提示： error: Your local changes to the following files would be overwritten by merge: readme.txt Please commit your changes or stash them before you merge. 　　　　2） 先测试 b 选择commit的情况：b 修改代码后，commit 提交了代码。然后git pull，此时提示信息： Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 　　　　3）现在来使用 git diff查看有哪些冲突：(截图在PHP文档里)

当你从远程仓库克隆时，实际上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，就没必要推到远程了

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。 准备新的 feature1 分支，继续我们的新分支开发： $ git checkout -b feature1 Switched to a new branch 'feature1' 修改 readme.txt 最后一行，改为： Creating a new branch is quick AND simple. 在 feature1 分支上提交： $ git add readme.txt $ git commit -m "AND simple" [feature1 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-) 切换到 master 分支： $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。 在 master 分支上把 readme.txt 文件的最后一行改为： Creating a new branch

[master][~/Downloads/ios] git push -u origin master Username for 'https://github.com': shiren1118 Password for 'https://shiren1118@github.com': To https://github.com/shiren1118/iOS_code_agile.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/shiren1118/iOS_code_agile.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 引用别人出现的错误信息