解决方案中的多个项目与源代码管理中的多个项目 [英] Multiple projects in a solution vs. multiple projects in source control

问题描述

在采用 Kiln 一年左右后，我一直坚持每个 Visual Studio 项目有一个源代码控制项目的惯例.虽然我发现这使提交保持良好和简单，并且源代码控制项目非常专注，但它开始导致大量提交，本质上是一个更改.

After adopting Kiln a year or so back, I've been sticking to the convention of having one source control project per one visual studio project. While I find this keeps the commits nice and simple and the source control project very focused, its starting to lead to a LOT of commits for what's essentially one change.

示例:我的视觉工作室解决方案之一是这样设置的:

Example: One of my visual studio solutions is setup like this:

• App.Core(服务层)
• App.Core.Tests(测试层)
• App.Web.Core(控制器)
• App.Web.UI(视图/js/等)
• App.Web.Admin(网络管理站点)
• App.Web.Tests(测试层)
• App.ChromeExtension

最终我也会添加一个 andriod 和 iphone 视图层(可能是 monotouch/monodriod)

Eventually I'll be adding an andriod and iphone view layer as well (probably monotouch/monodriod)

假设我在服务层端添加了一个需要更新界面的功能，然后我必须通过各种 Web 方法甚至 chrome 扩展来传播该更改.这是非常直接的，但这可能意味着我必须为本质上是单一更改"的内容进行多达 7 次不同的提交.这也意味着当我切换到/从我的笔记本电脑切换时，为其他开发者或我自己带来很多变化.

Say I add a feature on the service layer side that required an update to the interface, I then have to propagate that change through the various web methods and maybe even the chrome extension. That's pretty straight-forward, but it could mean me having to do up to 7 different commits for what's essentially a single "change". It also means pulling a lot of changes for other developers or for myself when I switch to/from my laptop.

处理过大型项目的人能否评论一下这里的最佳"方法是什么?我是否坚持使用多个源代码控制项目，以便每个提交树都非常简洁并处理开销?为了简单起见，我是否将所有内容都放在一个源代码控制项目中?我是否进行混合，将任何与 Web 相关的内容合并到一个项目中，并将任何与服务相关的内容合并到另一个项目中?还是别的什么?

Can someone who's dealt with large projects comment on what the "best" approach is here? Do I stick with the multiple source control projects so each commit tree is super concise and deal with the overhead? Do I stick everything in a single source control project for simplicity? Do I do a hybrid where I merge anything web related into one project, and anything service related into another project? Or something else?

供参考:该项目由 UX 开发人员和我自己维护，但将来很容易发生变化.

For reference: the project is maintained by a UX developer and myself, but that could easily change in future.

(另外:我不确定这是否值得程序员或stackoverflow，并决定转而去这里.如果mod想移动它，我不反对.)

(also: I wasn't sure if this was programmers or stackoverflow worthy, and decided to go here instead. If a mod wants to move it I've no objection.)

谢谢！

推荐答案

一旦你有相互依赖的组件(一组文件，这里是解决方案)，一个模块的改变必须传播给其他人，您可以考虑使用 系统"方法(即一个存储库，其中包含所有内容):
如果您认为不能只在一个模块上设置标记而不在所有其他模块上设置该标记，那么这很有意义.

As soon as you have inter-dependent components (set of files, here solutions), where one change to one module has to propagate to the others, you could consider a "system" approach (i.e. one repository, with everything in it):
That make sense if you consider that you cannot have a tag on just one module without setting that tag on all the others.

如果这些组件可以相互独立开发，您可以通过编写脚本来减少提交的数量，就像在这个脚本中 'git-submodule-recur.sh:'(这里是 Git):

If those components can be developed independently one from another, you could mitigate the number of commits by scripting them, like in this script 'git-submodule-recur.sh:' (here for Git):

#!/bin/sh

case "$1" in
        "init") CMD="submodule update --init" ;;
        *) CMD="$*" ;;
esac

git $CMD
git submodule foreach "$0" $CMD

然后将在每个子模块中提交一个命令:

One command would then commit in every submodules:

git-submodule-recur commit -a -m "some comment" 

这篇关于解决方案中的多个项目与源代码管理中的多个项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！