你是否控制了個人應用程序或整個項目或兩者？

Question

好吧，我有一個Django項目。我想知道是否應該將每個應用程序放在自己的git存儲庫中，還是僅僅將整個項目放到git存儲庫中，或者我應該爲每個應用程序都有一個git repo，還有一個git repo for該項目？

謝謝。

Answer 1

這真的取決於這些可重用的應用程序是否真的要在項目之外重用？

您可能需要它在不同的回購中的唯一原因是其他具有獨立回購的項目可能需要使用它。但是你可以隨時將它分開。製作一個git倉庫是很便宜的，所以如果有必要的話，你可以稍後再做。讓事情變得複雜起來只會讓你後來感到沮喪，所以隨時可以等到你知道這是必要的

YAGNI它不僅僅是代碼。

Answer 2

我不是git專家，但我不相信合適的策略與hg，甚至在這種情況下，svn是不同的，所以我會給我2美分的價值無論如何;-）。

每個應用的回購只有在大量的人有興趣提取（或觀看更改）單獨的應用時纔有意義;這在理論上可能是這種情況，但我從未在現實生活中觀察過它 - 大多數情況下，對這個項目感興趣的人都對它感興趣。因此，我會避免併發症，並將整個項目整合到一個回購項目中。

Answer 3

無論您擁有多少產品，每個開發團隊幾乎總是​​可以更容易地擁有一個存儲庫。最終你會希望在項目之間共享代碼（甚至是幾個獨立的DJango網站！），並且只需要一個存儲庫就容易得多。

通過一切手段設置一個很好的文件夾結構內存儲庫。然而，從git（可能來自子文件夾）的單個checkout應該爲您提供測試網站所需的所有文件（python，templates，css，jpegs ...），然後您只需將httpd.conf等複製到完成安裝。

Answer 4

這些單獨的應用程序是否利用共享代碼和庫？如果是這樣，他們真的屬於同一個存儲庫..這使您能夠在運行單個測試套件時看到新更改的影響。

如果他們是完全獨立的和不可知的，那真的沒關係。爲了理智，易於構建和便於包裝，我傾向於將整個項目保存在一個聯合存儲庫中。但是，我們通常在非常小的團隊中工作。因此，如果不涉及共享代碼，那麼對於所有相關方而言，其實際上只是一個哪種方法最方便和最高效的問題。

Answer 5

我喜歡Tom's或Alex's答案，但他們缺乏他們背後真正理由
（「更容易讓每個開發團隊一個倉庫」？
「大量人員可能會感興趣的拉出（或看變化）不同的應用程式」
爲什麼？）

首先，一個或多個倉庫是一個服務器端管理決定（在服務器資源的術語）。
SVN很容易在一個服務器上建立多個存儲庫，而ClearCase每個VOB都會有自己的「vob_server」進程，這意味着：你不需要每個（Unix）服務器有超過一百個VOB（或超過20-30在Windows服務器上）。
Git是特別的：設置一個倉庫很便宜，訪問它可以很容易（通過一個簡單的共享路徑），或可以涉及一個進程（一個git守護進程）。最新的解決方案意味着：「從外部直接訪問直接從訪問的庫不多」。 （它們可以通過由超項目引用的子模塊間接訪問）

然後是客戶端管理：多麼複雜將工作區的結構是，當一個或多個倉庫中涉及。客戶如何參考配置？ （引用正確文件所需的標籤列表）。
SVN會使用外部的git「submodules」，並且在這兩種情況下，都會增加複雜性。
這就是爲什麼Tom's answer可以是正確的。

最後，有configuration management aspect（在Alex's answer中引用）。你能不能標記部分回購？
如果你能（像SVN，你居然做出回購的一部分SVN副本），這意味着你可以有一個組件方法，其中文件的幾組有自己的生命週期，以及他們自己的標籤（按照自己的個人節奏）。
然而在Git中，這是不可能的：一個標籤引用提交它總是涉及所有庫。
這意味着一個「基於系統」的方法，在那裏你只想要所有的項目（而不是「看着單獨的應用程序 - 我從來沒有在現實生活中觀察它」從Alex's answer位）。如果是這種情況（如果你想要所有的系統），那並不重要。

但是對於我們這些認爲是「獨立文件組」的人來說，這意味着一個git存儲庫實際上代表了一組文件（在進化和標記方面有自己的節奏），可能還有一個超級-project將這些存儲庫作爲子模塊引用。
這不是你日常的設置，因此對於獨立項目，我會建議只有很少或一個混帳回購協議。
但是對於更復雜的相互依賴的項目集...您需要意識到，通過Git構思的方式，「存儲庫」代表了一組連貫的文件，應該以與all相同的速度進化。而不是「所有」，總是可以見縫插針在一組文件（如「所有」是夠複雜的）。因此，多個倉庫就在這種情況下是必需的。
而且一系列複雜的相互依賴的項目也會在現實生活中發生;）

Answer 6

如果您有可重複使用的應用程序，請將它們放在單獨的回購站中。

如果你擔心私有倉庫的數量看看到位桶（如果你決定讓他們開源的，我建議github上）

有包括到自己的應用中的一個很好的方式項目，甚至使用版本標籤：

我最近找到了一種方法來做到這一點與構建和git標籤 （我用svn：外部包括一個應用程序，但最近從svn切換到git）。

我第一次嘗試mr.developer，但在沒有得到這個工作，我發現mr.developer替代：

我發現gp.vcsdevlop是非常容易使用這個目的。

看到https://pypi.python.org/pypi/gp.vcsdevelop

我結束了，把這個在我的擴建文件，並得到了它在一次工作（我有一個點子requirements.txt添加到我的應用程序得到它的工作，但之後是一件好事所有）：

vcs-update = True 
extensions = 
    gp.vcsdevelop 
    buildout-versions 
develop-dir=./local_checkouts 

vcs-extend-develop=git+git@bitbucket.org:<my bitbucket username>/<the app I want to include>.git@0.1.38#egg=<the appname in django> 

develop = . 

在這種情況下

它chacks了我的應用程序，並在subdit項目將其克隆到版本標籤0.1.38 ./local_checkouts/ 和發展它運行斌/擴建

時

編輯：備註2013年8月26日

雖然使用此解決方案和編輯在一個項目中使用的應用程序的該地方結帳。我發現這一點：

嘗試正常「git push origin master」命令時，你會得到這樣的警告：

To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes before pushing again. See the 'Note about 
fast-forwards' section of 'git push --help' for details. 

編輯2013年8月28日

關於在local_checkouts工作由包括共享應用程序gp.vcsdevelop：

（並處理上述remakr中討論的警告）

混帳推起源+主似乎搞砸了提交歷史的共享代碼

所以在local_checkout目錄的工作方式是這樣的：

去到當地結賬（一斌/擴建後所以結帳是主）：

cd localcheckouts/<shared appname> 

像這樣創建一個新的分支，開關等它：

使用git checkout -b 'issue_nr1'（如分支的名稱你工作）

問題後，這裏命名和你做這個領域的工作，使用後（在usuals混帳後添加和git的承諾）

git push origin issue_nr1 

時測試完成合並分支回到主：

第一結賬主：

git checkout master 

更新（大概只有neede時的平均時間等提交）

git pull 

和合併到主（您身在何處，現在）：

git merge issue_nr1 

和finaly推動本次合併：

git push origin master 

（與sepcial感謝這個簡易導向，以git：http://rogerdudler.github.io/git-guide/） 並過了一段時間，要清理分支，您可能需要刪除此分支

git branch -d issue_nr1