Right now I could use the develop branch because I have made the
modifications that remove the old solution files and updates the solution
to visual studio 2015. It makes no sense to make those changes either in
the feature branch, nore the master branch but I would like to push those
changes somew
The master branch holding only production tags is useful for making a
production hotfix release. For example, this would be useful in making
security patches. As for holding release branches, in my use of git-flow,
I've always deleted them after merging back to develop&master, but in
theory, it cou
Hi
Gary Gregory wrote on 19.05.2017 23:01:10:
> Howdy,
>
> Thank you for the link.
>
> This is fine until you want to manage more than once major version in
one
> repo, right?
>
> Over at HttpComponents, we have decided for now to keep to one repo, as
> opposed to one repo per major version.
On 2017-05-21, Dominik Psenner wrote:
> To me the gitflow concept boils down to a way of tydying up the
> historical mess that piles up over the years. The branch
> feature/RollingFileAppender-NG dates actually back to 2012. I'd be
> happy already if we had a naming convention for the different br
To me the gitflow concept boils down to a way of tydying up the historical
mess that piles up over the years. The branch
feature/RollingFileAppender-NG dates actually back to 2012. I'd be happy
already if we had a naming convention for the different branch types. From
the branch name alone it is at
On 2017-05-19, Dominik Psenner wrote:
> would we like to use gitflow for our named branches? [1]
I've used gitflow in one or two projects at work and we've never really
come to a situation where having the release branch really helped. Maybe
because we didn't create bug fix releases on a regular
Re-reading my last mail I'm afraid that I did a poor job with explaining of
what is going on in my head. I hope that this little follow-up helps.
To me a typical gitflow usecase is to make development on the develop
branch. Larger portions of features should be done on feature branches that
branch
If I understand the usecase correctly, then there should be these branches:
* master
* release/4.4.1.x
* release/4.4.2.x
Note that there could be even more branches if "unstable" development
continues on the develop branch or a bugfix branch is needed to create a
bugfix on a released (i.e. tagged
Howdy,
Thank you for the link.
This is fine until you want to manage more than once major version in one
repo, right?
Over at HttpComponents, we have decided for now to keep to one repo, as
opposed to one repo per major version.
So ATM for example in HttpComponents' HttpCore we have a 4.4.x and
Hi,
would we like to use gitflow for our named branches? [1]
[1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
Cheers
--
Dominik Psenner
10 matches
Mail list logo
