我如何组织我的Git回购 [英] How do I organize my Git repo

问题描述

我正面临以下问题，并且没有答案：

我们有一个从SVN仓库克隆的仓库。存储在该回购站中的项目就像一个平台软件，可以被各种项目使用。回购的结构是这样的：

  platform 
 |  -  core 
 |  -  additional 
  

由于某些原因，该回购的结构无法更改。 核心和其他都包含属于平台附加包含源文件，并为该功能添加一个头文件到 additional / includes

目前，我们只需分支新项目来自 master ，并且所有内容都进入相同的仓库。这导致了分支通货膨胀，并且我的（中央）回购越来越多，因为单个项目中的所有提交都转到了中央回购（我的同事们习惯了SVN，因此他们 push 几乎在每个提交之后 - 只是为了确保......）。

首先我想到的是 submodules ：keep platform 作为超级项目下的子模块（称为 super ），然后转至 super / platform / additional / mystuff ，在那里创建源代码并将它们添加到 super 。但是这显然不起作用，因为这些文件位于 platform 子模块内。

有没有更好的方法组织我的回购，以便：平台的用户可以从中央仓库更新他们的工作副本
$ b

平台的$ b
• AND 用户可以将错误修复应用于平台的回购

< li AND 使用 platform 的项目不会搞乱 platform 的回购。


---

编辑1 ：涵盖了我所处的场景中的很多情况：紧密耦合的东西，我唯一知道的有点超过git的绝对基础知识，大多数开发人员对git只有非常粗略的了解。完美匹配！

---

编辑2 ：
Michael 看起来很有希望，我认为使用起来有些复杂。我正在寻找一些非常简单的事情，不需要那么多的交互。

我发现你的用法 master 有点令人困惑，因为我从来不知道
是指整个平台库还是只是它的
主分支。

我的解决方案如下：

• 您有一个用于 platform 。
  
• 每个项目有一个中央存储库。
中央平台存储库

这是只有平台代码才去的地方。使用例如您的
现有回购作为一个起点。




中央项目存储库





这是一个克隆平台存储库并保留项目的所有代码
。用



  $ git clone --bare / path / to / platform 
  





开发人员的本地存储库





初始化



作为开发人员，您可以从克隆项目存储库开始。



  $ git clone / path / to / project 
  





对项目进行更改





现在，进行更改，提交并将它们推送到项目
bare repo。

  $编辑器some-file 
 $ git add -p some-file 
 $ git commit 
 $ git push 
  

通过使用 git pull ，将其他开发人员对其他开发人员所做的更改提供给裸回购
。





对平台进行更改





由于您还想对平台本身进行更改，您还需要
来访问平台回购。所以你把它作为一个
的远程仓库添加到你的本地仓库：

  $ git remote add platform / path / to / platform 
 $ git fetch platform 
  

现在您可以看到 git branch -a ，你的本地仓库知道关于平台的
。现在您想对
平台进行一些更改。首先创建一个本地分支 central ，它是平台repo主分支的
克隆：



  $ git checkout -b中央平台/ master 
  

您可以随时检查您的分支'通过使用 git branch
或 git status 。现在你做出你的改变并提交它们（到
central，你的位置）。由于 central 连接到$ b $ em平台/ master （checkout cat .git / config ），您可以推送您的
只需使用 git push 更改为平台回购。另外
git pull 不带任何其他参数。使用 git checkout master 和 git checkout central 可以在您的分支机构之间更改
。



在您的项目中获取新的平台版本





注意： 您需要完成上一节的工作 。





首先转换到您的平台分支，并获取平台的新版本
：

  $ git checkout central 
 $ git pull 
  

现在回到您的项目分支，并将在
平台中所做的更改合并到您的项目分支中。



  $ git checkout master 
 $ git merge central 
  

如果发生冲突，会发生这样的事情：

  $ git merge central 
自动合并index.html 
 CONFLICT（内容）：合并索引中的冲突.html 
自动合并失败d;修复冲突，然后提交结果。 
  

打开包含冲突的文件，解决它们，将它们添加到
暂存区域以及提交合并：

  $ editor index.html 
 $ git add index.html 
 $ git commit 
  

现在将您的更改推送到项目的裸回购：

  $ git push 
  

更多关于合并冲突： Pro Git：基本合并冲突





