在git中使用插件维护项目 [英] Maintaining project with plugins in git

问题描述

目前我们正在使用SVN开发一个内部应用程序，它的大部分功能都是在插件中完成的。在我们开关git的方法中，这个应用程序引发了一些令人头疼的问题，关于在git中处理这种项目的最佳做法是什么。

我们应该把每个插件放到它自己的git仓库中吗？这似乎是一个合理的选择，因为插件大多不依赖于彼此，而是独立的（只是使用核心应用程序进行框架功能和管理常用功能），通常由不同的人开发，偶尔会被弃用。不过现在有十多个插件可供使用，构建整个项目通常需要逐个检查所有插件（或大多数插件）。并且似乎没有一种简单的方法可以一次性检出所有这些数据，也就是说可能需要某种列表，以便人们知道要获取什么，以及不需要什么。

另一方面，将所有内容放在一个git仓库中似乎并不符合git的精神，尤其是，因为我们会随身携带一些旧的代码，并且只需要一个插件就可以检出很多代码（尽管如此，大多数开发人员都会检查所有内容）。此外，分支将始终支持所有内容（例如，如果插件无法单独分支，则会使分支功能的交叉测试变得困难）。

一个想法是使用子模块，但我不知道这些开销（我的意思是头脑开销）是否大于收益（或者我们的收益是否比使用一劳永逸的方法损失更少）。

你会怎样在git中处理这种项目？

解决方案

这种系统在可写组件集合中）最好用以下方式进行管理：
$ b

• 每个插件在其自己的存储库中


• 一个将所有相关插件声明为子模块的父项目。 子模块的真实性，您可以直接从该父项目中修改任何插件。
  
  （参见也如果您有重复的依赖关系，则使用Git复制子模块）
  最近的Git版本命令能够递归地检出父项目的所有子模块。
  
  
  

  ---

  
  
  

  
  

  所以当我检查父项目并记住为每个插件调用 git submodule init ，我会在桌面上安装所有项目。
  

  但是你不应该记得在之外做任何事情> git submodule update --init --recursive （只是一个 命令）。正如我所说，它会递归初始化所有子模块。

  
  

  然而子模块固定到版本，这不会导致一些更复杂的工作流程吗？

  
  

  依赖关系管理的原则是始终引用特定版本（而不是引用最新的代码）。
  但是这并不妨碍您： >
  
  

  
  
  • 在该组件中工作（以该特定版本*为起点）
  
  
  • commit
  
  
  • 将其中一个组件推送到其远程仓库中
  
  
  • 上一级，回到父项目中
  
  
  • 提交父项目（以便引用刚刚修改的子模块的新版本）
  
  
  
  
  

  再次， tr子模块的性质详细说明了这一过程。
  

  We are currently using SVN to develop an internal application that has most of its functionality in plugins. In our approach to switch git, this app is causing some headaches as to what the best practice is regarding handling this kind of project in git.

  I.e. should we put every plugin into its own git repository? This would seem a logical choice as the plugins are mostly not depending on each other and rather stand-alone (just using the core app for framework functionality and management of common functions), often developed by different persons and occasionally deprecated. However there are now well over a dozen plugins with more to come and building the whole project would usually require checking out all (or most) of the plugins one by one. And there does not seem to be an easy way to check out ALL of them at once, i.e. there probably needs to be some kind of "list" out there so people know what to get and what not.

  On the other hand, putting everything in one git repository seems to be not in the spirit of git, esp. as we would carry around old dead code and working on just one plugin would require checking out a lot of code (though then most developers working on it would check out everything anyway). Also branching would always branch everything (which makes for example cross-testing of branched features difficult if the plugins can't branch individually)

  One idea is to use submodules, but I don't know whether the overhead (mental overhead, I mean) is bigger than the gain (or, whether we gain less than we lose with using the one-for-all approach).

  How would/do you handle this kind of project in git?

  解决方案

  This kind of system (as in "collection of writable components") would be best managed with:

  • each plugin in its own repository
  • one parent project which would declare all the relevant plugins as submodules.

  As detailed in "true nature of submodules", you can then modify any plugin directly from that one parent project.
  (See also Duplicate submodules with Git if you have duplicate dependencies) And recent Git releases comes with commands able to recursively checkout all the submodules of a parent project.

  ---

  So when I check the parent project out and remember to call "git submodule init" for each plugin, I would have all projects on my desktop.

  But you shouldn't have to remember to do anything beside git submodule update --init --recursive (just one command). As I said, it will recursively initialize all your submodules.

  However submodules are pinned to versions, wouldn't this cause some more complicated workflow?

  The principle of dependency management is to always reference a specific version (as opposed to reference "the latest code out there" for one component).
  But that doesn't prevent you to:

  • work in that component (working from that specific version *as a starting point")
  • commit
  • push that one component to its remote repo
  • go up one level, back in the parent project
  • commit the parent project (in order to reference the new version of the submodule you just modified)

  Again, true nature of submodules details that process.

  这篇关于在git中使用插件维护项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！