Questions tagged «gitflow»

语境 我的由8名工程师组成的团队目前正在过渡到Git（从Subversion进行），这是我们接下来的工作。我们有一些“经验更丰富”的工程师，他们发现很难拿起Git。尽管提供了用户手册，培训活动和白板会议，但我仍然被问到同样的琐碎问题。我们有两名初级顾问，他们在几天之内就完成了所有工作，这确实为这个问题锦上添花。这不是仅限于Git的模式，因此已经可见。 题 对于那些不会/不会学习的工程师，我尤其不满意-特别是拥有我们这里资深资历的员工。但是，我确实希望团队成功并建立出色的产品。我们正在使用集中化的Git Flow模型，我觉得所有新术语都使他们感到困惑。 我有什么办法可以帮助这些员工学习Git？ Sourcetree是整个团队都在使用的客户端。

68 git  gitflow 

最近，我们遇到了一个问题，管理层推迟了webapp（自动注册）的功能，因为他们觉得开始太“冷”了，但是他们希望我们一直在努力的所有其他功能都可以上线。 问题在于该功能在完成时已与我们期望在下一个版本中发布的所有其他功能一起合并到开发中，因此我们不能像往常一样将dev-> test-> master合并。 我们如何避免这个问题？

53 project-management  git  gitflow 

使用常规的git和github，我可以通过简单地创建我正在处理的功能分支到master分支的拉取请求来进行代码审查。我将如何使用git-flow进行代码审查？使用“ git flow功能完成”之类的工作流程，我对代码审查实际上发生在何处以及git-flow或git如何促进该审查感到困惑。

43 code-quality  git  code-reviews  github  gitflow 

我的公司正在使用Git，并且正在使用一种特殊的分支方案-工作是在master中完成的，分支保留用于发布。只要在迭代中完成的所有工作都可以进入分支，就可以很好地工作，但是，如果出现关键的生产问题，我们必须确保将工作以某种方式进入两个分支。 最近，我们在那些分支机构中获得了一些“乐趣”。这一直是管理上的头疼事，要确保所有工作都进入每个分支，并且某个分支上已修复的一些错误只有在有人指出时才成为主要问题。 我前段时间遇到了Git Flow，我觉得这将解决我们的问题-代码不会一直渗透到发行版中，也不会渗透到整个发行版中。唯一的收获是我的领导说这种发展是一种反模式-疯狂发展了两个星期，然后花了三个星期来解决合并冲突。 我不确定自己是否同意，并且自提出以来，工作恢复正常了。直到最近，我们才有了一些重大的痛点。 我想知道-为什么将这种开发方案视为反模式？ 是真的反模式？

30 git  workflows  branching  gitflow 

这是一笔交易，我加入了一家新公司，并被要求完成在已经近一年没有碰过的分支机构上的工作。同时，主分支机构也在稳定增长。理想情况下，我希望将master分支中的所有更改合并到feature分支中，然后从那里继续工作，但是我不太确定该如何处理。 如何在保留分支两侧的重要更改的同时安全地执行此合并？

25 version-control  git  gitflow 

我们是一个庞大的团队（10-12个开发人员和4个质量保证团队），他们使用同一个git存储库处理多个项目。它是一个基于Spring Boot的后端Web服务。我们正在寻找一个好的git分支和部署策略。我们还有一个质量保证团队，可以确保我们的功能能够按预期运行（一定程度上没有错误）。 看了几篇文章后，我感到Gitflow模型对我们来说很好用。我的问题来了。 我们的质量检查团队应该在哪里测试我们的功能？ 如果他们在功能分支上进行测试，他们将在这里提出错误，开发人员将对其进行修复，一旦通过质量检查，我们将合并以进行开发。然后质量检查人员将再次在开发分支中进行整数测试。 我们是否应该合并所有功能（在经过单元测试和开发人员的基本测试之后）以开发分支，然后从那里进行质量检查。修复和测试也将在开发中进行。 我很想知道哪种方法对其他人有效。

23 testing  git  branching  qa  gitflow 