如果您不想更改平台回购，但将
更改从那里合并到您的项目中使用

  $ git remote add platform / path / to / platform 
 $ git fetch platform 
 $ git merge platform / master 
  

仅当您第一次合并时才需要 git remote add 。
其他两个都是必需的。



---





关于合并的部分是基于 Pro Git Book ，它是cc-by-sa许可的
许可。这篇文章的所有其他内容可能是
被视为公有领域。




I'm facing the following problem and don't have an answer to it:

We have a repo that was cloned from an SVN repo. The project stored in that repo is something like a platform software that gets used by various projects. The structure of the repo is like this:

platform
  |- core
  |- additional

The structure of that repo cannot be changed for some reasons. Both, core and additional contain data that are part of that platform.

If a project wants to use the platform and add some functionality, it creates a new folder under additional containing the sources and adds a header for that functionality to additional/includes

Currently, we simply branch off new projects from master and everything goes into the same repo. This leads to a branch inflation and my (central) repo grows more and more because all of the commits being made in the single projects go to the central repo (my colleagues are used to SVN, so they push nearly after each commit -- just to be sure...).

First I had in mind were submodules: keep platform as a submodule under a superproject (called super) and then go to super/platform/additional/mystuff, create the sources there and add them to super. But this obviously doesn't work because the files are inside the platform submodule.

Is there any better way to organize my repo, so that:

• users of the platform are able to update their working copy from the central repo
• AND users of the platform are able to apply bug fixes to the repo of platform
• AND the projects using platform don't mess up the repo of platform?

---

EDIT 1: Highly coupled git submodules covers quite a bit of the scenario I'm in: tightly coupled stuff, me the only one knowing a bit more than absolute basics of git, "Most of the developers have only a very cursory knowledge of git". Perfect match!

---

EDIT 2: While the answer from Michael looks promising, I think that it's a bit too complex to use. I'm looking for some really simple thing that doesn't need that much interaction.

解决方案

I found your usage of master a bit confusing as I never knew whether you meant the platform repository as a whole or just its master branch.

My solution to this would be the following:

• You have one central repository for the platform.
• You have one central repository per project.
• Every developer has his/her own repository local.

The central platform repository

This is where only the platform code goes to. Use e.g. your existing repo as a starting point here.

The central project repository

This is a clone of the platform repository and keeps all the code of a project. Init it with

$ git clone --bare /path/to/platform

The developer's local repository

Init

You, as a developer, start by cloning the project repository.

$ git clone /path/to/project

Making changes to the project

Now, make your changes, commit them and push them to the projects bare repo.

$ editor some-file
$ git add -p some-file
$ git commit
$ git push

Pull changes made by other developers to the projects bare repo by using git pull.

Making changes to the platform

As you also want to make changes to the platform itself, you also need a way to access the platform repo. So you add it as a remote repo to your local repo:

$ git remote add platform /path/to/platform
$ git fetch platform

As you can see now with git branch -a, your local repo knows about the platform. Now you want to make some changes to the platform. First you create a local branch central which is a clone of the master branch of the platform repo:

$ git checkout -b central platform/master

You can always check which branch you're on by using git branch or git status. Now you make your changes and commit them (to central, where your on). As central is connected to platform/master (checkout cat .git/config) you can push your changes to the platform repo by simply using git push. Also git pull works without any other arguments.

Use git checkout master and git checkout central to change between your branches.

Get a new platform version into your project

Note: You need to have done the work from the previous section.

First change to your platform branch and pull in the new version of the platform:

$ git checkout central
$ git pull

Now go back to your project branch and merge the changes made in the platform into your project branch.

$ git checkout master
$ git merge central

If a conflict occurs, something like this happens:

$ git merge central
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Open the files with the conflicts, resolve them, add them to the staging area and commit the merge:

$ editor index.html
$ git add index.html
$ git commit

Now push your changes to the project's bare repo:

$ git push

More about merge conflicts: Pro Git: Basic Merge Conflicts

If you do not want to change the platforms repo, but merge changes from there into your project use

$ git remote add platform /path/to/platform
$ git fetch platform
$ git merge platform/master

The git remote add is only needed the first time you merge. The other two are always required.

---

The part about merging is based on the Pro Git Book which is licensed under cc-by-sa. All other content of this post may be considered public domain.

这篇关于我如何组织我的Git回购的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！