Javier Domingo Cansino writes:
> I would like to seek for a little more advice. I keep rebasing all my
> work each time master branch is updated, and I would like to know if
> this is usually done or not.
>
> The workflow is not using emails, but each developer has his clone
> where he works, and
Hello!,
I have been using this workflow you suggested, and I happen to find it
really good fitting in many projects I am.
I would like to seek for a little more advice. I keep rebasing all my
work each time master branch is updated, and I would like to know if
this is usually done or not.
The wo
I will start to rebase all feature branches because I have no real
dependency on those, but master needs to have a linear history, as I
build from it regularly, and I need to assure that people can get a
previous version of master.
The problem with that is that I wouldn't be able to have a linear
Javier Domingo writes:
> Hi,
>
> I have been using a very basic workflow for branching, features each
> in a branch.
>
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/* <= Feature and fix branches
> - master <= Integration of the whole feature and fi
rge and remerge it into master, so that I have
>> always just one commit to revert if necessary (instead of the
>> monstrous quantity I have now to).
>>
>> The workflow proposal should be in order of importance:
>> - Let me stay up-to-date with develop branch
>>
t; - Easy to follow
>
> I think I should be capable of doing some sort of merge/rebase
> branching workflow to avoid having to do that. I have thought about
> rebasing always the feature branches, and rebasing master into all of
> them, but it seems pretty strange to me.
>
&g
order of importance:
- Let me stay up-to-date with develop branch
- Easy to revert in master
- Have a clean history
- Easy to follow
I think I should be capable of doing some sort of merge/rebase
branching workflow to avoid having to do that. I have thought about
rebasing always the feature bran
7 matches
Mail list logo
