使用共享代码的多个项目的GIT版本控制设置 [英] GIT Version Control setup for multiple projects with shared code
问题描述
我不是问如何使用Git，而是如何构建资源库，或者如果我需要多个一些或什么。我有多个引用多个库的项目。我希望为这些库添加版本标签，以便我可以轻松维护这些内容：
项目A，2012年发货 -
主项目源，版本1.0，当前开发版本
Lib-A，版本1.0
Lib-B，版本2.0
Lib-C，当前开发版本
项目B，即将发货，更新至1.0
主项目源，版本2.0，当前开发版本
Lib -A，版本2.0，当前开发版本
Lib-B，版本1.0
Lib-C，当前开发版本
这个想法是，我可以把所有需要的东西放到一个目录中，以建立项目A和B - 随着他们当时可能需要的任何要求 - 能够使用当前的开发版本，或保留旧的版本（例如：项目B中的Lib-B是旧版本，并且此时未更新，或者如果它是分支h）
最初，我在考虑（In Repo）的一些事情：
/ Src / Project A
/ Src / Project B
/ Src / Lib / LibA
/ Src / Lib / LibB
/ Src / Lib / LibC
在这种情况下，我必须将它们放入与存档中不同的结构中，或至少将它们他们进入不同的目录：
$ b $ / src / ProjectA / Project A
/ Src / ProjectA / LibA
/ Src / ProjectA / LibB
/ Src / ProjectA / LibC
/ Src / ProjectB / Project B
/ Src / ProjectB / LibA
/ Src / ProjectB / LibB
/ Src / ProjectB / LibC
或
/ Src / ProjectA
/ Src / ProjectB
/ Src / Lib / LibA
/ Src / Lib / LibB
/ Src / Lib / LibC
（抱歉格式不正确，我很难说服它， t代码）
但是有了这个结构，当您从项目A切换到B的开发时，您将需要切换Lib目录...不是我想要做的事情。
在我看来，为了在GIT中做到这一点，我想要多个Git仓库，也许每个仓库都有一个仓库。我最近被告知第一个选项，将多个版本分解成不同的版本地点，将是一个坏主意。 （他在SVN下讨论过，所以可能不适用），我工作的公司在Source Safe几年前就做了这样的事情，它工作得很好 - 我们能够创建一个文件来指定每个lib的版本标签关闭并使用NANT脚本来获取正确的版本，并且可以根据需要更新它们。 （不知道在这里最简单的方法是什么，最初，它会简单得多，就像一个文件，说明它需要什么版本或者什么）。可以做的另一件事是在所有Project中应用一个标签A的发布源代码如下：RELEASE_1_0_PROJECT_A，并根据该版本标签将所有源代码放下。 （标签或任何你想称之为的）
尽管Source Safe安全，但标签只在该位置和下方，而不是在整个回购中。
我也曾经在那里分支代码并创建一个新的顶级树，比如：
/ Dev / x64 Branch / ProjectA（结构的其余部分与第二个例子相同）。
和
/ Dev / trunk / ProjectA结构与第二个例子相同。）
在这种情况下，为了同时处理A和B，您将有两个分支该项目，项目A分支和项目B分支。
建议？
谢谢
更新:(将会在下面发表评论，但StackOverflow已经溢出，不会让我发表评论）
好的，我这样做了，结果是：
Project\
Libs\
LibA
LibB
我用它创建它：
git add submodule ../Lib/LibA ./Libs/LibA
git update --init
修改一个文件，然后尝试推送它：
git push
warning：push.default未设置;它的隐含价值在
Git 2.0中从匹配变为简单。要压制此消息
并在默认更改后维护当前行为，请使用：
git config --global push.default匹配
若要压制此消息并现在采用新的行为，使用：
git config --global push.default简单
请参阅'git help config'并搜索'push.default'以获取更多信息。
（简单模式在Git 1.7.11中引入）如果您有时使用旧版本的Git，请使用类似模式
'current'而不是'simple'
计数对象：7，完成。
使用多达8个线程的增量压缩。
压缩对象：100％（4/4），完成。
写入对象：100％（4/4），378字节，完成。
合计4（增量3），重用0（增量0）
远程：错误：拒绝更新检出分支：refs / heads / master
remote：错误：默认情况下，**更新非裸仓库中的当前分支
remote：错误：被拒绝**，因为它会使索引和工作树不一致
remote：错误：使用您推送的内容，并且需要' git reset --hard'匹配
remote：error：工作树到HEAD。
remote：错误：
remote：错误：您可以在远程存储库中将'receive.denyCurrentBranch'配置变量设置为
remote：error：'ignore'或'warn'，以允许推入
remote：错误：当前分支;然而，除非你
remote：error：安排它更新它的工作树来匹配你在
remote：error：other方面推送的内容，否则不建议这样做。
remote：error：
remote：error：为了压制此消息并保持默认行为，请将
remote：error：'receive.denyCurrentBranch'配置变量设置为'拒绝'。
到/ src / C＃/ Lib / TraderhutLib
！ [remote rejected] master - > master（分支目前已经签出）
错误：未能推送一些文件到...
< hr>
注释：默认情况下，更新非裸仓库中的当前分支会被拒绝，因为它会使索引和工作树不一致......
听起来像我会对有人发表评论的LOL - 基本上，它听起来像是说：你只能检查文件到一个空的.Git回购，否则我们会乱
所以，我的新问题是：如何检入变更？什么是简单/匹配的东西？我使用的是哪个（它看起来像它给了我默认的命令）。
谢谢。
您将拥有五个存储库：
- 项目A
- 项目B
- Lib A
- Lib b
- Lib C
项目A有三个子模块，一个为每个图书馆。项目B也有三个子模块，每个子库一个。
当您克隆一个项目时，您将确保使用 - 递归，你会得到所有的图书馆资源，在正确的版本（不同版本的不同项目，如果你想）。当您更新库代码时，您需要将更改提交到项目代码中，以便项目将使用新版本的库。
子模块通过将参考父项目中子模块版本的SHA-1。因此，Project A的1.0版本将引用Lib A的提交 abc123 ... ，这对应于Lib A的1.0版本。当您检出项目A时，您会自动获取版本1.0的Lib A。
I've used about 10 version control systems over the years. And I'm moving to Git, which before a few days ago I've never used. (Git over SSH to a "public" repo)
I'm not asking about how to use Git, but rather how to structure the repository, or if I need multiple ones or what. I have multiple projects that refer to multiple libraries. I want to version label the libraries such that I can have something like this easily maintained:
Project A, Shipped in 2012
Main Project Source, Version 1.0, Current Development version
Lib-A, Version 1.0
Lib-B, Version 2.0
Lib-C, Current Development Version
Project B, To be shipped soon, update to 1.0
Main Project Source, Version 2.0, Current Development version
Lib-A, Version 2.0, Current Development Version
Lib-B, Version 1.0
Lib-C, Current Development Version
The idea being that I can pull down into a directory everything I need to build Project A and B - with whatever requirements they may have had back then - with the ability to use the current development version, OR stay with the older version (example: Lib-B in project B is an older version and is not being updated at this time, or if it is it would be a branch.)
Originally, I was thinking of something along the lines of (In Repo):
/Src/Project A
/Src/Project B
/Src/Lib/LibA
/Src/Lib/LibB
/Src/Lib/LibC
In which case, I'd have to bring them down into a different structure than exists in the archive, or at least, bring them down into different directories, either:
/Src/ProjectA/Project A
/Src/ProjectA/LibA
/Src/ProjectA/LibB
/Src/ProjectA/LibC
/Src/ProjectB/Project B
/Src/ProjectB/LibA
/Src/ProjectB/LibB
/Src/ProjectB/LibC
or
/Src/ProjectA
/Src/ProjectB
/Src/Lib/LibA
/Src/Lib/LibB
/Src/Lib/LibC
(Sorry for the bad formatting, I tried really hard to convince this it wasn't code)
But with this structure, you would need to switch the Lib directories when you switched from project A to B's development... Not something I want to do.
It seems to me in order to do this in GIT I would want multiple Git repo's, maybe one for each Lib
I've been recently told the first option, bringing multiple versions down into different locations, would be a bad idea. (He was talking about under SVN, so may not apply), The company I worked for did this kind of thing under Source Safe years ago and it worked pretty well - we were able to create a file that specified the version label of each lib to bring down and used a NANT script to fetch the correct versions, and could update them as required. (Not sure what the easiest way to do that here is, initially, it would be something much simpler. like just a file that said what versions it needed or something) One other thing that could be done is to apply a label across all Project A's source for a release something like: "RELEASE_1_0_PROJECT_A" and have all source brought down based on that version label. (Tag or whatever you wish to call it)
With Source Safe though, the labels are only across that location and below, not across the whole repo.
I've also worked places where they would branch the code and create a new top level tree, such as:
/Dev/x64 Branch/ProjectA (With the rest of the structure the same as the 2nd example.
And /Dev/trunk/ProjectA (With the rest of the structure the same as the 2nd example.)
In which case, to work on A and B at the same time you would have two branches of everything you needed for that project, a Project A Branch, and a Project B branch.
Suggestions?
Thanks
Update: (Would have done this as a comment below, but StackOverflow overflowed and wouldn't let me post comments that long)
OK, I did that and ended up with:
Project\
Libs\
LibA
LibB
I created it with:
git add submodule ../Lib/LibA ./Libs/LibA
git update --init
Modified a file, and then tried to push it:
git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 378 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, **updating the current branch in a non-bare repository
remote: error: is denied,** because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /src/C#/Lib/TraderhutLib
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to...
The comment: "By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent..."
Sounds like I would LOL about someone making that comment - Basically, it sounds like it says: "You can ONLY check in files to an empty .Git Repo, because otherwise we will mess up your working directory to not match what you just checked in."
So, my new question: HOW Do I check in changes? What is the Simple/matching thing? Which do I use (it looks like it gives me the command to make it the default.)
Thanks.
It sounds like you want to use submodules.
You'd have five repositories:
- Project A
- Project B
- Lib A
- Lib B
- Lib C
Project A would have three submodules, one for each library. Project B would also have three submodules, one for each library.
When you clone a project, you'll make sure to use --recursive and you'll get all of the library sources checked out too, at the right versions (different versions for different projects, if you want). When you update library code, you'll want to commit changes into project code so the projects will use the new version of the libraries.
Submodules work by storing a reference to the SHA-1 of the submodule version in the parent project. So version 1.0 of Project A will reference commit abc123... of Lib A, which corresponds to version 1.0 of Lib A. When you check out Project A you automatically get version 1.0 of Lib A.
这篇关于使用共享代码的多个项目的GIT版本控制设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
