團隊協作流程

認識Flow

GitHub Flow是一個輕量級的，基于分支的工作流程，支持團隊和部署在那里的定期做項目。

為團隊成員寫入權限

在我們的隊友添加一個寫的權限，這樣我們的隊友才能很好的修改代碼。
我們打開網頁上的GitHub,點擊settings,

之后我們找到collaborators，這里會讓我們驗證密碼，之后就有添加合作者的選項。這樣我們就能添加我們的小伙伴了！

這樣我們就添加了新的小伙伴，新的小伙伴有著同樣的權限去修改和管理代碼。
此時我們就會看到我的小伙伴wevan的github主頁上就會出現關于我創建的First的各種通知。

創建分支

在我們創建一個叫add new function的分支。

創建一個分支

Create a branch

當你工作的一個項目，你會在任何給定的時間有一堆不同的功能或正在進行的想法 - 其中一些是蓄勢待發，而另一些則不是。分支的存在是為了幫助你管理這個工作流程。

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.

當您在項目中創建一個分支，你創造一個環境，在那里你可以嘗試新的想法。你讓一個分支的更改不會影響主分支，讓你可以自由進行實驗，并提交更改，在你的分支將不會被合并，直到它準備好知識安全的人所正在與合作進行審查。

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中是一個核心概念，整個GitHub的流量是基于它。這里只有一個規則：在任何主分支總是部署。

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.

正因為如此，這是非常重要的一個功能或修復工作時，你的新分支關老爺的創建。您的分支名應該是描述（例如，重構的身份驗證，用戶的內容緩存鍵，使視網膜-化身），以便其他人可以看到正在處理。

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

一旦你的分支已經建立，現在是時候開始進行更改。無論何時添加，編輯或刪除一個文件，你作出承諾，并將其添加到您的分支。提交加入這一過程保持你的進步軌跡，你在一個特性分支工作。

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.

還承諾創建工作的透明歷史，其他人可以按照理解你做了什么，以及為什么。每次提交都有一個關聯的提交信息，這是解釋為什么一個特定的變化作出了說明。此外，每次提交被認為是變革的一個獨立單元。這使您可以回滾的變化，如果發現錯誤，或者如果你決定在一個不同的方向前進。

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

提交信息是重要的，特別是因為Git跟蹤更改，然后將它們顯示為承諾一旦他們推到服務器。通過字跡清晰提交信息，你可以更容易為其他人跟著，并提供反饋。

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

打開一個pull請求

這個是整個流程中比較關鍵的一步，發布Pull Request。

點擊客戶端或者網頁上的Pull Request發布。
我們這里點擊Pull Request

我們填寫好必要的說明性文字

點擊Send Pull Request

他既然讓我們到GitHub上看，我們就聽他的，點擊，進入。

我們發現小伙伴已經在下面留言了！

討論和審核你的代碼

你的小伙伴開始對你的代碼討論，修改，迭代。

討論和審查你的代碼

Discuss and review your code

一旦拉入請求已被打開，人或團隊審查您的變化可能有疑問或意見。也許編碼風格不匹配項目的指導方針，改變缺少單元測試，或者也許一切看起來不錯，道具都是為了。引入請求旨在鼓勵并捕獲這種類型的對話。

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.

您還可以繼續推送到你的分支在你提交的討論和反饋光。如果有人評論說，你忘了做某件事，或者如果在代碼中的錯誤，你可以在你的分支修復它，推高的變化。GitHub上會顯示新的提交和其他任何意見，你可能會收到統一拉請求視圖。

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

拉請求的意見都寫在降價，所以你可以插入圖片和表情符，使用預先格式化的文本塊，等輕質格式。

Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.

部署

部署

Deploy

一旦你拉的請求進行了審查和部門通過你的測試，您可以部署您的更改，以驗證他們的生產。如果你的分支造成的問題，您可以通過部署現有的主投產回滾

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.

合并

合并分支我們之前已經說過，這里就不再贅述。

合并

Merge

現在，您的更改在生產中得到了驗證，現在是時候你的代碼合并到主分支。

Now that your changes have been verified in production, it is time to merge your code into the master branch.

合并后，引入請求保護的歷史變遷到您的代碼記錄。因為他們是搜索的，他們不讓任何人回去的時間理解為什么以及如何決定了。

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

通過將某些關鍵字到您的拉請求的文本，你可以用代碼相關聯的問題。當你拉入請求合并，相關問題也將被關閉。例如，輸入短語關閉＃32將關閉在倉庫中發行數量32。欲了解更多信息，請查看我們的幫助文章。

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.

注意：英文翻譯為機器翻譯，可能有翻譯錯誤的地方，建議大家盡可能看英文

總結

基本的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/

總結

以上是生活随笔為你收集整理的GitHub for windows使用教程（三） 团队协作流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。