GitHub for windows使用教程（三） 团队协作流程
團(tuán)隊(duì)協(xié)作流程
認(rèn)識(shí)Flow
GitHub Flow是一個(gè)輕量級(jí)的，基于分支的工作流程，支持團(tuán)隊(duì)和部署在那里的定期做項(xiàng)目。
為團(tuán)隊(duì)成員寫入權(quán)限
在我們的隊(duì)友添加一個(gè)寫的權(quán)限，這樣我們的隊(duì)友才能很好的修改代碼。
我們打開網(wǎng)頁(yè)上的GitHub,點(diǎn)擊settings,
之后我們找到collaborators，這里會(huì)讓我們驗(yàn)證密碼，之后就有添加合作者的選項(xiàng)。這樣我們就能添加我們的小伙伴了！
這樣我們就添加了新的小伙伴，新的小伙伴有著同樣的權(quán)限去修改和管理代碼。
此時(shí)我們就會(huì)看到我的小伙伴wevan的github主頁(yè)上就會(huì)出現(xiàn)關(guān)于我創(chuàng)建的First的各種通知。
創(chuàng)建分支
在我們創(chuàng)建一個(gè)叫add new function的分支。
創(chuàng)建一個(gè)分支
Create a branch
當(dāng)你工作的一個(gè)項(xiàng)目，你會(huì)在任何給定的時(shí)間有一堆不同的功能或正在進(jìn)行的想法 - 其中一些是蓄勢(shì)待發(fā)，而另一些則不是。分支的存在是為了幫助你管理這個(gè)工作流程。
When you’re working on a project, you’re going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.
當(dāng)您在項(xiàng)目中創(chuàng)建一個(gè)分支，你創(chuàng)造一個(gè)環(huán)境，在那里你可以嘗試新的想法。你讓一個(gè)分支的更改不會(huì)影響主分支，讓你可以自由進(jìn)行實(shí)驗(yàn)，并提交更改，在你的分支將不會(huì)被合并，直到它準(zhǔn)備好知識(shí)安全的人所正在與合作進(jìn)行審查。
When you create a branch in your project, you’re creating an environment where you can try out new ideas. Changes you make on a branch don’t affect the master branch, so you’re free to experiment and commit changes, safe in the knowledge that your branch won’t be merged until it’s ready to be reviewed by someone you’re collaborating with.
ProTip
分支在Git中是一個(gè)核心概念，整個(gè)GitHub的流量是基于它。這里只有一個(gè)規(guī)則：在任何主分支總是部署。
Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There’s only one rule: anything in the master branch is always deployable.
正因?yàn)槿绱?#xff0c;這是非常重要的一個(gè)功能或修復(fù)工作時(shí)，你的新分支關(guān)老爺?shù)膭?chuàng)建。您的分支名應(yīng)該是描述（例如，重構(gòu)的身份驗(yàn)證，用戶的內(nèi)容緩存鍵，使視網(wǎng)膜-化身），以便其他人可以看到正在處理。
Because of this, it’s extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.
來自GitHub Flow
添加提交
我們首先把分支切換到新的分支上add new function
修改新的版本
填寫好新的Summary和Description，提交新的版本并同步。
這樣小伙伴登陸到GitHub上就看到了就可以清楚的看到一切的修改。
添加提交
Add commits
一旦你的分支已經(jīng)建立，現(xiàn)在是時(shí)候開始進(jìn)行更改。無論何時(shí)添加，編輯或刪除一個(gè)文件，你作出承諾，并將其添加到您的分支。提交加入這一過程保持你的進(jìn)步軌跡，你在一個(gè)特性分支工作。
Once your branch has been created, it’s time to start making changes. Whenever you add, edit, or delete a file, you’re making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.
還承諾創(chuàng)建工作的透明歷史，其他人可以按照理解你做了什么，以及為什么。每次提交都有一個(gè)關(guān)聯(lián)的提交信息，這是解釋為什么一個(gè)特定的變化作出了說明。此外，每次提交被認(rèn)為是變革的一個(gè)獨(dú)立單元。這使您可以回滾的變化，如果發(fā)現(xiàn)錯(cuò)誤，或者如果你決定在一個(gè)不同的方向前進(jìn)。
Commits also create a transparent history of your work that others can follow to understand what you’ve done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.
ProTip
提交信息是重要的，特別是因?yàn)镚it跟蹤更改，然后將它們顯示為承諾一旦他們推到服務(wù)器。通過字跡清晰提交信息，你可以更容易為其他人跟著，并提供反饋。
Commit messages are important, especially since Git tracks your changes and then displays them as commits once they’re pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.
來自GitHub Flow
打開一個(gè)pull請(qǐng)求
這個(gè)是整個(gè)流程中比較關(guān)鍵的一步，發(fā)布Pull Request。
點(diǎn)擊客戶端或者網(wǎng)頁(yè)上的Pull Request發(fā)布。
我們這里點(diǎn)擊Pull Request
我們填寫好必要的說明性文字
點(diǎn)擊Send Pull Request
他既然讓我們到GitHub上看，我們就聽他的，點(diǎn)擊，進(jìn)入。
我們發(fā)現(xiàn)小伙伴已經(jīng)在下面留言了！
討論和審核你的代碼
你的小伙伴開始對(duì)你的代碼討論，修改，迭代。
討論和審查你的代碼
Discuss and review your code
一旦拉入請(qǐng)求已被打開，人或團(tuán)隊(duì)審查您的變化可能有疑問或意見。也許編碼風(fēng)格不匹配項(xiàng)目的指導(dǎo)方針，改變?nèi)鄙賳卧獪y(cè)試，或者也許一切看起來不錯(cuò)，道具都是為了。引入請(qǐng)求旨在鼓勵(lì)并捕獲這種類型的對(duì)話。
Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn’t match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.
您還可以繼續(xù)推送到你的分支在你提交的討論和反饋光。如果有人評(píng)論說，你忘了做某件事，或者如果在代碼中的錯(cuò)誤，你可以在你的分支修復(fù)它，推高的變化。GitHub上會(huì)顯示新的提交和其他任何意見，你可能會(huì)收到統(tǒng)一拉請(qǐng)求視圖。
You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
ProTip
拉請(qǐng)求的意見都寫在降價(jià)，所以你可以插入圖片和表情符，使用預(yù)先格式化的文本塊，等輕質(zhì)格式。
Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.
部署
部署
Deploy
一旦你拉的請(qǐng)求進(jìn)行了審查和部門通過你的測(cè)試，您可以部署您的更改，以驗(yàn)證他們的生產(chǎn)。如果你的分支造成的問題，您可以通過部署現(xiàn)有的主投產(chǎn)回滾
Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
合并
合并分支我們之前已經(jīng)說過，這里就不再贅述。
合并
Merge
現(xiàn)在，您的更改在生產(chǎn)中得到了驗(yàn)證，現(xiàn)在是時(shí)候你的代碼合并到主分支。
Now that your changes have been verified in production, it is time to merge your code into the master branch.
合并后，引入請(qǐng)求保護(hù)的歷史變遷到您的代碼記錄。因?yàn)樗麄兪撬阉鞯?#xff0c;他們不讓任何人回去的時(shí)間理解為什么以及如何決定了。
Once merged, Pull Requests preserve a record of the historical changes to your code. Because they’re searchable, they let anyone go back in time to understand why and how a decision was made.
ProTip
通過將某些關(guān)鍵字到您的拉請(qǐng)求的文本，你可以用代碼相關(guān)聯(lián)的問題。當(dāng)你拉入請(qǐng)求合并，相關(guān)問題也將被關(guān)閉。例如，輸入短語(yǔ)關(guān)閉＃32將關(guān)閉在倉(cāng)庫(kù)中發(fā)行數(shù)量32。欲了解更多信息，請(qǐng)查看我們的幫助文章。
By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository. For more information, check out our help article.
注意：英文翻譯為機(jī)器翻譯，可能有翻譯錯(cuò)誤的地方，建議大家盡可能看英文
總結(jié)
基本的GitHub教程就算寫完了，已有如果在有就是一些GitHub上的一些使用小技巧了。
原文：http://youngxhui.github.io/2016/05/15/GitHub-for-windows%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B%EF%BC%88%E4%B8%89%EF%BC%89/
總結(jié)
以上是生活随笔為你收集整理的GitHub for windows使用教程（三） 团队协作流程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GitHub for Windows使用
- 下一篇： 坐标系统及投影概述