Working on merged branches whilst seeing current master

Working on merged branches whilst seeing current master

[rhlee]

Hi again gits,

I think my current query is somewhat related to my previous issue of
"Preserving branches after merging on ancestor" that you help me with last
time (many thanks).

I use branches for features. I have a branch and I merged it into my master
branch as I thought it was finished. But it turns out I wasn't and so I need
to work on it again.

I have made some more changes (branches and merges) on master. So what I
should do is checkout that branch, work on it committing along the way and
then merge it again onto my master branch.

However I though I am working on a feature branch I want to be also working
from the master branch as reference. Yes I know I probably should not be
working like this. My branches should be wholly independent. But I doing web
development not kernel development so there is much less modularity and
branches/features have a tendency to creep into one another. If you want to
get and idea of my workflow see my thread last week "Preserving branches
after merging on ancestor".

So how do I work again on a branch that has been preiously merged whilst
"seeing" the current changes on the master or another branch?

Is this a bad idea first of all. Should I change my workflow instead?

If I do try to do this I guess I got several ways.

I think I could pull(?) or merge the changes so far from the master branch
into the feature branch. But this seems like an uneccesary duplication.

Or should I just create a new branch? But if I do this there is no link
between the old and new branch.

Richard
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3987667.html
Sent from the git mailing list archive at Nabble.com.

Re: Working on merged branches whilst seeing current master

[Nicolas Sebrecht]

The 11/11/09, rhlee wrote:
> 
> I use branches for features. I have a branch and I merged it into my master
> branch as I thought it was finished. But it turns out I wasn't and so I need
> to work on it again.
> 
> I have made some more changes (branches and merges) on master. So what I
> should do is checkout that branch, work on it committing along the way and
> then merge it again onto my master branch.
> 
> However I though I am working on a feature branch I want to be also working
> from the master branch as reference.

If the feature branch is merged to the mainline, it should really mean
that the feature is ready : the feature branch life stop here. This also
means that if you see that this feature was not as ready as you thought,
you have to restart a _new_ feature branch off of the mainline.

That's why there is the "next" branch in the git releases process. This
way, we can test the feature branches without touching master for some
time.

>                                      Yes I know I probably should not be
> working like this. My branches should be wholly independent. But I doing web
> development not kernel development so there is much less modularity and
> branches/features have a tendency to creep into one another.

This should not be the case. Modularity in the release process and the
development strategy is not tied to "what I am developing". I'm doing
some web development too and have no difficulty around this point.

> Or should I just create a new branch? But if I do this there is no link
> between the old and new branch.

Yes, feature branches have no reason to live after they are merged to
the mainline.

-- 
Nicolas Sebrecht

Re: Working on merged branches whilst seeing current master

[Tim Mazid]

Nicolas Sebrecht-3 wrote:
> 
> The 11/11/09, rhlee wrote:
>> 
>> I use branches for features. I have a branch and I merged it into my
>> master
>> branch as I thought it was finished. But it turns out I wasn't and so I
>> need
>> to work on it again.
>> 
>> I have made some more changes (branches and merges) on master. So what I
>> should do is checkout that branch, work on it committing along the way
>> and
>> then merge it again onto my master branch.
>> 
>> However I though I am working on a feature branch I want to be also
>> working
>> from the master branch as reference.
> 
> If the feature branch is merged to the mainline, it should really mean
> that the feature is ready : the feature branch life stop here. This also
> means that if you see that this feature was not as ready as you thought,
> you have to restart a _new_ feature branch off of the mainline.
> 

Actually, there's no reason you couldn't just 'git reset HEAD^' once you
realise that the branch isn't ready. If you want to see the changes from
master, you could just merge that into your branch. If you just want to see
the content in master, you could use gitk or gitg, which allows you to view
files at any commit.

Personally, I merge master into my branches, test and check, and fix, then
merge the branch into master. This sometimes results in a fast-forward, if
you haven't made changes to master. If you don't like that, you can always
use the --no-ff option, though.

Good luck,
Tim.
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3992599.html
Sent from the git mailing list archive at Nabble.com.

