与Git单一工作分支

时间:2011-09-07 09:40:16

标签: git

赏金简短描述

是否有便携式方式使用单个存储库w /多个签出?作为替代 多个克隆,其中有太多的开销(推/拉/同步......)以及覆盖.git/objects硬链接的风险(甚至在Windows上都不起作用)。


Git的新手,很想听听有经验的git用户的想法。

是否存在一个概念上的原因,为什么git一次只适用于一个分支?在大多数时间我需要同时处理至少两个不同的分支时,例如在分支之间切换回来和转发似乎是绝对不切实际的。建筑,并行运行a.s.o。

好的,也许开发人员可能不需要同时在两个分支上工作。但检查另一个分支不会自动携带忽略的东西,如构建输出文件。因此需要进行新的重建a.s.o。

这个脚本git-new-workdir应该允许多个工作分支,但是对于一个,它不是git发布的一部分,虽然它已经存在了大约3年,所以我不相信它保持我的文件一致。其次,我找不到它作为Windows发行版的一部分,它是我用于开发的机器之一。

所以唯一正式的选择是为每个分支创建一个新的“克隆”,这似乎是不正确的,因为每个克隆都是一个完整的存储库。我甚至不知道该怎么称为克隆目录 - 我是使用存储库名称还是分支名称或两者兼而有之?如果我在该分支上创建另一个分支,a.s.o。

,该怎么办?

实际用例更新 (@ Philip的建议)

我通常会处理两个主要/次要版本,其功能同时进行。在合并到将来的某个版本之前,还会有一个临时开发分支,其中包含实验功能。

在功能开发期间,通常会降低行为,并且将其与更改之前的行为进行比较会更有效。检查以前的分支/修订版是不够好的,因为很多时候它都是并行调试,这意味着需要在硬盘驱动器上同时检出这两个版本。

因此,更方便和自然的方法是在其自己的目录中使用自己编译的二进制文件来检查每个所谓的“活动”分支。这也可以节省编译时间和偶尔的本地设置(即每次结账后需要更改的配置文件,以便让产品运行)。

7 个答案:

答案 0 :(得分:16)

签出时的分支只是指向提交的指针(within a graph of commit) 因此, Git无法同时检出该图的两个提交

实际上,请参阅“Multiple working directories with Git?” 使用Git 2.5+(2015年第2季度),您可以使用git checkout --to=<path>为一个git仓库拥有多个工作树

这允许您在<path>的单独工作目录中签出分支。新的工作目录链接到当前存储库。

该链接是“可移植的”(即在Windows上工作),因为它被记录在主回购$GIT_DIR/worktrees目录中。


原始答案(2011):

git branches

