git分支

git使用手册：https://git-scm.com/book/zh/v1/ 一、分支 　　1、查看所有本地分支 　　　　git branch 　　2、查看所有本地分支和远程分支 　　　　git branch -a 　　3、查看本地分支和远程分支的对应关系 　　　　git branch -vv 　　4、查看远程分支对应远程库路径 　　 git remote -v 　　5、创建/删除本地分支 　　　　git branch local-name 以当前分支为基础创建名为local-name的本地分支 　　　　git checkout -b local-name 以当前分支为基础创建本地分支local-name并切换到该分支 　　　　git branch -d 如果有未合并的提交，不会删除 　　　　git branch -D 强制删除，如果有未合并的提交也删除 　　6、设置本地分支与远程分支的追踪关系 　　 git branch --set-upstream-to=远程库名/分支名 　　7、以远程库为基础创建本地分支 　　　　git checkout -b localbranch remotebranch 创建本地分支，以remotebranch为开始。同时也建立了本地分支和远程分支的关系。 　　　　该方法与5相比更加方便，因为5是以当前分支为基础创建新分支，而远程分支是其他分支

3 月，跳不动了？>>> 问题： I'd like to move the last several commits I've committed to master to a new branch and take master back to before those commits were made. 我想将我已承诺掌握的最后几个提交移动到新的分支，并在做出这些提交之前将master重新带回去。 Unfortunately, my Git-fu is not strong enough yet, any help? 不幸的是，我的Git-fu还不够坚固，有什么帮助吗？ Ie How can I go from this 即我该如何去 master A - B - C - D - E to this? 对此吗？ newbranch C - D - E / master A - B 解决方案： 参考一： https://stackoom.com/question/6pf9/使用Git将最新提交移至新分支 参考二： https://oldbug.net/q/6pf9/Move-the-most-recent-commit-s-to-a-new-branch-with-Git 来源： oschina 链接： https://my.oschina.net/u/3797416/blog

3 月，跳不动了？>>> 1. 假定原作者的名称叫gittest, 我叫uniquejava. 原作者新建了一个项目叫nocrazy。 于是路径为gittest/nocrazy 做了两次提交 提交一： a.txt this is a 提交二：b.txt this is b. 2. 我cyper某天fork了这个项目，于是有origin指向uniquejava/nocrazy, 并且新增一个upstream指向原作者gittest/nocrazy $ git clone https://git.oschina.net/uniquejava/nocrazy.git $ cd nocrazy ➜ nocrazy git:(master) $ git remote add upstream https://git.oschina.net/gittest/nocrazy.git ➜ nocrazy git:(master) $ git remote -v origin https://git.oschina.net/uniquejava/nocrazy.git (fetch) origin https://git.oschina.net/uniquejava/nocrazy.git (push) upstream https://git.oschina.net/gittest/nocrazy

TortoiseGit菜单概览： p.s. 安装TortoiseGit后，请先按照 TortoiseGit密钥设置 教程完成SSH密钥配置 下面逐一讲解以上菜单： Git同步菜单，主要用来跟服务器进行同步操作（pull/push）; 也可以在该窗口进行commit或查看log等操作; Git提交工菜单，当有文件被改动时，在被改动文件（或者其上层目录）上右键选择此菜单，会弹出提交窗口，如下图：填写信息，点击OK，提交成功。 p.s. 提交成功后，可以直接点击push，将修改推送到服务器，如下图： Git拉取，从服务器上获得更新，这个简单，如下图： p.s. 该操作会拉取(fetch)更新到本地仓库并将更新合并(merge)到项目中去，实际上包括fetch和merge两步操作; Git拉取，只从服务器获得更新到本地仓库中，并不会合并到项目中去，要合并到项目中去还需要执行merge操作，麻烦，一般不用，不多作介绍; Git推送，将提交到本地仓库的修改推送到服务器(远程仓库)，这个简单，如下图： 以上两个操作都是用来进行文件对比，一般在需要对比的文件上右键，选择diff即可将工作区文件与本地仓库中该文件进行差异对比，主要用来查看改动了啥, 不多作介绍; 查看日志，如下图： 在这里可以选择重置到历史版本，如下图： 在弹出窗口选择重置方式，点击OK，即可回到选择的历史版本： 可选择项说明：

Git常用命令 init: 在本地创建一个新的库 clone: 从服务器克隆代码到本地（将所有代码下载） status: 查看当前代码库的状态 add: 将本地文件添加到本地仓库 commit: 将代码提交到本地仓库 push: 将代码推送到远程仓库 pull: 将远程仓库的代码拉取到本地（只更新与本地不一样的代码） branch: 分支管理 checkout:切换分支 / 代码回滚 / 代码还原 merge: 合并分支 log: 查看提交历史 diff: 差异对比 remote: 远程库管理 Github 的使用 版本控制及代码管理 分支类型　　 master: 主干分支，代码经过严格测试，最稳定，可以随时上线 develop: 开发分支，合并了各个开发者最新完成的功能，经过初步测试，没有明显BUG feature: 功能分支，开发中的状态，代码最不稳定，开发完成后需要合并到develop分支 Pull Request: 拉取请求 开发者自己提交Pull Request 通知团队成员来合并自己提交的代码。 通过此方式可以将合并过程暴露给团队成员，让代码在合并之前可以被团队其他成员审核, 保证代码质量量。 Code Review: 代码审核 代码逻辑问题 算法问题 错误的使用方式 代码风格及规范问题 代码开发、管理、合并流程 来源： https://www.cnblogs.com