我们在项目中使用GitHub Flow，大多数时候，我们从master开一个新的功能分支，在那做一些工作，打开PR，查看代码，然后合并回master。 但是，我目前的工作取决于中正在处理的另一个问题feature-branch-A。从另一个分支创建我的分支是否符合犹太规范，还是违背GitHub Flow的精神？ 另一种选择是将我的分支基于master并合并feature-branch-A（经常）进行的更改。 GitHub流中首选哪个选项？

22 git  github  gitflow 

我最近开始使用由bitbucket实现的GitFlow模型。我有一件事还不完全清楚。 我们试图通过积压，计划和实施重构任务来定期解决我们的技术债务。这样的重构分支以合并到中的拉取请求结束develop。我的问题是重构分支在哪里属于GitFlow？ 使用feature前缀似乎是最合乎逻辑的方法，但是感觉并不完全正确，因为重构不会添加任何新功能。 但是，使用bugfix前缀似乎并不正确，因为没有实际的错误重构修复程序。 另一方面，如果不过度设计，则创建自定义前缀看起来很复杂。 你有这种情况吗？您使用哪种做法解决此问题？请解释原因。

22 git  refactoring  branching  gitflow 

我经常在项目的某些功能上工作，需要休息一下才能使其足够好提交。但是，我每天使用两台不同的计算机进行编码（我的笔记本电脑和我的研究实验室台式机）。例如：我正在家里进行某项功能，然后停下来去实验室。 我不想将云同步（例如Dropbox）与GitHub远程跟踪混合使用。 我只是在（然后推入）代码之前提交了未完成的（和混乱的）代码状态，仅是为了将其拉入另一台计算机以继续工作。我很确定这是一个不好的做法。 不过今天，我git stash在Google搜寻了一下之后遇到了。这似乎是我需要的完美解决方案。 但是，一旦我推送更改，该文档就不会说是否转到github。除此之外，我想知道是否有一种更有效的方式来实现所需的机动性。 提前致谢！

20 git  github  gitflow 

我有一个带有git分支模型的项目，该模型大致遵循nvie的git-flow的模型。 我们的发行分支以SemVer格式命名，例如v1.5.2 一旦发布分支允许生产，我们就关闭该分支，方法是将其合并到master中，应用标签，然后删除该分支。 当我们立即删除发布分支时，我们一直在使用相同的标识符来标记分支，例如 v1.5.2 这是我们用于关闭发布分支的命令： $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags 这似乎在大多数情况下都可行，但是在git …

20 version-control  git  branching  gitflow 

我们是一个由大约200名开发人员组成的组织，他们正在不断开发单个产品（使用版本控制Git），并计划在某个日期发布该产品。 由于开发人员数量众多，我们正在尝试创建“跨职能”团队，每个团队中约有10个开发人员，因此组织中大约有20个开发团队。 由于我们希望在主存储库中保持产品的连续“高标准”（意味着当开发人员进行拉动时，产品至少应是可编译的，等等），因此我们想使用某种质量保证。 我不太确定如何表达这个问题，但是我想知道是否可以为如此大量开发单个产品的开发人员提供一些开发方法的建议。 我们认为，范围的一端是允许每个开发人员直接提交到主存储库，但是我们担心由于开发人员/提交的数量过多，“主存储库”可能一直处于崩溃状态，这是由于我们不能为每次提交都提供苛刻的“质量门”。 频谱的另一端可能像是树或金字塔结构（我们认为是Linus Torvalds / Linux做到了），其中“主存储库”仅具有三个拉取源，这三个仅具有少数受信任的拉取源，依此类推但是，我们认为，采用这样的结构，为了进入“主存储库”，更改需要爬很长的链。另外，如果发生合并冲突，问题将落在“原始开发人员”之外的其他开发人员上。 陈述了所有这些背景信息和意见后，我们如何才能学习和阅读针对众多开发人员的推荐开发方法？大型组织（Microsoft，Facebook，Ubuntu等）如何组织其发展？

19 agile  workflows  software  development-methodologies  gitflow 

我是作为一个新手程序员来找您的，他一直在从事自己的项目（进展很好）。我的联合创始人还一直在学习如何编程，并且已经达到了可能开始修复某些问题并使某些事情发生的地步。 他问了一个很好的问题，即“这将如何工作”。我只能从理论上做些什么，因为我从未与其他人一起编程过。您能建议我最好的工作流程吗？我们使用git。 我们应该拥有系统的特定部分吗？签入代码？代码审查？ 您如何与> 1开发人员合作？

