8

这些年来,我使用了大约 10 个版本控制系统。我正在转向 Git,几天前我从未使用过。(通过 SSH 访问“公共”存储库)

我不是在问如何使用 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 是旧版本,目前没有更新,或者如果它是一个分支。)

最初,我在想一些类似(In Repo)的东西:

/Src/项目 A
/Src/项目 B
/Src/Lib/LibA
/Src/Lib/LibB
/Src/Lib/LibC

在这种情况下,我必须将它们放入与存档中存在的不同结构中,或者至少将它们放入不同的目录中,或者:

/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

(抱歉格式错误,我非常努力地说服这不是代码)

但是使用这种结构,当您从项目 A 切换到 B 的开发时,您需要切换 Lib 目录……这不是我想做的事情。

在我看来,为了在 GIT 中执行此操作,我需要多个 Git 存储库,也许每个 Lib 一个

我最近被告知第一个选项,将多个版本放到不同的位置,这不是一个好主意。(他在 SVN 下谈论,所以可能不适用),我工作的公司几年前在 Source Safe 下做过这种事情,效果很好 - 我们能够创建一个指定每个 lib 的版本标签的文件关闭并使用 NANT 脚本来获取正确的版本,并可以根据需要更新它们。(不确定这里最简单的方法是什么,最初,它会更简单。就像一个文件,说明它需要什么版本或其他东西)可以做的另一件事是在所有项目中应用标签A 的发布源类似于:“RELEASE_1_0_PROJECT_A”,并根据该版本标签关闭所有源。

但是,使用 Source Safe,标签仅位于该位置及其下方,而不是整个存储库。

我也曾在他们将代码分支并创建新的顶级树的地方工作过,例如:

/Dev/x64 Branch/ProjectA (结构的其余部分与第二个示例相同。

和 /Dev/trunk/ProjectA (结构的其余部分与第二个示例相同。)

在这种情况下,要同时处理 A 和 B,您将拥有该项目所需的所有内容的两个分支,一个项目 A 分支和一个项目 B 分支。

建议?

谢谢

更新:(会在下面作为评论这样做,但 StackOverflow 溢出并且不允许我发表这么长时间的评论)

好的,我这样做了,结果是:

 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...

评论:“默认情况下,在非裸存储库中更新当前分支是被拒绝的,因为它会使索引和工作树不一致……”

听起来我会因为有人发表评论而大声笑 - 基本上,它听起来像是在说:“你只能将文件签入一个空的 .Git Repo,否则我们会搞乱你的工作目录,与你刚刚签入的内容不匹配。”

所以,我的新问题是:我如何签入更改?什么是简单/匹配的东西?我使用哪个(看起来它给了我将其设为默认值的命令。)

谢谢。

4

2 回答 2

5

听起来您想使用子模块。

您将有五个存储库:

  • 项目A
  • 项目 B
  • 库 A
  • 库 B
  • 库 C

项目 A 将有三个子模块,每个库一个。项目 B 也将有三个子模块,每个库一个。

当您克隆一个项目时,您将确保使用--recursive正确的版本(不同项目的不同版本,如果您愿意),您也会检查所有库源。更新库代码时,您需要将更改提交到项目代码中,以便项目使用新版本的库。

子模块通过在父项目中存储对子模块版本的 SHA-1 的引用来工作。所以 Project A 的 1.0 版本会引用abc123...Lib A 的提交,它对应于 Lib A 的 1.0 版本。当您签出 Project A 时,您会自动获得 Lib A 的 1.0 版本。

于 2013-04-03T18:48:33.723 回答
1

请花点时间用 git 弄脏你的手,学习 Scott Chacon 的“Pro git”、Ben Lynn 的“git magic” ,并在附近的git 主页上链接各种教程/备忘单。根据开发组的范围,您还应该阅读 git 工作流程。尽早发现 git 能做什么和不能做什么,它与您所知道的系统有什么不同(并且存在差异),过去只是白日做梦或不可能复杂的事情在 git 中是微不足道的;在承诺如何组织数据和工作流程之前,可以省去很多挫折。

正如我在学习英语时被告知的那样:不要翻译,要学会用英语思考。当你做梦时,你会完成的。是的,这需要时间。但它节省了时间。

于 2013-04-04T16:54:36.973 回答