re-base

出现问题的原因：在github上更新了README.md,没有更新到本地仓库。而在本地git仓库又修改了文件，这时使用 git push origin master 推送到远程仓库后就出现了下面的问题： 解决办法： 使用git pull origin master 命令将远程仓库和本地仓库进行连接。之后可能会出现 Merge branch 'master' of提示问题，编辑不了文字，可直接按 shift+! 进入编辑状态输入 wq 后可以了。 产生原因分析 当多人合作开发一个项目时，本地仓库落后于远程仓库是一个非常正常的事情，可参考下图。 1 A-B- C(master) 2 \ 3 D(origin/master) 具体情境如下： 我当前拉取的远端版本为 B ，此时修改了代码，并在本地仓库 commit 一次，但并未 push 到远端仓库。 另一位开发者在 B 的基础上，同样 commit 了一次并 push 到远端仓库。那么这个时候，我再 push 自己的代码就会发生错误，如下。 这个时候我们会选择，先 pull，再 push。Ok，push 成功，但是此时我们查看 log 就会发现除了我们自己提交的那条日志之外，会多出一条 "Merge branch 'master' of ..."。 那么，为什么会出现这种现象呢？其实是与 Git 的工作原理有关，对 Git

版本控制简介 大纲 版本控制系统 分支模型 Git Git介绍 Git命令详情 版本控制系统 版本控制系统即VCS（Version Control System）是一种记录若干文件的修订记录的系统，帮助我们查阅或回到某个历史版本 VCS 人肉式 LVCS本地式版本控制系统 CVCS集中式版本控制系统 DVCS分布式版本控制系统 人肉VCS 问题 最大问题，污染了整个工作空间，没办法集中精力维护当前编辑的版本。 Local VCS - 本地式 举例 RCS（Revision Control System） 优缺点 优点：具备个人版本管理 缺点：多人协同开发无法开展 CVCS - 集中式 举例 CVS（Concurrent Versions System） SVN（Subversion） Perforce 优缺点 优点：中央版本管理，数据内容可控 缺点：每次操作经过中央库，单点故障 DVCS - 分布式 举例 Git Mercurial 优缺点 优点：本地操作，查看历史版本，版本差异比较 分支模型 版本污染，开发提交被迫终止， 问题定位比较复杂： 如果采用如下方式进行开发： 分支和分支模型 分支： 从目标仓库获得一份项目拷贝，每条拷贝都有和原仓库功能一样的开发线 分支模型（branching model）/工作流（workflow）： 一个围绕项目**[开发/部署/测试]*

问题： I know of some people who use git pull --rebase by default and others who insist never to use it. 我知道有些人默认使用 git pull --rebase ，而其他人坚持不使用它。 I believe I understand the difference between merging and rebasing, but I'm trying to put this in the context of git pull . 我相信我理解合并和变基之间的区别，但我试图把它放在 git pull 的上下文中。 Is it just about not wanting to see lots of merge commit messages, or are there other issues? 它只是不想看到很多合并提交消息，还是有其他问题？ 解决方案： 参考一： https://stackoom.com/question/AN94/我什么时候应该使用git-pull-rebase 参考二： https://oldbug.net/q/AN94/When-should-I-use-git-pull-rebase 来源： oschina 链接： https://my.oschina

一、登录 首次登录 $ git config --global user.name "Your Name" $ git config --global user.email ‘your email’ 如果忘记了登录名与密码 $ git config --global --replace-all user.email "输入你的邮箱" $ git config --global --replace-all user.name "输入你的用户名" 检查登录情况 $ git config --list 二、秘钥连接 1、首先检查是否已经有秘钥了 或者在C:\Users\Administrator.ssh查看 2、如果没有的话，执行以下指令生成秘钥： $ ssh-keygen -t rsa -C "你的邮箱" 3、然后去按照上条方式查看以下有没有生成 4、去C:\Users\Administrator.ssh里找到id_rsa.pub，用记事本打开，全选，复制，得到ssh key公钥。 5、进入github，点击settings 然后打开SSH keys菜单，Add SSH key新增秘钥，填上标题（随意，建议跟repository一致），然后将id_rsa.put文件中的key粘贴，然后Add key生成秘钥。 到此，github账号与本地的SSH key配置完成 三、

gerrit上提示代码冲突的时候，我们首先会想到rebase下，不行的话就只能解决冲突了，最简单的做法是我的另一篇博客https://www.cnblogs.com/zndxall/p/9140813.html 中的方法，但是有的时候还是会出现问题，报错commit xxxx is a merge but no -m option was given,如下： 或者执行git cherry-pick 4e73b64a5fc251e6ff82aa1db4316bd4ecd389d5 是一样的效果。 出现这个问题，是因为提交的代码之前pull 了其他人的代码并合入了自己本地的代码，产生了一个merge操作以后，又push到代码仓，就会出现这种情况，我们看下他的提交日志： 分3个点解释，标记“1”很明显是一个merge操作，标记“2”是他自己的改动，标记“3”我们看到parent节点有两个,一个merge里有多个父节点，cherry-pick的时候至少要指定一个父节点，可以用-m parent-num来指定，parent-num 默认从1开始，比如上面的两个父节点， 上面一个父节点29b3eb321d8f512616fad12ce40d7ed22d5d4371的parent-num 为1 ，