(来源:Scott Chason,ProGIT Book,http://progit.org/book/ch3-1.html,CC-BY-NC-SA)

如果您需要同时处理两个不同的分支,只需克隆您的repo并选择(git checkout)该克隆中的另一个分支。您可以使用分支的名称作为该克隆的根目录的名称 你可以在任何这些回购中创建分支。


  

所以问题是为什么Git不能有两个指针,每个目录一个? -

正如“Popularity of Git/Mercurial/Bazaar vs. which to recommend”中所提到的,Git的核心是内容管理。每次提交都代表了回购的完整快照 您无法在同一容器(工作目录)中查看两个内容,即使您可以根据需要继续引用尽可能多的指针(分支)。

Git Local operations

您只使用一个内容填充工作目录。

答案 1 :(得分:9)

如果您git clone使用本地路径,则.git/objects下的所有内容(即存储库中的大多数提交和数据)都会尽可能地与旧存储库紧密相连,并且会在no磁盘空间。因此,如果您想要两个不同的工作目录,那么在本地克隆您的repo并不是非常昂贵。尝试从一个存储库管理两个不同的工作目录可能会起作用,但这不值得。

基本上,运行git clone /path/to/old/repo new_repo,一切都会正常工作。

答案 2 :(得分:6)

你想要的是alternates,它允许一个repo依赖于另一个repo来获取它的对象。它的使用并不常见,因为磁盘空间很便宜,你必须小心不要意外删除依赖repo所需的对象。

答案 3 :(得分:5)

如果你想这样做,

我100%建议编写一个自定义应用程序 1 ,以一种万无一失的方式管理这个过程。

起点可能是

GIT_WORK_TREE=/worktrees/stable   git checkout -f origin/stable
GIT_WORK_TREE=/worktrees/unstable git checkout -f origin/unstable

我特意确保确保没有任何工作副本(远程)看起来像通常的存储库,因此普通的git命令不适用。

使用通常的git(sub)命令是灾难的秘诀,因为有一天你会遇到一个不使用GIT_DIR,GIT_WORK_TREE,GIT_INDEX的脚本(或者你预期的那样)。


1 (可能基于NGit,或类似的Python Git绑定,Ruby - watever在你的宇宙中是可移植的)

答案 4 :(得分:4)

实际上,git-new-workdir就是针对这个问题而做的。我有同样的问题,并使用它没有任何问题。关于您的预订:

  

有一个脚本git-new-workdir应该允许多个工作分支,但是对于一个,它不是git发布的一部分,虽然它已经存在了大约3年,所以我不相信它保持我的文件一致。

好吧,我(以及其他许多人)已经使用它多年了,我自己也没有遇到过任何错误,也没有听说过任何真正的问题(除了一些小的限制,见下文)。这可能听起来不是很多,但即使使用git本身(或任何 - 自由 - 软件项目,就此而言),你得到的唯一真正的保证是“没有人发现问题”。我不知道为什么git-new-workdir仍然在贡献,但我不认为这会阻止你。

  

其次,我找不到它作为Windows发行版的一部分,这是我用于开发的机器之一。

这可能只是因为您的发行版选择不包含contrib/内容。

如果你在Cygwin下使用git,你可以下载并使用原始的git-new-workdir脚本。它工作正常,我自己使用它。如果您使用msysGit,则有可用的端口: https://github.com/joero74/git-new-workdir/blob/master/git-new-workdir.cmdhttps://github.com/dansmith65/git/blob/master/contrib/workdir/git-new-workdir-win。不过,我不知道它们的质量。

git-new-workdir

的限制

为了完整起见,以下是我所知道的限制:

答案 5 :(得分:2)

也许submodules可以帮助您拥有独立目录?

答案 6 :(得分:2)

如果我理解正确,您正在寻找CopyOut特定分支机构或在分支机构上提交到独立目录的能力,以便进行调查和比较,同时仍然拥有您当前的开发/错误修正分支仍然检查出你的主要git'参考'。

您希望独立的“复制”目录不太可能直接重新提交给git。

未经测试的方法是使用基本git命令及其[--git-dir=<path>] [--work-tree=<path>]选项,并通过仔细的脚本调整/更正您的HEAD /索引{{1}然后回到你当前的分支。

通常的警告适用..

  1. 创建新的work_dir
  2. 启动git指向work_dir
  3. 保存当前的HEAD
  4. Checkout需要分支/提交(它应该进入work_dir)
  5. 将HEAD设置回已保存的值(这是一个黑客攻击,如果没有保持索引正确的步骤,可能无法正常工作!)
  6. 关闭git以'忘记'work_dir设置
  7. 在您的旧目录及其关联的分支
  8. 中重新启动git

    这肯定需要仔细测试,可能需要围绕第3步和第3步进行调整。如图5所示,步骤6-7为真。

    git work-tree选项可以提供一种机制,用于从copyout目录引入更改,如果它有需要提交到相应分支的错误修复。

    更新--------------------------------
    clunx指令基于Windows用户的视图。

    CopyOut

    通过在正确的时间将# this is run from your main work dir (that contains .git) Copy .git/HEAD MyBackup # HEAD will contain the line similar to "ref: refs/heads/master" mkdir <path> # the path should be 'somewhere else', not in your existing directory # If the path doesn't exist the following checkout will fail Git --work-tree=<path> checkout <branch> # this will extract the latest commit on that branch to the work tree path # or use a commit sha1 instead of <branch>, if you want an exact commit # Note: your index will be updated to reflect the checked out files, as will HEAD. Copy MyBackup .git/HEAD # set the HEAD back to where it was Git reset # reset the index appropriate for the previous Head. # note we dropped the --work-tree parameter 指向正确的位置并确保正确设置索引,可以使用类似的技术从提取的路径中获取任何修订。不要忘记通常的警告[备份,备份和备份]。

    这对我来说对我有一个测试回购。有些操作是在Windows中进行的。