我们通常会在git-flow上寻求最佳实践。
功能分支应该持续多长时间?
是否存在一些注意事项和维护命令,开发人员经常需要执行这些命令和维护命令才能拥有有效,有效且响应迅速的git? />
谢谢。
#1 楼
功能分支应保留到功能完成为止,完成后必须关闭/删除分支。建立这种行为应该是团队的目标,通常需要一些时间,而在我准备好我的请求请求模式时,赶紧忘记它们会更容易。保持所有这些都会使维护变得更加困难。您可能会认为每个分支都遵循带有JIRA票证的映射或您所拥有的任何映射的命名约定,因此很容易直接区分它们,但是一旦您拥有十几个它们并且甚至不断堆积。我高度怀疑性能是否有用,更像是一个混乱的成本开关。
关于命令,我不这么认为。
#2 楼
我同意Recoba20的回答,我只想补充两点。我们通常会在git-flow上寻求最佳实践。 >这意味着
在某些时候,您还将这些分支合并到主线(
master
分支)中。 /> 如果是这种情况,那么我认为实际上保留分支机构不会对您的过程有任何帮助。更改已在进行中,并且如果需要错误修复或更改,则意味着您将从更远的地方开始而不是从原始功能分支开始新的分支(根据git-flow)。
我可以看到发生的一件事就是以某种方式弄乱了主线(或
--no-ff
),并且您需要重新创建一组集合在一起的功能。如果已经有分支(即未删除),则可以创建一个新的发行分支并重新合并正确的功能。如果没有分支,则没什么大问题,因为通过使用release-X
合并, />
保留所有这些文件是否足够安全且成本不高或性能下降?
我不确定
--no-ff
本身是否会遇到问题鉴于分支只是refs(指向提交的指针),但同时在某些情况下事情变慢也不会令我惊讶git
ing。我可以看到发生的一个问题是某些
clone
GUI的性能下降。为此,我建议一些轻量级的。我已经使用git
很长时间了,这对于快速了解提交树是正确的。开发人员是否需要经常执行维护命令才能获得有效,响应迅速的git?尚未合并。它并不能解决任何问题,但是可以直观地显示您正在使用的工具。有点不同。以我的经验,大多数
gitk
问题只是一个过程的症状,并没有针对意图进行过调整。 git branch --no-merged master
就在那儿,受到打击。功能分支的运行时间较长(几天,几周),使其在重新集成时更容易遇到问题。 >#3 楼
关于“特征分支应持续多长时间?”请尽可能短。只要需要。 “旧功能分支”本身就是一个矛盾。
我们将Scrum与JIRA一起用作票务工具。任何功能分支的持续时间都不会超过2周的冲刺期。我们的票务计划时间通常从2个(净工作时间)小时变为几乎从来没有40个(净工作时间)(即2%的净开发时间为2周)。
如果建议。没有阻止者的任务可以由不同的人并行完成。通过这种精细的过程,任何开发人员都可以轻松地继续购买机票(如果需要放假,请病假,在另一地点的办公室被烧毁等),也可以开始新的工作而无需关心有关先决条件的信息。
如果任务的预计完成时间往往超过两天,则会将其拆分为较小的任务。
示例:使用Java,JUnit,GitLab,Eclipse,Maven,Jenkins的项目
开发任务
为分支main,开发,功能,修补程序,发布创建Jenkins项目
创建Git存储库(包括配置访问权限等)
创建Maven项目(s)(在Eclipse中),相应地修改POM声明(属性,依赖项,插件...)
实现框架:创建包,接口,测试类以及具有空方法,资源和测试的类/枚举开始的资源(根据项目的大小,此任务也可以分为多个)
实现功能(可以拆分dep结束于...请参见上文)
Git任务(针对上述每个开发任务)
如果故障单的状态从“新建”变为“在实施中”,则会创建一个功能分支。
如果故障单的状态从“实施中”更改为“已实施”,则完成检查。 br />关于“是否存在开发人员需要经常执行的注意事项和维护命令,以使工作正常,高效且响应迅速?”
关于
git gc
,请参见SO。他们:git flow init
git flow feature start <name> [<base>]
git flow feature finish [<name>]
长话短说页面底部的Gitflow工作流程:
Gitflow的总体流程为:
从
(main) $ git flow init
... 6 times <Enter> to accept the defaults ...
(develop) $ git branch
* develop
main
$ git flow feature start my-cool-feature
Switched to a new branch 'feature/my-cool-feature'
Summary of actions:
- A new branch 'feature/my-cool-feature' was created, based on 'develop'
- You are now on branch 'feature/my-cool-feature'
Now, start committing on your feature. When done, use:
git flow feature finish my-cool-feature
(feature/my-cool-feature) $ git branch
develop
* feature/my-cool-feature
main
...
(feature/my-cool-feature) $ git status | add | commit | pull | push | gc | ... # whatever
...
(feature/my-cool-feature) $ git flow feature finish # without a feature name it finishes the current
Switched to branch 'develop'
Already up to date.
Deleted branch feature/my-cool-feature (was a57868f).
Summary of actions:
- The feature branch 'feature/my-cool-feature' was merged into 'develop'
- Feature branch 'feature/my-cool-feature' has been locally deleted
- You are now on branch 'develop'
(develop) $ git push # if there's a remote repo
(develop) $ git branch
1. develop
main
(develop) $ git flow feature start my-even-cooler-feature
...
(feature/my-even-cooler-feature) $
[现在为develop
]创建了一个master
分支,一个
main
分支为从release
创建的develop
分支是从Feature
创建的当
develop
完成时,它会合并到feature
分支中。完成后将其合并到develop
和develop
[或master
] 如果检测到
main
中的问题,则会从master
创建一个hotfix
分支ed到master
和hotfix
[或develop
]
评论
并不是真正的git,但是由于功能分支过多,Jenkins倒塌时遇到了很多麻烦。我想您的问题引起了相当主观的回答。