git 拉取github_使用GitHub的GIT拉取请求

git 拉取github

旧习惯

我们已经使用git一年多了。 SCM是从SVN迁移而来的，它拥有所有的历史。 我们的习惯也被迁移了。 我们的流程非常简单： master分支是我们从中部署代码的地方。 在处理要素时，我们创建要素分支。 几个人可以在这个分支上工作。 有些创建私有本地分支。 有些没有。 代码审查是一对一完成的。 一位成员要求另一位成员加入并浏览代码。

向团队介绍拉取请求

最近，在队友“ 拉取请求”概念的帮助下，我介绍了团队。 花费一些时间来掌握方法并看到好处。 但是，我已经开始看到协作，代码质量和编码行为方面的改进。

好处

1. 更好的协作
   当一个人进行更改并要求拉取请求时，整个团队都可以看到更改。 每个人都可以发表评论并发表评论。 在更改合并到主分支之前对其进行讨论。
2. 代码所有权
   每个人都知道更改，任何人都可以检查和评论。 结果是每个人都可以“拥有”代码。 它可以帮助每个团队成员参与编码和检查任何代码。
3. 分支机构
   在合并之前，需要对代码进行额外的修订。 合并功能后，可以删除分支（应删除IMHO）。 git历史记录（日志）更加清晰。 （这完全取决于评论的质量）
4. 改善代码质量
   我发现即使在代码审查之前 ，它也可以提高代码质量。 人们知道每个人都可以观看时， 人们不想引入错误的代码。
5. 更好的代码审查
   自项目开始以来，我们一直在进行广泛的代码审查。 但是，正如我上面所解释的，我们是一对一完成的，通常作者会向审阅者解释代码。 在我看来，这样做会错过代码审查的优势。 当作者向审阅者解释材料时，代码审阅的质量降低。 使用拉取请求，如果审阅者不了解某些内容，则意味着代码可能不够干净。 因此，更多的评论和注释，从而使代码更好。
6. 指导
   当长者一对一地对初中进行代码审查时，没有其他人看到它。 对于大四生来说，要向案例展示关于代码外观和代码审查方式的期望更加困难。 （当然，还有其他方式传递它，例如代码dojos。而且，虽然是一对一的，但也可以成对编程）。 通过在请求请求中评论评论，团队可以了解重要内容以及如何进行评论。 每个人都可以从其他团队成员的审查中受益。
7. 改善git使用习惯
   当某人与整个团队合作时，他/她可能会写出更好的git注释。 由于没有人希望读取大量的diff行，因此提交将更小，更频繁。 因此，没有人想让团队“沮丧”。 使用拉取请求会强制使用分支，从而改善git历史记录。

异议

其他人可能将此部分称为缺点 。 但是从我的角度来看，更多的是抱怨“为什么我们需要这个？ 我们对目前的情况很满意”

1. 我已经收到太多电子邮件了
   好吧，这是真的。 使用请求请求，我们开始收到更多电子邮件，这很烦人。
   噪音太大了。 我可能没有注意到重要的电子邮件。 答案很简单： 如果您是此功能的一部分，那么此邮件很重要，因为它提到了您正在处理的某些部分中的代码更改。 如果您想停止接收有关此特定请求请求的电子邮件，可以要求将其静音。
   

   静音线程

3. 如果我们开始发送电子邮件，我们将停止彼此交谈
   我不同意这一说法。 这可能会减少一对一的审查讨论。 但是根据我的（简短）经验，它改善了我们的口头讨论。 口头讨论是在审阅者观看代码更改后进行的。 如果审阅者不了解某些内容，则只有她才能与开发人员联系。 一对一的讨论更加有效和“切题”。
4. 啊！ 我需要考虑更好的提交意见。 现在我还有更多想
   这很好，不是吗？ 通过使用拉取请求，每个团队成员都需要改进在提交中编写注释的方式。 它还将改善git习惯。 在较短的时间内进行较小的提交。
5. 很难理解。 我希望其他开发人员会向我解释其意图
   通过撰写作者的文章，我们不会错过代码审查的重要优点吗？ 我的意思是，如果我需要解释代码的功能，那么我们最好修复该代码。 因此，如果很难理解，我可以写我的评论，直到它有所改善。

怎么样？

在本节中，我将简要说明我们选择使用请求请求的方式。 屏幕快照是从GitHub截取的，尽管BitBucket也支持它。

从“主”分支分支

我不是故意写“主人”的。 假设我在一个名为FEATURE_A的分支中处理某些功能（对我来说，这是主分支）。 该分支是从master创建的。 假设我需要在FEATURE_A中实现某种子功能。 示例（极其简单）：将toString添加到Person类。 然后，我将创建一个分支（本地在FEATURE_A之外）：

# On branch FEATURE_A, after pull from remote do:
# git checkout -b <branch-name-with-good-description>
git checkout -b FEATURE_A_add_toString_Person

# In order to push it to remote (GitHub), run this:
# git push -u origin <branch-name-with-good-description>
git push -u origin FEATURE_A_add_toString_Person
# Pushing the branch can be later

提出拉取请求

在分支上进行一些工作并将其推送到GitHub后，我可以请求Pull Request。 有几种方法可以做到这一点。 我发现“最酷”的一个是使用GitHub中的按钮/链接来调用请求请求。 在网络上输入GitHub的存储库时，它会显示我推送到的最后一个分支的可单击符号。 发送请求请求后，所有团队成员将收到一封电子邮件。 如果您希望某人进行实际的代码检查，则还可以为其指定一个特定的人。

比较并提取请求

分配菜单

更改差异的分支

默认情况下，GitHub将要求对master分支进行拉取请求。 如上所述，有时（通常是？），我们将要针对某些功能分支而不是母版进行差异/合并。 在拉取请求对话框中，可以选择要与工作分支进行比较的分支。

编辑差异分支

代码审查与讨论

任何推送的代码都将添加到拉取请求中。 任何团队成员都可以添加评论。 您可以在讨论的底部添加。 并且，一个非常不错的选择是在特定的代码行上添加注释。

拉取请求中的几个提交

合并和删除分支

经过讨论和更多的推入代码，每个人都满意，并且可以合并该代码。 GitHub会告诉您是否可以将您的工作分支合并到该请求请求的主（diff）分支中。 有时分支不能自动合并。 在这种情况下，我们将在本地进行合并，修复冲突（如果有），然后再次推送。 我们试图记住经常这样做，所以通常GitHub会告诉我们分支可以自动合并。

分支可以自动合并

确认合并

合并拉取请求后，它将自动关闭。 完成后，可以删除分支。

合并/关闭屏幕

谁负责？

人们问

• 谁应该合并？
• 谁应该删除分支？

我们发现，发起拉取请求的人将合并和删除是最明智的。 只有在审阅者确定后，才能进行合并。

有用的git命令

这是我们使用的有用的git命令的列表。

# Automatically merge from one branch (from remote) to another
# On branch BRANCH_A and I want to merge any pushed change from BRANCH_B
git pull origin BRANCH_B

# show branches remotly
git remote show origin

# Verify which local branch, which is set to upstream can be deleted
git remote prune origin --dry-run

# Actual remove all tangled branches
git remote prune origin

# Delete the local branch
git branch -d <branch-name>

资源资源

https://help.github.com/articles/using-pull-requests
https://www.atlassian.com/git/workflows#!pull-request

请享用…

翻译自: https://www.javacodegeeks.com/2014/05/git-pull-requests-using-github.html

git 拉取github