用于维护派生派生的Git工作流程 [英] Git workflow for maintaining a derivative fork

问题描述

概述

我有一个项目是对现有FOSS产品的定制.到了我们维护长期分支而不是应用新插件之类的地步.我想要一些有关维护该项目的最合理的工作流程的信息.

条件

1. 我们应该能够轻松地向上游发送请求请求/补丁
2. 该项目需要跟踪已标记的版本，并且可能会作为我们自己的发布工作流程的一部分更新到较新的版本.
3. 需要有自己的标记发行版
4. 对于像git-flow这样的开发过程，需要具有自己的分支结构.

选项1

只需在github上分叉该项目即可.超级凌乱的维护和使人们快速上手.失败3,4.

选项2

创建一个新的存储库，让项目维护人员根据需要提取上游代码库的带标记的版本.例如，像 git这样的东西在上游获取；git merge upper/sometag tagintegrationbranch 不确定如何轻松地在此模型中向上游推送修订.失败的种类1.

选项3

分叉上游项目，像选项2一样将其用作上游项目.用作PR系统的助手.根据功能/错误分支的管理方式，可能将不得不进行点刺或类似的微管理来将代码备份到此工作流程中，但应相当干净.似乎满足大多数条件.

选项?

我没有考虑过的事情?

解决方案

选项3似乎代表了两个项目之间工作流程的最清晰分离:

• 偶尔会回馈原始项目并提出请求的人
• 具有全新分支和代码的新应用程序

为便于合并，我建议您在回购中使用分层分支名称，以便清楚地分开:/p>

• 为您的项目开发服务的分支机构(经典名称，其中不需要'/')
• 来自上游/原始存储库的分支(所有前缀带有代表原始存储库分支的名称，例如" original/dev "，供您从或"选择樱桃)
  这些分支已经在其remotes/upstream命名空间中，但是如果您要回退新的提交，则需要创建一个本地分支，我的意思是:该本地分支的名称应具有'/"，以便与您项目的其他常规分支区分开来.

Overview

I have a project that is a customisation of an existing FOSS product. Its getting to the point where we're maintaining a long-term fork rather than applying new plugins and the like. I'd like some input on what the sanest workflow for maintaining this project might be.

Criteria

1. We should be able to send pull requests / patches upstream easily
2. The project needs to track from tagged releases, and may be updated to newer releases as part of our own release workflow.
3. Needs to have its own tagged releases
4. Needs to have its own branching structure for a git-flow like development process.

Option 1

Just fork the project on github. Super messy to maintain and get people up to speed on. fails 3,4.

Option 2

Make a new repository, have a project maintainer pull in tagged releases of the upstream codebase as needed. eg something like git fetch upstream; git merge upstream/sometag tagintegrationbranch Not sure how to easily push fixes upstream in this model. Kind of fails 1.

Option 3

Fork the upstream project, use that as the upstream like in Option 2. Used as an aide to the PR system. Will probably have to do cherry-picks or some similar micromanagement to push code back up this workflow depending on how well feature/bug branches are managed, but should be fairly clean. Seems to satisfy most criteria.

Option ?

Something I have not considered?

解决方案

Option 3 seems to represent to clearest separation of workflow between the two projects:

• one with occasional contribution back to the original project, with pull requests
• one with entirely new branches and code for the new application

To facilitate the merges, I would recommend using hierarchical branch names in your repo, in order to clearly separate:

• branches for your project development (classic names, no need for a '/' in them)
• branches from the upstream/original repo (all prefixed with a name representing a branch from the original repo, like 'original/dev', for you to cherry-pick from or to)
  Those branches are already in their remotes/upstream namespace, but if you want to push back new commits, you need to create a local branch, and my point is: the name of that local branch should have a '/' in it, in order to clearly differentiate it with other regular branches for your project.

这篇关于用于维护派生派生的Git工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！