Re: Working on merged branches whilst seeing current master

[rhlee]

Tim Mazid wrote:
> 
> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
> realise that the branch isn't ready. If you want to see the changes from
> master, you could just merge that into your branch. If you just want to
> see the content in master, you could use gitk or gitg, which allows you to
> view files at any commit.
> 
> Personally, I merge master into my branches, test and check, and fix, then
> merge the branch into master. This sometimes results in a fast-forward, if
> you haven't made changes to master. If you don't like that, you can always
> use the --no-ff option, though.
> 

I don't think 'git reset HEAD^' would work in my case as that only goes back
one commit. I may have made many other changes on the master branch that I
want to keep.

By merging from master into your branch, like you said, you get a nice graph
view that shows what you've brought into your branch from master since you
last left off. But doesn't this goes against the idea that branches should
be independent, by bringing in changes from master?
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3994102.html
Sent from the git mailing list archive at Nabble.com.

Re: Working on merged branches whilst seeing current master

[Tim Mazid]

rhlee wrote:
> 
> 
> Tim Mazid wrote:
>> 
>> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
>> realise that the branch isn't ready. If you want to see the changes from
>> master, you could just merge that into your branch. If you just want to
>> see the content in master, you could use gitk or gitg, which allows you
>> to view files at any commit.
>> 
>> Personally, I merge master into my branches, test and check, and fix,
>> then merge the branch into master. This sometimes results in a
>> fast-forward, if you haven't made changes to master. If you don't like
>> that, you can always use the --no-ff option, though.
>> 
> 
> I don't think 'git reset HEAD^' would work in my case as that only goes
> back one commit. I may have made many other changes on the master branch
> that I want to keep.
> 
> By merging from master into your branch, like you said, you get a nice
> graph view that shows what you've brought into your branch from master
> since you last left off. But doesn't this goes against the idea that
> branches should be independent, by bringing in changes from master?
> 

Yup, you only need to 'git reset HEAD^' on the master branch to undo the
merge. Isn't that what you wanted?

And yeah, I suppose it kind of does. But once again, you can 'git reset
HEAD^'. And since you're merging master INTO the branches, you are keeping
the branches independent, anyway.
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p4070977.html
Sent from the git mailing list archive at Nabble.com.

Re: Working on merged branches whilst seeing current master

[rhlee]

Thanks for the help Nicolas,

That cleared up the issue a lot for me.


Nicolas Sebrecht-3 wrote:
> 
>>                                      Yes I know I probably should not be
>> working like this. My branches should be wholly independent. But I doing
>> web
>> development not kernel development so there is much less modularity and
>> branches/features have a tendency to creep into one another.
> 
> This should not be the case. Modularity in the release process and the
> development strategy is not tied to "what I am developing". I'm doing
> some web development too and have no difficulty around this point.
> 

Just to clarify. Do you mean that this should not be the case that you get
feature creep in branches or the fact that this happens does interfere with
your release process/development strategy.

Regards,

Richard
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3993313.html
Sent from the git mailing list archive at Nabble.com.

Re: Working on merged branches whilst seeing current master

[Nicolas Sebrecht]

The 12/11/09, rhlee wrote:
> Nicolas Sebrecht-3 wrote:
> > 
> >>                                      Yes I know I probably should not be
> >> working like this. My branches should be wholly independent. But I doing
> >> web
> >> development not kernel development so there is much less modularity and
> >> branches/features have a tendency to creep into one another.
> > 
> > This should not be the case. Modularity in the release process and the
> > development strategy is not tied to "what I am developing". I'm doing
> > some web development too and have no difficulty around this point.
> 
> Just to clarify. Do you mean that this should not be the case that you get
> feature creep in branches or the fact that this happens does interfere with
> your release process/development strategy.

I mean that the independency of the feature branches is mostly relying
on "what do I (as a developer) commit in this branch", which is really
tied to "how to write nice atomic commits" (easily reversible, etc).

This must be applicable whatever the product/software you're working on
and it is applicable for web development too.

-- 
Nicolas Sebrecht