Git主要优点有 分布式存储 , 本地仓库包含了远程仓库的所有内容 . 安全性高 , 远程仓库文件丢失了也不怕 优秀的分支模型 , 创建/合并分支非常的方便 方便快速 , 由于代码本地都有存储 , 所以从远程拉取和分支合并时都非常快捷 　　当分支过多时 , 如何管理这些分支呢 ? 我们团队采用了Git Flow的模式 GitFlow的常用分支 master 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改 另外所有在master分支的推送应该打标签做记录,方便追溯 例如release合并到master , 或hotfix合并到master develop 主开发分支 , 基于master分支克隆 包含所有要发布到下一个release的代码 该分支为只读唯一分支 , 只能从其他分支合并 feature功能分支完成 , 合并到develop(不推送) develop拉取release分支 , 提测 release/hotfix 分支上线完毕 , 合并到develop并推送 feature 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发 功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)

远程分支上存在本地分支中不存在的提交，往往是多人协作开发过程中遇到的问题，可以先fetch再merge，也就是pull，把远程分支上的提交合并到本地分支之后再push。 如果你确定远程分支上那些提交都不需要了，那么使用如下命令，强行让本地分支覆盖远程分支。 git push origin master -f 来源： CSDN 作者： energy_百分百 链接： https://blog.csdn.net/lch551218/article/details/104846273

创建 dev 分支，然后切换到 dev 分支： $ git checkout -b dev 上面语句等于下面这条 $ git branch dev 创建分支 $ git checkout dev 切换到分支 $ git branch 查看分支，*表示当前分支 * dev master 接下来对分支进行提交 $ git add readme.txt $ git commit -m "branch test" 提交成功后切换回master分支 $ git checkout master 把分支dev合并到master分支上 $ git merge dev 删除分支 $ git branch -d dev 小结 Git鼓励大量使用分支： 查看分支： git branch 创建分支： git branch <name> 切换分支： git checkout <name> 创建+切换分支： git checkout -b <name> 合并某分支到当前分支： git merge <name> 删除分支： git branch -d <name> 来源： oschina 链接： https://my.oschina.net/u/2666706/blog/655919

Pull Requests 是 Bitbucket 上方便开发者之间协作的功能。提供了一个用户友好的 Web 界面，在集成提交的变更到正式项目前可以对变更进行讨论。 开发者向团队成员通知功能开发已经完成， Pull Requests 是最简单的用法。开发者完成功能开发后，通过 Bitbucket 账号发起一个 Pull Request 。这样让涉及这个功能的所有人知道，要去做 Code Review 和合并到 master 分支。 但是， Pull Request 远不止一个简单的通知，而是为讨论提交的功能的一个专门论坛。如果变更有任何问题，团队成员反馈在 Pull Request 中，甚至 push 新的提交微调功能。所有的这些活动都直接跟踪在 Pull Request 中。 相比其它的协作模型，这种分享提交的形式有助于打造一个更流畅的工作流。 SVN 和 Git 都能通过一个简单的脚本收到通知邮件；但是，讨论变更时，开发者通常只能去回复邮件。这样做会变得杂乱，尤其还要涉及后面的几个提交时。 Pull Requests 把所有相关功能整合到一个和 Bitbucket 仓库界面集成的用户友好 Web 界面中。 解析 Pull Request 当要发起一个 Pull Request ，你所要做的就是请求（ Request ）另一个开发者（比如项目的维护者），来 pull

Pull Requests 是 Bitbucket 上方便开发者之间协作的功能。提供了一个用户友好的 Web 界面，在集成提交的变更到正式项目前可以对变更进行讨论。 开发者向团队成员通知功能开发已经完成， Pull Requests 是最简单的用法。开发者完成功能开发后，通过 Bitbucket 账号发起一个 Pull Request 。这样让涉及这个功能的所有人知道，要去做 Code Review 和合并到 master 分支。 但是， Pull Request 远不止一个简单的通知，而是为讨论提交的功能的一个专门论坛。如果变更有任何问题，团队成员反馈在 Pull Request 中，甚至 push 新的提交微调功能。所有的这些活动都直接跟踪在 Pull Request 中。 相比其它的协作模型，这种分享提交的形式有助于打造一个更流畅的工作流。 SVN 和 Git 都能通过一个简单的脚本收到通知邮件；但是，讨论变更时，开发者通常只能去回复邮件。这样做会变得杂乱，尤其还要涉及后面的几个提交时。 Pull Requests 把所有相关功能整合到一个和 Bitbucket 仓库界面集成的用户友好 Web 界面中。 解析 Pull Request 当要发起一个 Pull Request ，你所要做的就是请求（ Request ）另一个开发者（比如项目的维护者），来 pull