git-flow

    3热度

    1回答

    我对git和Jenkins相当陌生。我们希望使用Jenkins并遵循feature-branch-workflow concept,我相信这与GitHub flow类似。 我知道主分支应该始终是生产中当前部署的内容,但是何时应该更新主分支?好像有两种选择: 之前部署到生产:pull请求得到批准,并掌握了成功的合并触发构建,部署到临时 环境,QA测试,然后有人按下按钮部署 生产 后部署到生产:东西(

    0热度

    1回答

    在使用GitFlow来适应多个开发环境和生产环境时,是否有推荐的方法? 我正在开发的一个项目必须维护一个生产站点以及两个开发环境。 第一个开发环境反映了与当前活动环境相关的任何变化 - 这些变化大多数是微小的变化。 第二个开发环境包含更重要的更改和更新,作为更长期项目的一部分。 所有这三个环境都建立了本地和远程托管,以涵盖长期开发,测试/签署和生活。另外,我还推出了管道以构建测试并部署每个分支。

    0热度

    1回答

    我有一个感觉好像是很多人的共同问题的问题。但是,我无法找到我的问题的任何答案。 我正在使用GIT中流动的工作流(未用git流)一到位桶库。但是,使用分支权限时,我目前遇到了一些工作流问题。我有以下分支命名约定: master develop hotfix/... release/... feature/... 我已经配置我的写访问资源库,对分支机构master和develop,只有通过拉请求。对于

    0热度

    1回答

    我正在使用Laravel项目并使用git-flow来管理我的更改。我的develop分支是两个提交前的功能分支我最近完成了名为功能/注册验证码。我想将这个特性分支合并到develop分支中。 最近提交我做这已经被合并到开发分公司只需运行composer update更新包,其中有一个bug在里面。所以,composer.lock文件当然已被修改。 功能/注册验证码功能分支包括添加验证码包和验证码U

    0热度

    1回答

    我有一个情况如下[这不是一个具体的规划问题,但有些事我预见会发生在我身上不久] 我分配2票需要添加2个密切相关的功能,比如功能1和功能2分别对应一个工具。必须有2个独立的提交(或2个不同的提交集)与添加这些功能 添加这两个功能需要编辑大约95%的相同源文件 需要引入以实现的更改功能2取决于功能1的变化。即if(feature1 flag enabled) foo; else bar; 我刚刚实现了

    -1热度

    1回答

    我整个的Visual Studio插件来:GitFlow为Visual Studio 2017年 (https://marketplace.visualstudio.com/items?itemName=vs-publisher-57624.GitFlowforVisualStudio2017) 现在我感到有点困惑的本地和远程分支机构。从我的理解gitflow工作流程应该如下: 创建多达最新本地

    1热度

    1回答

    Git和标准Git-Flow相当新颖。在特定场景中寻找一些建议: 我们在开发分支(Feature1)之外创建一个功能分支并完成功能。这个“完成”将特征合并到开发中。 一个新功能(Feature2)由develop分支中的其他人创建,其中包含完成的Feature1中的代码。 从develop分支创建一个发行版,其中包含Feature1的代码。 然后在Feature1中发现了一个错误,因此在发布分支中

    0热度

    1回答

    我们最近从CVS切换到Git,并使用Vincent Driessen的successful Git branching model与master分支和develop分支,它合并回master。我们从Git中的一个项目开始,现在我们有两个单独的项目,它们使用子模块中的一些通用代码(common)。最近另一个项目对我们没有做好准备的develop进行了更改,在我们更新了自己的代码之前,我们不能将任何更

    4热度

    1回答

    希望这将是一个简单的问题。我对git比较陌生,有些东西我还是不会...... git。 假设的情况: 假设开发分支包含两次提交,C1和C2。 在c2之后创建发布分支,因此发布分支也包含c1和c2。 然后决定c1需要推迟到以后的版本。 将发行分支合并回开发时,如果不从发布分支中删除c1,推荐从发布分支中删除c1的方法是什么?

    1热度

    1回答

    假设您目前处于产品的第3版,并且您的下一个版本为4.但是您的功能比开发周期需要花费更长的时间,例如不会准备好,直到版本5,(可能会更长)。在git-flow中处理这个问题的最好方法是什么?在我看来,这种工作流程并不真的允许这样的事情。在下一个版本之后,没有真正的发行版本。 在我使用工作的地方,我们有一个下一个版本的分支,例如上面的例子中的release/4。并且主分支将在下一个版本之后发布,即版本