Questions tagged «gitflow»

在通常称为Git-flow模型的修补程序中，修补程序进入其特定hotfix-*分支，而在发布之前的小型集成修补程序也进入该release-*分支。以前版本中的常规错误修正似乎没有位置。 它们应该出现在哪里？它们是否应该在自己的bug-*分支中分支develop（就像feature分支一样）？

14 git  gitflow 

很久以前，我与之合作的Web开发人员小团队开始使用git进行Web开发。那时我们只是致力于直接登台或掌握，然后在两者之间频繁合并。总比没有好，但也很混乱。 不久之前，我们采用了gitflow工作流程。尽管它肯定比以前出现的混乱更好，但它似乎有些繁琐且过于释放/面向里程碑。我的开发人员经常要求我弄清楚它应该如何工作，什么应该合并而不应该合并。一般而言，它似乎不适合用于Web开发工作，在Web开发工作中，我们经常部署代码，而没有跟踪特定的发布里程碑。 根据朋友最近的建议，我已经开始关注GitHub Flow。在这里阅读Scott Chacon的帖子，可以很好地解决这一难题： 那么，为什么不在GitHub上使用git-flow？好吧，主要的问题是我们一直都在部署。git-flow过程主要围绕“发行版”设计。我们实际上没有“版本”，因为我们每天都会部署到生产中，通常一天要部署几次。 FWIW，我也在Atlassian的网站上看到了这种很好的工作流汇总：https ://www.atlassian.com/git/workflows#!workflow-feature-branch 但是，它们看起来都像是在一个小型团队中，对于Web开发而言是错误的选择，并且它们又针对主要的应用程序发布而不是频繁/每日发布。 这是关于SE的一个问题，要求比较git-flow和github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -流 一般而言，这是一个很好的答案，但是正如我在meta.programmers.SE下方的评论中提到的那样，这似乎表明有关最佳通用工作流程实践的问题属于此处，我希望除了git-flow和github以外，还提供更多可能的答案-flow，而特定于Web开发。因此，我认为这里值得提出一个新问题。 这样一来，对于一个小型Web开发团队来说，您发现最佳/首选的基于git的工作流程是什么？是github-flow还是其他东西？

12 web-development  git  gitflow 

我正在向初级团队成员（一个合作社）介绍git。 现在，他们对添加，提交，推送和拉取的基础知识感到满意。 现在，我要介绍它们来拉取请求和分支。 如果他们开始在分支机构中执行拉取请求，我是否应该为正在进行的工作做同样的事情？ 我将成为合并他们的请求请求的人。我不确定在分支机构工作对我来说是否最有意义（通常我知道这是一种很好的做法，但我对2个开发人员和一个大三的这种特定情况感到好奇），如果是的话，那意味着我将把自己的分支合并到master中。无论如何，我是否还会为我的工作/分支提出拉动请求？通常，我们使用基本的github功能分支工作流进行以下更改：https : //www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow 如果我是唯一的开发人员，是否有在自己的仓库上使用拉取请求的目的？是有用的，但不够具体。 2个人在一个项目上的工作流程似乎也更笼统 和 我应该在官方仓库或叉子上打开来自分支的拉取请求吗？似乎更多关于叉子。

11 git  github  gitflow  pull-requests 

我的工作团队正在使用Subversion作为我们的VCS来启动一个新项目（出于这个问题的考虑，您可以将其视为一成不变的）。我们仍处于该项目的早期阶段，并试图就分支模型达成共识。我们之前的项目基于非标准版本模型，该模型导致管理现有版本的修补程序和修补程序时出现问题。 我发现不同的分支模型相当复杂，但是我确实很清楚地理解的一种模型是git flow。我很好奇在Subversion中实现这种变化会有多么困难/不期望。显然，在分支机构上进行协作的人会有所不同。功能分支必须集中而不是局限于本地存储库，但是据我所知，该模型的其他概念应该可以在Subversion中重现。 这种方法的缺点或挑战是什么？我听说相对于Git，在SVN中“合并成本很高”。但是我尚不清楚这在实践中意味着什么，或者它将如何影响我们使用像分支模型这样的git flow的能力。 这种方法最大的担忧是什么。有没有一种类似的清晰方法在Subversion中更自然？

10 svn  branching  gitflow 

我已经开始在项目中使用gitflow，并且拥有出色的功能分支以及新创建的修补程序。每gitflow工作流程，修复被同时应用于主和发展分支，但没有说或约现存功能分支完成。 不过，我想将修补程序更改合并回我的功能分支中，据我所知，它留下三个选项： 不要合并更改。如果功能分支需要更改，则应将其作为功能分支的一部分。 合并开发回要素分支。这似乎最好地遵循gitflow工作流程，但会导致乱序提交。 变基的特性分支上开发。这将保留提交顺序，但常规gitflow工作流程似乎完全没有重新定基础。 最佳做法是什么？

10 git  gitflow 

使用gitflow时，在创建release-1.0.0分支并将其合并到master和时develop，两个分支都将缺少提交： master不会有release-1.0.0合并到的提交develop develop不会有release-1.0.0合并到的提交master 相反，在hotfix-1.0.1创建并合并到之后master，在将其合并到时develop，要合并的提交将包括先前release-1.0.0合并到的提交master；所以它看起来像这样： User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'. * merge release-1.0.0 to master * merge release-1.1.0 to master * Fix shopping cart critical bug 如果这听起来有点混乱，你很容易就注意到这个everytie你看到的develop通常是一对夫妇后面的提交master（即使开发，从理论上说，应该只有提前，因为它的主要分支。这些提交的合并从release-x.x.x到master）。 应该如何处理以保持干净的历史记录？

9 git  gitflow