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
Hi John!,
Thanks a lot for your tip, but I have the problem that I would need to
have a linear history in master (forgot to mention it explicitly) ;(
I build on master branch, and getting to a previous version is hereby needed.
I had thought about the revert workflow, but using --no-commit. I
wo
On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:
> 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 whol
6 matches
Mail list logo
