好的,我有一个Django项目。 我想知道是否应该将每个应用程序放入其自己的git存储库中,还是最好只将整个项目放入git存储库中,或者是否我应该为每个应用程序和项目都有一个git存储库?
谢谢。
好的,我有一个Django项目。 我想知道是否应该将每个应用程序放入其自己的git存储库中,还是最好只将整个项目放入git存储库中,或者是否我应该为每个应用程序和项目都有一个git存储库?
谢谢。
这真的取决于那些可重用应用程序是否会在项目之外被重复使用?
你可能需要将它放在不同的存储库中,只有当其他具有单独存储库的项目需要使用它时才需要。但是您可以随时将其拆分。创建git存储库很便宜,因此如果有必要,可以稍后再做。从一开始就让事情变得复杂只会让您以后感到沮丧,所以请随时等待直到您知道它是必要的。
YAGNI不仅适用于代码。
我喜欢汤姆或亚历克斯的回答,但它们缺乏真正的理论依据
(“每个开发团队只有一个存储库”更容易?
“很多人可能对分离的应用程序进行拉取(或查看更改)”
为什么?)
接下来是客户端管理:当涉及一个或多个仓库时,工作空间的配置将有多么复杂。客户端如何引用正确的配置?(需要引用正确文件的标签列表)。
SVN使用外部引用,Git使用“子模块”,在这两种情况下都会增加复杂性。
这就是为什么汤姆的答案可能是正确的原因。
最后,还有配置管理方面(在Alex的回答中提到)。你能标记部分仓库吗?
如果可以(就像在SVN中,你实际上可以复制部分仓库),那么你就可以采用组件方法,其中几组文件有自己的生命周期和自己的标签(以自己的个体节奏设置)。
但是在Git中,这是不可能的:标签引用的是涉及整个存储库的提交。
这意味着采用"基于系统"的方法,无论如何你都只需要整个项目(与Alex的回答中的“观察单独的应用程序-我从未在现实生活中观察到”相反)。如果是这种情况(如果你无论如何都需要整个系统),那就不重要了。
但对于那些按独立文件组思考的人来说,这意味着git存储库实际上代表了一个单独的文件组(具有自己的演变和标记节奏),可能会有一个超级项目将这些存储库作为子模块引用。
这不是你每天都会遇到的设置,因此对于独立项目,我建议只使用少量或一个Git存储库。
但对于更复杂的相互依赖的项目集...您需要意识到Git的设计方式,“存储库”表示一组一致的文件,应该与所有文件以相同的速度演变。并且如果“所有内容”足够复杂,则不一定能够全部适合一组文件中。因此,在这种情况下需要多个存储库。
在现实生活中也会发生复杂的相互依赖的项目集;)
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 = .
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日编辑
关于在gp.vcsdevelop包含的共享应用程序的local_checkouts中工作:
(并处理上面讨论的警告)
git push origin +master似乎会损坏共享代码的提交历史记录
因此,在local_checkout目录中工作的方法如下:
进入本地checkout(经过bin/buildout后,checkout是主要的):
cd localcheckouts/<shared appname>
git checkout -b 'issue_nr1'
(例如,分支的名称以您正在处理的问题命名)git push origin issue_nr1
git checkout master
更新(可能仅需要在此期间进行其他提交)
git pull
git merge issue_nr1
git push origin master
感谢这篇简化版的git指南http://rogerdudler.github.io/git-guide/,之后你可能需要清理分支,可以删除这个分支。
git branch -d issue_nr1
我不是git专家,但我认为适当的策略与hg或者在这种情况下甚至svn的策略没有任何区别,所以我还是要发表我的意见。
每个应用程序一个仓库只有在大量人员可能对单独的应用程序进行拉取(或观察更改)时才有意义;理论上可能会出现这种情况,但我从未在现实生活中观察到过——大多数对项目感兴趣的人都是对整个项目感兴趣。因此,我建议避免复杂性,将整个项目制作成一个仓库。
这些单独的应用程序是否使用共享代码和库?如果是,它们确实属于同一个存储库...这使您能够在运行单个测试套件时查看新更改的影响。
如果它们完全分离且不可知,那么实际上并不重要。仅出于清晰起见、易于构建和打包的考虑,我更喜欢将整个项目放在一个组合存储库中。然而,我们通常是在非常小的团队中工作。因此,如果没有共享代码涉及,则真正的问题只是哪种方法对所有相关人员最方便和高效。