git-flow | 易学教程

Git branching model strategy

阅读更多关于 Git branching model strategy

问题 We are trying to follow the gitflow branching model, but with a twist. We have have four servers environments where the product can be deployed to, each server serves a purpose : development, internal testing, external testing, and production. DevServer , where developers test their different features, while developing. Developers cannot test locally on their machines, they have to make their changes on the DevServer to be able to test TestServer , where QA testers test multiple features once

Merge a branch with Git Flow keeping the branch still alive

阅读更多关于 Merge a branch with Git Flow keeping the branch still alive

问题 I'm starting using git flow and I understand that doing: git flow feature start my-feature git flow feature finish my-feature I create a feature and then, when i've finished my changes, I merge it with the develop branch. The finish flow command literally delete the feature branch after the merge action. My question is: is there any way using git flow to merge my feature with develop without deleting it after merge. And my second question would be: is this workflow correct? I mean, is it

`git flow release finish` non-interactively

阅读更多关于 `git flow release finish` non-interactively

问题 How I can use git flow release finish in a manner that doesn't ask for merge commit messages? The -m flag doesn't provide this, as I expected. The goal of course is to be able to script this in such a way that doesn't require interaction. 回答1: You can set the environment variable export GIT_MERGE_AUTOEDIT=no git flow release -m 'Merge Message' release_branch_name unset GIT_MERGE_AUTOEDIT It won't invoke the editor for when you merge. If you switch to my fork git-flow AVH Edition you can set

Maven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase

阅读更多关于 Maven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase

问题 Note regarding the accepted answer: I accepted the answer because of strong circumstantial evidence. Nonetheless, this is circumstantial evidence, so take it with a grain of salt. How can I have a plugin be triggered when the user runs a plugin goal, not a lifecycle phase? (This has been asked before, but the answer was to use a lifecycle phase.) Case in point: I need release:branch to invoke regex-plugin to generate a branch with the current version as its name, minus the -SNAPSHOT suffix .

Avoiding maven repository version collision when using feature branches

阅读更多关于 Avoiding maven repository version collision when using feature branches

问题 Question : How do you handle feature branches for maven multi project builds? Jenkins builds and deploys these branches to keep build overhead on developers to a minimum but develop and feature branches cannot build the same maven version or we risk mismatch between artifacts and source. We have a script to change parent version in child poms and version in root pom. While this segregates the branches in maven space, it results in extra work when merging. I think nexus pro staging feature

Why doesn't “git flow feature pull” track?

阅读更多关于 Why doesn't “git flow feature pull” track?

问题 Lets say I've created a new feature with git flow feature start FEATURENAME then published it with git flow feature publish FEATURENAME Now my colleague wants to collaborate on this feature with me, so he does git flow feature pull FEATURENAME This creates a new branch on his local repo, based on the feature branch in the remote repo. This does not however set his local feature branch to track the remote feature branch, so now he has to track this branch manually. What is the reasoning behind

How should gitflow hotfixes work?

阅读更多关于 How should gitflow hotfixes work?

We use Gitflow for our web builds, and I have a question about how hotfixes are supposed to work. But first I should explain that we don't quite use the normal Gitflow workflow. I understand that usually you would branch your features , they would merge into develop when finished, you would create your release , release gets merged into master and you deploy that, as an actual "versioned release". However, as this is client work, we don't do "releases", instead features are deployed as and when they are required, so changes from our feature branches are merged into master on an ad-hoc basis.

Git flow: How to configure a one-click release process in Jenkins?

阅读更多关于 Git flow: How to configure a one-click release process in Jenkins?

问题 We are using the standard git flow branching model (develop, master, release- , hotfix- , etc). As part of our workflow, we would like to set up a "one-click" release via jenkins. I was looking at the jgitflow-maven-plugin. Can I set up this plugin to do a one-click release from jenkins? If so, what are the configuration options? In particular, can I do something like this? Jenkins Job Maven goals: release-start release-finish -Dsomething -Delse And is there a way tell it to automatically

How to push the “develop” branch to the remote “origin”?

阅读更多关于 How to push the “develop” branch to the remote “origin”?

When I do git flow init it creates a master and develop branches. When I add the remote I do git remote add origin git@github.com:NewB/our-repo.git . Now I have git flow initialized on my local repo and I have the remote repo added. After I do git push -u origin master I have master in my origin but not the develop branch. Is there a git flow publish for the develop branch? All I'm seeing are publish for feature or release branches. Does git-flow want me to just use regular git and do git push origin develop ? Daniel Hilgarth Does git-flow want me to just use regular git and do git push origin

Set the develop branch as the default for a pull request

阅读更多关于 Set the develop branch as the default for a pull request

问题 I want to make the pull request merge into develop from the feature branch by default. I'm advocating the use of git flow, so when a pull request is submitted for a feature, the pull request needs to get merged into develop, and not master. Some of the managers commented that being human, there is a possibility that the team leads could overlook that fact and merge the pull request into master by mistake, causing issues with the release later on. We want to mitigate the risks of merge hell so