18 git  github  gitflow 

我已经将我的几个项目迁移到git flow工作流程中，并且我很喜欢它。但是，我还没有找到一种最佳实践来使一个项目同时维护一个以上的主要版本，从而使事情顺利进行。 具体来说，我不是在维护“免费版本”和“付费版本”或任何其他并行模型，我是在谈论一个项目，其中发布了版本1，并且仍支持次要版本（1.1、1.2等） 。），直到发布了第3版为止，此时将维持第2和第3版，直到第4版发布为止。 您如何或将如何在gitflow工作流程中一次维护一个项目的两个或多个受支持版本？

18 git  workflows  gitflow 

我们的团队刚刚从FogBugz＆Kiln / Mercurial转到了Jira＆Stash / Git。我们使用Git Flow模型进行分支，从功能分支添加子任务分支（与Jira功能的Jira子任务有关）。当我们创建一个合并到父分支的拉取请求时，我们使用Stash来分配一个审阅者（通常是开发，但是对于子任务来说是返回到功能分支）。 我们发现的问题是，即使对功能用例进行了最佳的规划和分解，当多个开发人员一起使用同一个功能时，例如在前端和后端，如果他们正在使用相互依赖的代码，在一个单独的分支中，一个开发人员最终阻止了另一个。 随着我们的发展，我们尝试在彼此的分支机构之间拉动。我们还尝试了创建本地集成分支，每个开发人员可以从多个分支中提取它们以在开发时测试集成。最后，这似乎到目前为止对我们来说是最好的，尽管开销更大，我们尝试立即从功能分支创建一个集成分支。当子任务分支（不在功能分支中）准备好进行拉取请求和代码检查时，我们还将手动将这些更改集合并到此功能集成分支中。然后，所有感兴趣的开发人员都可以从该集成分支拉到其他依赖的子任务分支。这样可以防止任何人等待他们依赖的任何分支通过代码检查。 我知道这不一定是Git问题-它与在多个分支中处理相互依赖的代码有关，并与我们自己的工作流程和文化相结合。如果我们没有用于开发的严格代码审查策略（真正的集成分支），则开发人员1可以合并以进行开发，以供开发人员2退出。另一个复杂的问题是，在将功能交付给QA之前，我们还需要在代码审查过程中进行一些初步测试，这意味着即使前端开发人员1正从后端开发人员2的分支直接拉出如果后端开发人员2完成并且他/她的拉取请求在代码审查中待了一周，那么前端开发人员2从技术上讲就无法创建他的拉取请求/代码审查，因为他/她的代码审查者无法测试，因为后端开发人员2' 最重要的是，在这种情况下，我们发现自己采用的是串行方式而不是并行方式，这取决于我们走的路线，并希望找到一种避免这种情况的过程。 我要提到的最后一件事是，我们通过在尚未经过代码审查和定稿的分支之间共享代码来实现，但实际上我们是在使用其他Beta代码。在某种程度上，我认为我们无法避免，并且愿意在一定程度上接受这一点。

17 git  workflows  branching  jira  gitflow 

此问题表明： 根据我的理解，在合并之前将标签放置在release分支上（而不是在master分支上）实际上是正确的做法，也可以通过develop describe分支的git describe --tags找到它。参见＃374 而另一篇文章： 我今天不小心通过自制软件安装了0.4.2-pre版本，并且对标记在该版本中的工作方式感到困惑。先前（版本0.4.1），在将发布分支合并到主分支之后，该标签已在master分支上创建。现在看来，标记是在release分支的最后一次提交上创建的，这对我来说不是一个好主意。特别是如果您有一个依赖git标记的构建系统，并且如果HEAD是带标记的提交则创建发行版本，而如果其以下提交之一则创建开发版本。有人可以向我解释此更改背后的逻辑吗？对于语义版本控制，我不认为这是补丁程序级别的颠簸！ 在我们的团队中，我们对此进行了多次讨论。有些表示需要从master分支创建标签，而另一些则倾向于使用release分支。根据gitflow的图片： 好像标签已放置在母版上。

16 gitflow