文章目录
第一阶段:注册设置阶段
问题一:在使用git时配置的全局邮件和用户名作为区分用户,如何区分
关键字:区分用户,用户识别。
GitHub 使用用户邮件地址区分 Git 提交。 如果你在自己的提交中使用了多个邮件地址,希望 GitHub可以正确地将它们连接起来,你需要在管理页面的 Emails 部分添加你拥有的所有邮箱地址。
在setting页面添加邮箱,由于提交识别用户。
作用:这样所有的邮箱会体现是一个用户的操作。( 当 GitHub 发现任意版本库中的任意提交信息包含了这些地址,它就会将其链接到你的账户)
第二阶段:使用问题阶段
问题一:如何对项目作出贡献步骤
操作流程总览:
通过这种方式,项目的管理者不再需要忙着把用户添加到贡献者列表并给予他们推送权限。 人们可以派生这个项目,将修改推送到派生出的项目副本中,并通过创建合并请求(Pull Request)来让他们的改动进入源版本库
流程通常如下:
- 从 master 分支中创建一个新分支
- 提交一些修改来改进项目
- 将这个分支推送到 GitHub 上
- 创建一个合并请求
- 讨论,根据实际情况继续修改
- 项目的拥有者合并或关闭你的合并请求
操作步骤:
一:情形:你想要参与某个项目,但是并没有推送权限,这时可以对这个项目进行“派生”。 派生的意思是指,GitHub 将在你的空间中创建一个完全属于你的项目副本,且你对其具有推送权限。
关键字:没有push 权限,想要参与
解决:使用fork(派生) 建立一个项目副本
实例:
首先,单击“Fork”按钮来获得这个项目的副本。
这里修改后提交的内容
如果你点击了那个绿色按钮,就会看到一个新页面,在这里我们可以对改动填写标题和描述,让项目的拥有者考虑一下我们的改动。通常花点时间来编写个清晰有用的描述是个不错的主意,这能让作者明白为什么这个改动可以给他的项目带来好处,并且让他接受合并请求
提交后在原来的仓库中多出了pull request1 请求。
此时视角转到项目的拥有者角度
项目管理者受到请求如何处理,这里整个流程转到
合并请求讨论页面
pull request 下的具体页面进行操作
接下来可能会通过电子邮件进行互动,就像我们在 分布式 Git 中提到的工作流程那样,但是在 GitHub,这些都在线上完成。项目的拥有者可以审查修改,只需要单击某一行,就可以对其发表评论.
当维护者发表评论后,提交合并请求的人,以及所有正在(Watching)这个版本库的用户都会收到通知。(这些人都会收到项目管理者的邮件的每个评价都会发送一个一份邮件)我们待会儿将会告诉你如何修改这项设置。现在,如果 Tony 有开启电子邮件提醒,他将会收到这样的一封邮件
每个人都能在合并请求中发表评论。
在合并请求讨论页面 里我们可以看到项目拥有者对某行代码发表评论,并在讨论区留下了一个普通评论。你可以看到被评论的代码也会在互动中显示出来。
讨论完后,贡献者根据要求再次修该代码并且提交,在讨论提交界面会自动添加跟踪代码贡献者新的提交,在讨论界面
此时,项目拥有者可以直接merge 或者如果你需要,你还可以将分支拉取并在本地合并。如果你将这个分支合并到 master 分支中并推送到
GitHub,这个合并请求会被自动关闭。
这里的merge都是no-fast-forward都会留下合并提交记录的。
补充
问题一:pull request提交过于迟缓,导致原项目与提交的项目发生了冲突,此时应该如何办?
关键字:提交冲突,原分支,提交分支
问题描述:
如果你的合并请求由于过时或其他原因不能干净地合并,你需要进行修复才能让维护者对其进行合并。GitHub会对每个提交进行测试,让你知道你的合并请求能否简洁的合并。
解决方法:
如果项目贡献者看到了像不能进行干净合并中的画面,你就需要修复你的分支让这个提示变成绿色,这样维护者就不需
方式评价:你有两种方法来解决这个问题。你可以把你的分支变基到目标分支中去(通常是你派生出的版本库中的 master
分支),或者你可以合并目标分支到你的分支中去。
GitHub上的大多数的开发者会使用后一种方法,基于我们在上一节提到的理由:我们最看重的是历史记录和最后的合并,变基除了给你带来看上去简洁的历史记录,只会让你的工作变得更加困难且更容易犯错。
git rebase or pit pull 两种方式
操作步骤:
说明:以下步骤是跟着文档自己走一遍出来的
我的
前提:区别:自己是在dev 分支进行修改和提交的解决冲突的
关键字:dev 分支冲突修改