-
pull request 具体步骤
将 原开源项目仓库 fork到 自己的服务器 上；
将 自己服务器 上的 该仓库 clone 到 本地；
本地修改；
push 回 自己服务器 上的 仓库；
从 自己服务器 上的 仓库，向 原开源项目仓库 发起 pull request (合并申请）；
开源项目维护者 会review 你的 puul request，展开讨论或者修改之；
一旦通过审核，开源项目维护者 合并 该分支 到 正式仓库 然后 关闭 合并申请。
查看全部 -
1、创建一个分支。
2、添加新版本。
3、（核心）开启一个pull request（拉取请求），pull request用来发起对你做的各个版本的讨论。因为pull request与底层git仓库代码是紧密相关的，任何人都能确切地看到一旦他接受了你的pull request会有哪些代码合并进来。
4、讨论和代码审核。
5、合并分支，然后部署。
查看全部 -
github flow是一个非常轻便的，基于分支的工作流。非常适合代码部署非常频繁的团队和项目。
查看全部 -
不要在公共分支使用rebase
本地和远端对应同一条分支,优先使用rebase,而不是merge
查看全部 -
merge branches之后，合并就成功了，master中拥有了idea中的所有代码。底层历史变成了如图所示。新生成了一个C5，这是一个“融合版本”（merge commit）这个合并挺特殊，里面一般没有修改内容，它的作用主要是把两个分支合并起来。怎么合并呢？把master的内容sync到github.com上，然后查看一下这个merge commit，会发现它有两个parent。
merge之后，master分支指针指向了merge commit，也就自动拥有了idea分支上的c3这个版本了。idea分支一般这会儿就可以删除了。
查看全部 -
·····SD
查看全部 -
版本控制入门—github>
老师网址：github.com/happypeter
git---傻子 ，版本控制工具
开源文化---github.com(2008年诞生)，项目的托管。
Git与Linux之父，Linus
查看全部 -
学习使我快乐查看全部
-
github核心：团队协作和代码版本控制
GitHub flow 团队协作流程
协作流程的核心： pull request (目的：引发讨论和代码审核)
查看全部 -
合并两种方式：
merge commit 和 rebase 有区别
版本冲突原因：
不同分支修改同一文件，git无法判断该文件是由哪个分支修改，因此提示冲突。需要程序员手动解决冲突。
解决冲突：
把冲突部分还原
更新代码
修改后
再合并
查看全部 -
master分支指向新的版本
分支类似一节一节的竹子，控制版本线
新建分支不是拷贝master分支，是重新创建了一个指针指向新版本
原则上：
master分支存放的代码用于是可线上运行的无问题代码
新建分支用于存放持续开发中的测试代码
新建分支不会污染原master分支的代码（新建分支的目的）
查看全部 -
新建项目
第一步 新建代码仓库 new repository
添加文件 create new file
项目中相关介绍：
commit：版本操作，有几个版本
commit new file 提交新加文件到下一个版本（下方填写版本说明）
版本号：40位，可以用前几位作为简写形式，能区分即可
parent：上一个版本的版本号
版本之间通过父子版本号构成版本线连接在一起
查看全部 -
冲突的部分被<<< >>>包围，被=======分隔；
head代表本地\当前分支，origin/master代表远端\非当前；
删掉冲突标识符，选择二者其一的方案，提交版本解决冲突。
同一分支，在本地分支commit前先同步，发现别人在此分支上提交了新
版本： 1，与我将要提交的版本无冲突，则本地同步后直接融合，称为变基（rebase)
2、与我将要提交的版本有冲突，则本地同步后发生冲突，通过上文方法解决冲突，提交解决冲突后的版本，称为融合（merge)
查看全部 -
pull request url：repoName/pull/id
查看全部 -
github 官方hello-world
https://guides.github.com/activities/hello-world/
查看全部
举报