Hi Piotr,
yeah, you're right that right now is very rare case, but just want to point
a well known strategy that is widely used all over the world and that could
make people coming to us more confident in our technology.
2017-10-06 11:41 GMT+02:00 Piotr Zarzycki :
> Carlos,
>
> But we are
Carlos,
But we are doing branches if someone is working on some bigger features/bug
fix. However sometimes we are fixing some minor things, founded ad hoc, so
I think full flow development will not be possible. I don't remember that
we have had so much critical develop breaking, from time to time
Hi Olaf,
that's basically what I do. I must say that as gitflow was launched we
couldn't use any of the scripts that propose.
Don't remember why, but we had some problems at that time and never try It
again.
But the concepts in [1] are in essence what I propose.
In Royale everybody end committin
I don't know if it is still used by people but am using the gitflow [1][2]
branching model here with our internal git repos and I am happy with it.
It is easy to create and merge feature, release, hotfix or other branches by
using it and it follows some basic rules.
E.g. the command "git flow featu
Hi Piotr,
as you requested, I'm compying from other threads what I think it's the
best proven workflow to work (as I saw it in many projects):
I think what Piotr propose is very good for organization, revision and
matching with issues. The workflow I know (and I think works pretty well)
is the fo
Hi Guys,
I thought that would be could to share some vision about how could we work
with our GitHub repository.
COMMITS:
This parts is only regards when we have issue raised. Each commit should
have description and issue number. I will use as an example our issue
raised for renaming. [1]
If you
