2016-04-25 54 views
3

我是在一家小公司從事私人GitHub回購工作的少數開發人員之一。回購是我們的老闆在他的GitHub賬戶下創建的,所有開發人員都可以訪問它。在GitHub上設置私人回購有什麼好處嗎?

正如你可能知道的那樣,即使你沒有付費訂閱,也可能會分叉主倉庫,並且貨叉仍然保持私有狀態。而且每個添加到原始回購庫的人都會自動添加到分支的觀察者列表中(我不知道爲什麼)。

這是我前一陣子出於好奇(我不知道我能做到這一點)所做的事情,因爲我認爲這將是很好的,讓我在工作中的分支機構和臨時工在主體之外回購保持乾淨。但今天我的老闆問我爲什麼要這樣做,除了我上面說的,我無法想出一個好的理由。

有什麼好的理由在GitHub上分發私人回購,而不是直接推送到主回購?

+0

如果您被添加爲原始回購的貢獻者。我沒有發現太多的用法,因爲你仍然可以在本地擁有自己的分支機構,只要你想要就推動它們。它只是增加一個額外的步驟,以提交從你的分叉回購到原來的拉請求,有時你會感到困惑(如果你在原始回購或分叉回購...所有這些) – uday

+0

@szx你可能想檢查這個http://stackoverflow.com/questions/3611256/forking-vs-branching-in-github#answer- 34343080 – Vishwanath

回答

3

如果他不允許你直接對這個倉庫做出貢獻,那麼需要分給老闆的倉庫的一個原因是。但是,由於他允許您直接訪問,因此沒有明確的需要製作分支。正如@Diego指出的那樣,GitHub喜歡讓用戶從自己的回購站點中推拉,然後通過拉取請求將更改提交到上游回購站。但是,分叉不需要審查更改。一個簡單的選擇就是在老闆的遠程倉庫中創建功能分支並讓他查看這些更改。

1

通常使用fork來爲沒有寫入權限的回購做出貢獻。

在你的情況,因爲你是所有的貢獻者沒有必要的叉子。

如果我想貢獻回購,其中我不是一個貢獻者,我希望提交一個拉請求,我會從我的分叉。

創建一個「fork」會生成別人項目的個人副本。

叉子充當原始存儲庫和您的個人副本之間的橋樑。

您可以提交合並請求,通過將更改提供給原始項目來幫助改善其他人的項目。

分叉是GitHub社交編碼的核心。

+0

但是,如果我錯了,請糾正我,訪問私有存儲庫的唯一方法是如果您是撰稿人,然後您有寫入權限。 –

+0

確切的說,這是叉子的用途。爲了能夠在你不是貢獻者的倉庫上工作。 – CodeWizard

0

如果你推到你鬆有引入請求的能力正在審查的主要倉庫,評論並最終由誰就控制了倉庫合併。

+1

這可以通過主回購中的分支來完成。 – Vishwanath

2

我想爲什麼你想要私人叉的最佳描述是Atlassian's explanation of the forking workflow。以下是我們如何執行我們的存儲庫,分叉和拉取請求。它可以超越少數開發人員,並保持獨立,直到合併時爲止。

設置你的本地工作副本:

  1. 你的公司有一箇中央與支付一個或多個專用庫GitHub的帳戶。這些存儲庫的「黃金副本」。此存儲庫還與TeamCity等持續集成(CI)工具以及自動部署工具捆綁在一起。

  2. 中央公司資料庫有兩個分支。 「主」分支是生產中的,「開發」是部署到QA服務器的部分。你甚至可以有一個第三長壽命的分支「分期」服務器。

  3. 開發人員將存儲庫分發到他們自己的個人GitHub帳戶。

  4. 開發人員將從他們的個人分支克隆到他們的硬盤驅動器git clone [email protected]:username/reponame。這將使「起源」指向他們的私人分支。

  5. 開發人員還添加了一個指向公司存儲庫的「上游」(命名約定)。這是通過git remote add upstream [email protected]:company/reponame完成的。

這是新工作副本設置的結束。現在我們可以完成日常任務。

  1. 對於開發者,在創建新功能分支之前,他們應該用git fetch upstream && git checkout development && git merge --ff-only upstream/development && git push origin development更新他們的本地開發分支。

  2. 在開始解決問題或添加功能之前,在本地工作副本中創建功能分支。這可以通過git checkout development && git checkout -b new-branch-name完成。 (如果我正在處理GitHub問題,我的分支名稱是'i #### - 問題描述',其中####是GitHub問題編號。)

  3. 開始在本地功能分支上工作,作出承諾。您可以選擇立即將它們推送到「原點」(GitHub上的個人分支)。

  4. 一旦您對功能/修復分支感到滿意並將其推送到「origin」,您將創建一個GitHub Pull Request(PR)將其合併到公司存儲庫的「開發」分支中。這給你一個很好的用戶界面來審查更改,驗證他們將乾淨地合併到公司資源庫「發展」分支。如果您使用CI,那麼在允許合併之前,您也可以在您的代碼上使用GitHub運行單元/集成測試。

  5. 將功能分支合併到公司存儲庫後,它不再需要在本地工作副本或個人分支中使用。但是我通常會在更改部署到生產後將它們保留2-3個月。

  6. 我們通常對「開發」分支進行QA測試,然後將PR從「開發」變爲「主」,以便最終部署。

有時你有合併衝突,你需要重新綁定你的特性分支。

  1. 將「開發」的最新副本下載到您的工作副本git fetch upstream && git checkout development && git merge --ff-only upstream/development && git push origin development

  2. 再次以git checkout branch-name結算您的功能分支。

  3. git rebase development執行重新綁定。

  4. 將重新設定的分支強制推送至git push --force origin branch-name

  5. GitHub PR現在應該表明它與公司存儲庫中的「開發」分支沒有衝突。

相關問題