问题： I have two branches. 我有两个分支。 Commit a is the head of one, while the other has b , c , d , e and f on top of a . 提交 a 是一个的头，而其他有 b ， c ， d ， e 和 f 之上 a 。 I want to move c , d , e and f to first branch without commit b . 我想将 c ， d ， e 和 f 移到第一分支而不提交 b 。 Using cherry pick it is easy: checkout first branch cherry-pick one by one c to f and rebase second branch onto first. 使用樱桃挑选很容易：以 c 到 f 逐个签出第一个分支樱桃选择，然后将第二个分支重新设置为第一个分支。 But is there any way to cherry-pick all c - f in one command? 但是，有什么方法可以在一个命令中挑选所有 c - f 吗？ Here is a visual description of the scenario (thanks JJD ): 这是该场景的直观描述（感谢 JJD ）：

使用git向主干分支合并代码通常采用两种方式：第一种是merge，第二种是利用BeyondCompare等工具进行比对，将差异合并到主干； 通过merge合并代码出现冲突时，并不清楚谁的修改和谁的修改发生了冲突，在没有了解冲突背景的情况下解决冲突可能引入问题； 利用BeyondCompare等比对工具直接将代码合入会丢失大量的commit信息，影响后续代码的可追溯性。 个人建议采用git cherry-pick进行代码合并；首先在自己的开发分支上进行开发调试，验证通过后进行代码提交整理，识别功能性提交和调试性提交，将调试性提交与之前的功能性提交进行commit合并，最后将整理后的commit通过git cherry-pick合并到主干分支，具体步骤如下： 1.从主线分支master拉取自己的开发分支self_develop； 2.在自己的开发分支self_develop上进行开发、调试、验证，直至当前小功能点验证通过； 3.在自己的开发分支self_develop上执行git log >gitlog.txt, 将commit信息导出到gitlog.txt中，如下所示（请无视中文commit log，这是自己的LaTex文档库😀）； 4.使用notepad++等文本编辑器，过滤出以commit起始的commit id信息，从中截取拉取开发分支时的base以及后续开发提交部分，如下所示

【git上传本地代码到github新建仓库】 一、建立git本地仓库 　　1、在本地目标文件夹(Code)中执行命令： 　　　　git init　　 //初始化本地仓库 二、将上传到github的项目文件添加到本地仓库中： 　　1、将本地需要上传的工程代码复制到Code中： 　　　　git status　　 //查看本地仓库文件状态 　　2、将需要上传的文件纳入版本控制 　　　　git add XX　　 //XX为目标文件(夹)名,此时执行git status命令，目标文件变为绿色 　　3、将需要上传的文件提交到本地仓库 　　　　git commit -m "(版本提交信息)" 三、在github上创建远程仓库Repository并与本地仓库关联 　　1、创建远程仓库 　　　　依据github提示操作即可 　　2、建立本地仓库与远程github仓库的关联 　　　　git remote add origin git@github.com:Vikezhu/(repository名).git 　　3、实现本地与远程仓库的合并与同步（需要输入密码） 　　　　git pull --rebase origin master 　　4、将本地仓库的内容上传到github仓库（需要输入密码） 　　　　git push -u origin master 【本地代码更新后，同步到远程仓库github】

1.首先，删除本地的分支 git checkout -d cxa 2.所以，目前本地只有master分支了。 3.pull一下master的最新的代码本地 git pull 4.创建新的分支 git checkout -b cxa 5.修改代码之后，点击项目根目录右键选择Commit Directory 之后弹出框 对已经track并且修改的内容会打勾，输入commit的内容即可。 6.git push 关于rebase的操作，首先查看历史记录 git log 然后使用 git rebase -i HEAD~2 然后s(合并),p(保留) 最后使用pycharm push的时候强制push(force) 来源： oschina 链接： https://my.oschina.net/u/4342092/blog/3300870

前言 前情提要： Git应用详解第八讲：Git标签、别名与Git gc 这一节主要介绍 git cherry-pick 与 git rebase 的原理及使用。 一、 Git cherry-pick Git cherry-pick 的作用为移植提交。比如在 dev 分支错误地进行了两次提交 2nd 和 3rd ，如果想要将这两次提交移植到 master 分支上。采用先删除再添加的方法将会很繁琐，而使用 cherry-pick 就能轻松实现这一需求。 首先在版本库中创建了两个分支 master 和 dev ，并模拟上述场景： 可以看到，在 dev 分支上进行了两次提交，在 master 分支上只进行了一次提交。现在想要将这两次提交 移植 到 master 分支上。整体分为两步： 第一步： 将 dev 分支上多余的两次提交移植到 master 分支上； 第二步： 删除 dev 分支上多余的两次提交； 1.第一步 git cherry-pick commit_id 首先切换到 master 分支，然后使用如下命令将 dev 分支上的两次提交移植到 master 分支上： //移植2nd提交 git cherry-pick 009dd //移植3rd提交 git cherry-pick aec8c 009dd 和 aec8c 分别表示需要移植的提交 2nd 和 3rd 的 SHA1 值：