单一工作分支与Git [英] Single working branch with Git

问题描述

是否有一种便携式方式来使用单个存储库w /多个结帐？作为拥有
多个克隆的替代方案，其中存在太多开销（推/拉/同步...）以及覆盖 .git / objects 硬链接（它甚至不能在Windows上运行）。

---

新手入门，好奇听到有经验的git的想法用户。

是否有一个概念性原因，为什么git只能与一个分支一起工作？当我需要同时处理至少两个不同的分支时，大部分时间都需要在分支之间切换回来，这似乎是绝对不切实际的。并行运行a.s.o。

好的，也许开发人员并不需要在两个分支完全同时工作。但是检出另一个分支并不会自动执行构建输出文件等被忽略的内容。所以需要一个新的重建aso

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

因此，唯一官方选择是创建一个新的克隆每个分支，这似乎是不正确的，因为每个克隆是一个完整的存储库。我甚至不知道该怎么称呼克隆目录 - 我是否使用存储库名称或分支名称或两者？如果我创建另一个分支，aso

实用案例更新 （@ Philip的建议）

我通常在两个主要/次要版本上工作，功能同时进行。还有一个偶尔的开发分支，在将它们合并到未来的版本之前，实验功能会进入分支。

在功能开发过程中，行为往往会降低，将它与更改前的行为进行比较。检出一个以前的分支/修订并不够好，因为很多时候它是并行调试的，这意味着两个修订版都需要在硬盘上同时检出。

因此，更方便和自然的方法是在其自己的目录中保留一些所谓的活动分支，并使用其自己的编译二进制文件。这还可以节省编译时间和偶尔的本地设置（例如，为了使产品正常运行，需要在每次结帐后更改配置文件）。 解决方案

如果您想这样做，那么我会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_IND的脚本EX的方式应该（或你预期的）。

---

¹ NGit或Python的类似Git绑定，Ruby - watever在你的宇宙中是可移植的）

Bounty short description

Is there a portable way to use a single repository w/ multiple checkouts? As an alternative to having multiple clones where there is just too much overhead (pushing/pulling/syncing...) and the risk of overwriting the .git/objects hard links (which does not even work on Windows).

---

New to git and curious to hear thoughts from experienced git users.

Is there a conceptual reason why git only works with ONE branch at a time? It seems absolutely impractical having to switch back and forward between branches, when most of the time I need to work on at least two different branches at the same time, e.g. building, running in parallel a.s.o.

Ok, so maybe a developer does not really need to work on two branches exactly at the same time. But checking out another branch does not automatically carry ignored stuff like build output files. So a new rebuild is required a.s.o.

There is this script git-new-workdir that is supposed to allow multiple working branches, but for one, it is not part of the git release althoug it has been around for about 3 years, so I do not trust it to keep my files consistent. And secondly, I cannot find it as part of the Windows distribution, which is one of the machines I use for development.

So the only official option is to create a new "clone" for every branch, which seems incorrect, since each clone is a full-blown repository. I would not even know what to call the clone directories -- do I use the repository name or the branch name or both? What if I create another branch off that branch, a.s.o.

Real-use case update (@Philip's suggestion)

I usually work on two major/minor releases, with features going on both in parallel. There is also an occasional development branch, where experimental features go into, before being merged to some future release.

During feature development, often behaviour degrades and it is more efficient to compare it with the behaviour before the changes. Checking out a previous branch/revision is not good enough, because many times it comes down to debugging side-by-side, which means both revisions need to be checked out simultaneously on the harddrive.

So the more convenient and natural approach would be to keep a few so-called "active" branches checked out each in its own directory, with its own compiled binaries. This would also save compilation time and occasional local setup (i.e. configuration files that need to be changed after every checkout in order to get the product running).

解决方案

If you want to be doing this,

I'd 100% recommend to write a custom application¹ that manages this process in a foolproof way.

A starting point could be

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

etc.

I would specifically make sure that none of your working copies look (remotely) like a usual repository so that normal git commands do not apply.

Using the usual git (sub)commands is recipe for disaster because someday you'll run into a script that doesn't use the GIT_DIR, GIT_WORK_TREE, GIT_INDEX quite the way it should (or you expected).

---

¹ (perhaps based on NGit, or similar Git bindings for Python, Ruby -- watever is portable in your universe)

这篇关于单一工作分支与Git的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！