git 的“本地存储库”是如何实现的？概念与“开发人员分支”不同吗？
在之前的工作中，我发现通过让每个开发人员在他/她自己的分支上工作，可以更轻松地管理和保持稳定的预发布分支（或主分支，取决于设置）。我们只有一个生产实例，因此不需要支持同一应用程序的多个版本。
这个“预发布”分支之所以如此命名，是因为我们可以从另一个分支（主分支）进行暂存和生产版本。分支的设置使得只有来自预发布分支的代码才能合并到发布分支中。这些合并是我们的代码审查检查点。 CI 构建也是从这个预发布分支构建的，每个开发人员都需要从“预发布”分支合并到自己的分支，以便在该工作主体的开发完成后解决复杂的合并问题。
如果开发人员需要结对并共同工作某一特定功能，那么除了他们自己的分支权限之外，没有什么可以阻止他们与其他人合作。这对于管理分布式团队非常有效，其中每个团队中的个人都在处理单独/多个功能。
在频繁（每周 1-2 次）30 分钟状态更新会议的帮助下，我们作为一个团队将决定哪些内容将进入 QA，哪些内容不会进入特定的 QA 版本。
这个系统有效，但在搜索这个主题时，我发现开发人员分支有很多不满。人们似乎对 git 的本地存储库功能充满热情。然而，它们似乎只是解决同一问题的不同方法。没有考虑本地存储库解决的跨网络问题，例如签入延迟等。
In a previous job, I found easier to manage and keep a stable pre-release branch (or main, depending on setup) by having each developer work on his/her own branch. We only had a single production instance, so no need to support multiple versions of the same apps.
This "pre-release" branch is named that way because there was another branch (main) where we'd make our staging and production releases from. The branches were setup such that only code from the pre-release branch could be merged into the release branch. These merges were our code review checkpoints. The CI builds were made from this pre-release branch as well and it was up to each developer to merge from "pre-release" to their own branch to migitage complex merging issues when the development for that body of work was completed.
If there was a need for developers to pair up and work together one a given feature, nothing but their own branches permissions prevented them from working with others. This worked well for managing distributed teams where individuals within each team were working on separate/multiple features.
With the help of frequent (1-2 times a week) 30-minute status update meetings, we as a team, would decide what would go into QA and what wouldn't for that particular QA release.
This system worked, but I find a lot of resentment for developer branches when searching on this topic. There seems to be a lot of enthusiasm about git's local repository feature. Yet, it seems that they are just different ways of addressing the same problems. Not considering the cross-network issues that local repositories address, such as check in latency and such.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
存在三个主要区别：
本地存储库意味着：它位于您的系统本地，如果您发现自己被困在没有互联网连接的荒岛上，您仍然可以提交更改。 Git 最好的事情之一是您不必连接到存储库就能够利用版本控制系统。开发人员有时远程工作而无法访问主存储库，当您拥有 Subversion、Perforce 或其他类型的集中存储库版本控制等系统时，这通常会很混乱系统。借助 Git 和 BitKeeper，您可以轻松地离线工作。
在开发人员分支情况下，您通常会从集成分支分支到开发人员分支，然后合并回集成分支。在 Git 中，您不合并，而是发送补丁，并且您不仅可以将更改发送到主存储库，还可以发送给其他开发人员，而无需先将补丁发送到主存储库嗯>。这允许开发人员在不接触主存储库的情况下一起工作。
在开发人员/集成分支设置中，开发人员分支位于存储库中，这意味着其他人可以看到它。在 Git 中，开发人员的更改在开发人员交付更改之前不可用。
There are three main differences:
Local repository means just that: It is local to your system, and if you ever found yourself stranded on a desert island with no Internet connection, you'll still be able to commit your changes. One of the best things about Git is that you don't have to be connected to your repository to be able to take advantage of the version control system. Developers sometimes work remotely without being able to access the main repository and that can usually be messy when you have a system like Subversion, Perforce, or another type of centralized repository version control system. With Git and BitKeeper, you can easily work offline.
In a developer branch situation, you normally are branching from the integration branch to your developer branch and merging back to the integration branch. In Git, you don't merge, but send patches and you can send your changes not just to the master repository, but to other developers without first sending your patch to the master repository. This allows developers to work together without touching the master repository.
In a developer/integration branch setup, the developer branch is in the repository which means others can see it. In Git, the developer's changes are unavailable until the developer delivers their changes.
像 Git 或 Mercurial 这样的 DVCS 引入了发布工作流程（推/拉），该工作流程是
这意味着：
即使所有开发人员都在同一个分支上工作，他们也可以在自己的存储库上“私下”这样做：只要他们不发布他们的工作（即推送到上游存储库），那么common 分支实际上是他们自己的。他们可以定期拉取（获取+合并），以免与同一主题上其他人的工作分歧太大，但他们会在准备好时推送。
开发人员甚至可能永远不会推送他/她的工作，但集成商可以从上游“集成”存储库中从集成商需要的尽可能多的开发人员存储库中获取尽可能多的分支（具有相同的名称）：每个分支将存储在集成存储库中自己的命名空间中（
dev1/branch、dev2/branch、dev3/branch、...）从那里，集成商可以查看每个开发人员分支正在引入的提交，并决定是否合并集成存储库中的这些更改。
注意：这在 Mercurial 中略有不同，因为命名分支在全局命名空间中具有名称（请参阅 Jakub Narębski 的回答“Git 和 Mercurial - 比较和对比”，看看“个人意见：我个人认为“命名分支”...”部分）
因此，git“本地存储库”会转换开发人员分支中的任何分支（这不会阻止开发人员在来自公共存储库的分支之上创建他/她自己的私人分支）。
这些分支可用于主动发布（由开发人员推送）或被动发布（从上游存储库拉取或获取，无需所述开发人员的直接干预）
什么David W 的 答案（已投票）更清楚地表明了两者之间的区别：
如果集成商无法访问开发人员存储库，那么是的，正如 David 所说，“在 Git 中，开发人员的更改在开发人员交付其更改之前不可用。”。
如果开发人员的存储库可访问（即使通过简单的“本地协议”，例如网络共享），然后开发人员的更改可以从下游存储库拉到集成上游存储库）
另请参阅“描述使用版本控制（VCS 或 DVCS）的工作流程"，以另一种方式对比使用分支的集中式 VCS 方式与使用存储库的分散式 VCS 方式。
A DVCS like Git or Mercurial introduces a publication workflow (push/pull) which is orthogonal to branching.
That means that:
even though all developers are working on the same branch, they can do so "privately" on their own repo: as long as they don't publish they work (i.e push to an upstream repo), that common branch is actually their own. They can pull (fetch + merge) regularly in order to not diverge too much from the work of others on the same topic, but they will push when ready.
a developer might even never push his/her work, but an integrator can fetch, from an upstream "integration" repository, as many branch (with the same name) from as many developer's repos that integrator needs to: each branch will be store in the integration repo in its own namespace (
dev1/branch,dev2/branch,dev3/branch, ...)From there, the integrator can look at the commits each developer's branch is introducing, and decide to merge or not those changes in the integration repo.
Note: this is slightly different in Mercurial, since named branch have names in a global namespace (See Jakub Narębski's answer on "Git and Mercurial - Compare and Contrast", looking at the "Personal opinion: I personally think that "named branches" ..." part)
So a git "local repo" transform any branch in a developer's branch (which doesn't prevent a developer to make his/her own private branch on top of those coming from a common repo).
Those branches are available for active publication (push by the developer) or passive publication (pull or fetch from an upstream repo, without direct intervention from said developer)
What David W's answer (upvoted) makes clearer is the difference between:
If the developer repo isn't accessible by an integrator, then yes, as David says, "In Git, the developer's changes are unavailable until the developer delivers their changes.".
If the developer's repo is accessible (even through a simple "local protocol" like a network share), then the developer's changes can be pulled from the downstream repo to an integration upstream repo)
See also "Describe your workflow of using version control (VCS or DVCS)" for another way to contrast the Centralized VCS way of using branches vs. the Decentralized VCS way of using repositories.
如果它对你有用，那就太好了。我认为您会发现它与 DVCS 配合使用效果会更好，因为它们可以支持您现在所做的一切以及更多。
本地存储库相对于开发人员分支的优点之一是您可以在本地拥有任意数量的分支。您可以启动一个快速分支来测试您感兴趣的东西。您可以启动一个分支来测试迁移到您喜欢的库的最新版本。所有这一切都不需要用可能永远不会出现的东西“污染”集中式服务器。
If it worked for you, great. I think you would find it would work even better with a DVCS, because they can support everything you're doing now and more.
One advantage of a local repository over a developer branch is that you can have as many branches as you want locally. You can spin up a quick branch to test something you're curious about. You can spin up a branch to test migration to the latest version of that library you love. All without needing to "pollute" the centralized server with stuff that perhaps shouldn't ever see the light of day.