学习如何像专业人士一样在团队中使用 Git 和 GitHub(第 2 部分)
在本教程的上一部分中,我们了解了哈利和赫敏如何决定构建一款 SaaS 应用,让人们可以在线制作自己的魔药并与世界分享。他们将其命名为Potionfy。
赫敏创建了一个远程存储库,然后创建了一个issue
来解决构建登陆页面的任务,以及哈利如何在本地处理该任务并在完成工作后issue
创建一个。pull request
您可以在此处阅读本教程的第一部分:
现在,我们将看到:
- 赫敏如何审查哈利的准则,
- 代码如何合并到主分支上,
- 使用分支机构的决定
develop
, - 团队如何在开发分支中工作并将更改合并到主分支中,
- 以及团队如何解决合并冲突。
代码审查
步骤 1:创建评论
赫敏已经完成了市场推广工作,现在有时间审核哈利的代码了。为此,她打开了 GitHub 代码库,点击标签页,Pull requests
找到了哈利的拉取请求。
单击它之后,她又单击Commits
选项卡,最后单击 Harry 的最后一次提交(这只是访问拉取请求中修改的文件的一种方式)。
她对这段代码不太确定<h1>
,于是点击了鼠标悬停在那行代码上时出现的加号图标,并给哈利写了一条评论。最后,她点击了Start a review
按钮。
由于她对代码没有其他评论,她现在单击Review changes
按钮以使团队其他成员可以看到该评论。
您可以在“审查拉取请求中的提议更改”文章中找到有关进行审查的更多信息。
第 2 步:处理审核并创建代码变更
哈利检查了他的拉取请求并发现了一个新的对话:赫敏的评论。
哈利回答了赫敏的评论并点击了Resolve conversation
按钮。
现在对话已经解决,赫敏可以提交评论,表明有要求的更改,以便哈利可以真正地进行更改。
注意:这只是 GitHub 可以实现的审核流程的一个版本,它可能与您的团队选择处理它们的实际方式不同。
Harry 再次检查拉取请求并发现它已经Changes requested
。
步骤 3:实施变更
由于 Harry 喜欢在本地工作,因此他继续在自己创建的分支上工作以实现代码更改。
$ git checkout 1-add-landing-message
一旦他确定自己在正确的分支上工作,他就会对index.html
文件进行更改。
注意:为了简单起见,我们不在这里创建单独的 CSS 文件。
一旦 Harry 完成代码调整,他就会暂存更改,提交它们(确保包含id
问题,因为他仍在处理它),然后将它们推送到 GitHub。
$ git add -A
$ git commit -m "Add colour and remove text. #1"
$ git push
步骤 4:合并拉取请求
现在轮到赫敏了。她打开拉取请求,发现了一个新的提交:就是哈利提交并推送到 GitHub 的那个。
然后,她点击Files changed
选项卡并找到她建议在文件上实施的选项卡index.html
。
由于她对更改感到满意,因此她通过单击按钮Review changes
并选择Approve
选项来批准更改。
哈利看到他的拉取请求已被赫敏批准,于是他将其合并到项目的主分支中。
他决定不删除该分支,因为他想将其留在那里以供将来参考(尽管删除它是一个好主意)。
由于赫敏对问题的解决感到满意,她继续通过转到Issues
选项卡并单击Close issue
按钮来关闭它。
如果您想以图形方式查看到目前为止的整个过程,可以点击选项Insights
卡,然后点击Network
选项。您将能够实际看到分支和合并是如何执行的。
使用develop
分支
在实际项目中,不建议像您之前看到的那样将更改合并到主分支。您不是直接在main
分支(通常称为production
)上工作,而是在一个分支上工作develop
。您将从该分支中分支出问题develop
,然后再将它们合并回该develop
分支。一旦解决了一组问题,该develop
分支将被合并到main
(或production
)分支,这通常表示应用程序中的版本更改。
Hermione 意识到了这一点,现在落地页已经上线并可供客户访问,她决定保留原来的生产环境,并在开发分支上工作。为此,她develop
从原来的分支中创建了一个分支main
,这样她和 Harry 就可以在该分支上工作,而不会影响生产环境。
合并冲突
Hermione 想在落地页添加一个新功能:一个用于收集客户电子邮件的表单。为此,她创建了一个新问题。
问题创建后,Harry 决定开始处理它。为此,他从现有develop
分支(通过在 GitHub 界面上选择该分支)分支出一个新的分支,名为3-email-form
(在分支前面加上问题编号,以明确该分支与问题的关系)。
然后,他将该分支拉到本地并开始对其进行处理。
$ git pull
$ git checkout 3-form
Harry 决定在文件中添加一个简单的表格index.html
:
<form action="mailto:hermione@potionfy.com" method="post" enctype="text/plain">
Name:<br>
<input type="text" name="name"><br>
E-mail:<br>
<input type="text" name="mail"><br>
<input type="submit" value="Send">
<input type="reset" value="Reset">
</form>
注意:此代码仅用于举例说明 Harry 如何处理文件,而不是实际构建此类表单的方式。
Harry 使用该Contact form. #3
消息在本地暂存并提交他的更改。
$ git add -A
$ git commit -m "Contact form. #3"
$ git push
在哈利创建新的拉取请求之前,赫敏决定自己在文件上为该表单创建一个占位符index.html
。为此,她创建了一个develop
名为的新分支3-email-form-placeholder
。
为了处理这个index.html
文件,她使用了 GitHub 在线代码编辑器(本质上就是网页版的 VSCode)。要打开它,她只需按下.
键盘上的 键,GitHub 页面就会变成 VSCode 界面(就像变魔术一样😉)。
然后她继续将以下代码添加到文件中:
<form action="mailto:harry@potionfy.com" method="post" enctype="text/plain">
</form>
保存文件后,她使用 VSCode 图形界面直接在浏览器窗口上提交更改:
提交完成后,她再次打开 GitHub 并决定创建自己的拉取请求并将她的更改合并到develop
分支。
另一方面,Harry 还决定创建一个pull request
以将他的更改合并到develop
分支中。
此时,GitHub 会让他知道他的拉取请求将无法自动合并到develop
分支。
Harry 认为他的分支不再反映develop
分支的状态,并且分支develop
已经发生了变化,因为其他人合并了影响index.html
他正在处理的文件的更改。尽管如此,他还是创建了一个拉取请求。
接下来他看到的是 GitHub 通知他修改的文件存在冲突的方式。他继续点击Resolve conflicts
按钮。
他现在可以看到确实index.html
已被修改,并且对该文件所做的更改正在影响他自己修改的行。
有关解决冲突的更多信息,您可以阅读GitHub 上的解决合并冲突文章。
Harry 继续直接在 GitHub 网站上修改文件以删除冲突的更改,然后单击Mark as resolved
按钮。
一旦冲突被标记为已解决,他就点击Commit merge
按钮。
最后,他的分支没有冲突,他可以合并他的拉取请求(假设赫敏审查了他的代码并批准了它,就像她之前做的那样)。
当团队成员在不同分支上工作,而这些分支又影响同一个文件时,经常会发生冲突。避免合并冲突的一个好方法是,在分支pull
上发出请求develop
,将更新后的develop
分支合并到您正在处理的分支中,然后执行 ,再push
执行pull request
。
$ git branch
x-my-branch # This is an example name
$ git checkout develop
$ git pull
$ git checkout x-my-branch
$ git merge develop
# You make some changes on the files of the x-my-branch branch
$ git add -A
$ git commit -m "<a message>"
$ git push
最后的想法
在完成落地页的制作后,哈利和赫敏成功收集了大量潜在客户的电子邮件地址,并继续开发他们的MVP。他们成功从当地一家风险投资公司获得了资金,目前正在招聘其他开发人员,将Potionfy推向公众。我相信他们很乐意看看你的简历,考虑聘请你加入他们的公司,祝你好运!
🗞️新闻通讯 - 如果您想了解我的最新文章和有趣的软件开发内容,请订阅我的新闻通讯。如果在 2021 年 11 月订阅人数超过 100 人,我将向订阅者赠送一门 Udemy 课程!
🐦TWITTER——在Twitter上关注 我。
文章来源:https://dev.to/colocodes/learn-how-to-use-git-and-github-in-a-team-like-a-pro-part-2-11j