{"thread":{"id":"21585","subject":"Working on merged branches whilst seeing current master","startedAt":"2009-11-11T17:16:46Z","lastAt":"2009-11-26T12:45:50Z","messageCount":7,"participants":["rhlee","Nicolas Sebrecht","Tim Mazid"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"127354","messageId":"1257959806206-3987667.post@n2.nabble.com","threadId":"21585","inReplyTo":null,"subject":"Working on merged branches whilst seeing current master","fromName":"rhlee","fromEmail":"richard@webdezign.co.uk","sentAt":"2009-11-11T17:16:46Z","receivedAt":"2009-11-11T17:16:46Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"\nHi again gits,\n\nI think my current query is somewhat related to my previous issue of\n\"Preserving branches after merging on ancestor\" that you help me with last\ntime (many thanks).\n\nI use branches for features. I have a branch and I merged it into my master\nbranch as I thought it was finished. But it turns out I wasn't and so I need\nto work on it again.\n\nI have made some more changes (branches and merges) on master. So what I\nshould do is checkout that branch, work on it committing along the way and\nthen merge it again onto my master branch.\n\nHowever I though I am working on a feature branch I want to be also working\nfrom the master branch as reference. Yes I know I probably should not be\nworking like this. My branches should be wholly independent. But I doing web\ndevelopment not kernel development so there is much less modularity and\nbranches/features have a tendency to creep into one another. If you want to\nget and idea of my workflow see my thread last week \"Preserving branches\nafter merging on ancestor\".\n\nSo how do I work again on a branch that has been preiously merged whilst\n\"seeing\" the current changes on the master or another branch?\n\nIs this a bad idea first of all. Should I change my workflow instead?\n\nIf I do try to do this I guess I got several ways.\n\nI think I could pull(?) or merge the changes so far from the master branch\ninto the feature branch. But this seems like an uneccesary duplication.\n\nOr should I just create a new branch? But if I do this there is no link\nbetween the old and new branch.\n\nRichard\n-- \nView this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3987667.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"127384","messageId":"20091111215727.GK27518@vidovic","threadId":"21585","inReplyTo":"1257959806206-3987667.post@n2.nabble.com","subject":"Re: Working on merged branches whilst seeing current master","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-11T21:57:27Z","receivedAt":"2009-11-11T21:57:27Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 11/11/09, rhlee wrote:\n> \n> I use branches for features. I have a branch and I merged it into my master\n> branch as I thought it was finished. But it turns out I wasn't and so I need\n> to work on it again.\n> \n> I have made some more changes (branches and merges) on master. So what I\n> should do is checkout that branch, work on it committing along the way and\n> then merge it again onto my master branch.\n> \n> However I though I am working on a feature branch I want to be also working\n> from the master branch as reference.\n\nIf the feature branch is merged to the mainline, it should really mean\nthat the feature is ready : the feature branch life stop here. This also\nmeans that if you see that this feature was not as ready as you thought,\nyou have to restart a _new_ feature branch off of the mainline.\n\nThat's why there is the \"next\" branch in the git releases process. This\nway, we can test the feature branches without touching master for some\ntime.\n\n>                                      Yes I know I probably should not be\n> working like this. My branches should be wholly independent. But I doing web\n> development not kernel development so there is much less modularity and\n> branches/features have a tendency to creep into one another.\n\nThis should not be the case. Modularity in the release process and the\ndevelopment strategy is not tied to \"what I am developing\". I'm doing\nsome web development too and have no difficulty around this point.\n\n> Or should I just create a new branch? But if I do this there is no link\n> between the old and new branch.\n\nYes, feature branches have no reason to live after they are merged to\nthe mainline.\n\n-- \nNicolas Sebrecht\n"},{"id":"127440","messageId":"1258030118389-3992599.post@n2.nabble.com","threadId":"21585","inReplyTo":"20091111215727.GK27518@vidovic","subject":"Re: Working on merged branches whilst seeing current master","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2009-11-12T12:48:38Z","receivedAt":"2009-11-12T12:48:38Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n\nNicolas Sebrecht-3 wrote:\n> \n> The 11/11/09, rhlee wrote:\n>> \n>> I use branches for features. I have a branch and I merged it into my\n>> master\n>> branch as I thought it was finished. But it turns out I wasn't and so I\n>> need\n>> to work on it again.\n>> \n>> I have made some more changes (branches and merges) on master. So what I\n>> should do is checkout that branch, work on it committing along the way\n>> and\n>> then merge it again onto my master branch.\n>> \n>> However I though I am working on a feature branch I want to be also\n>> working\n>> from the master branch as reference.\n> \n> If the feature branch is merged to the mainline, it should really mean\n> that the feature is ready : the feature branch life stop here. This also\n> means that if you see that this feature was not as ready as you thought,\n> you have to restart a _new_ feature branch off of the mainline.\n> \n\nActually, there's no reason you couldn't just 'git reset HEAD^' once you\nrealise that the branch isn't ready. If you want to see the changes from\nmaster, you could just merge that into your branch. If you just want to see\nthe content in master, you could use gitk or gitg, which allows you to view\nfiles at any commit.\n\nPersonally, I merge master into my branches, test and check, and fix, then\nmerge the branch into master. This sometimes results in a fast-forward, if\nyou haven't made changes to master. If you don't like that, you can always\nuse the --no-ff option, though.\n\nGood luck,\nTim.\n-- \nView this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3992599.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"127444","messageId":"1258037862366-3993313.post@n2.nabble.com","threadId":"21585","inReplyTo":"20091111215727.GK27518@vidovic","subject":"Re: Working on merged branches whilst seeing current master","fromName":"rhlee","fromEmail":"richard@webdezign.co.uk","sentAt":"2009-11-12T14:57:42Z","receivedAt":"2009-11-12T14:57:42Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"\nThanks for the help Nicolas,\n\nThat cleared up the issue a lot for me.\n\n\nNicolas Sebrecht-3 wrote:\n> \n>>                                      Yes I know I probably should not be\n>> working like this. My branches should be wholly independent. But I doing\n>> web\n>> development not kernel development so there is much less modularity and\n>> branches/features have a tendency to creep into one another.\n> \n> This should not be the case. Modularity in the release process and the\n> development strategy is not tied to \"what I am developing\". I'm doing\n> some web development too and have no difficulty around this point.\n> \n\nJust to clarify. Do you mean that this should not be the case that you get\nfeature creep in branches or the fact that this happens does interfere with\nyour release process/development strategy.\n\nRegards,\n\nRichard\n-- \nView this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3993313.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"127447","messageId":"20091112151425.GD25398@vidovic","threadId":"21585","inReplyTo":"1258037862366-3993313.post@n2.nabble.com","subject":"Re: Working on merged branches whilst seeing current master","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-12T15:14:25Z","receivedAt":"2009-11-12T15:14:25Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 12/11/09, rhlee wrote:\n> Nicolas Sebrecht-3 wrote:\n> > \n> >>                                      Yes I know I probably should not be\n> >> working like this. My branches should be wholly independent. But I doing\n> >> web\n> >> development not kernel development so there is much less modularity and\n> >> branches/features have a tendency to creep into one another.\n> > \n> > This should not be the case. Modularity in the release process and the\n> > development strategy is not tied to \"what I am developing\". I'm doing\n> > some web development too and have no difficulty around this point.\n> \n> Just to clarify. Do you mean that this should not be the case that you get\n> feature creep in branches or the fact that this happens does interfere with\n> your release process/development strategy.\n\nI mean that the independency of the feature branches is mostly relying\non \"what do I (as a developer) commit in this branch\", which is really\ntied to \"how to write nice atomic commits\" (easily reversible, etc).\n\nThis must be applicable whatever the product/software you're working on\nand it is applicable for web development too.\n\n-- \nNicolas Sebrecht\n"},{"id":"127456","messageId":"1258044562803-3994102.post@n2.nabble.com","threadId":"21585","inReplyTo":"1258030118389-3992599.post@n2.nabble.com","subject":"Re: Working on merged branches whilst seeing current master","fromName":"rhlee","fromEmail":"richard@webdezign.co.uk","sentAt":"2009-11-12T16:49:22Z","receivedAt":"2009-11-12T16:49:22Z","isPatch":false,"sender":{"key":"richard@webdezign.co.uk","avatar":"https://gravatar.com/avatar/36c0bc285b2d30baa54ed2e1488161fd27a4a4a8128836a673b66204ab08c9b7?d=mp&s=160"},"body":"\n\nTim Mazid wrote:\n> \n> Actually, there's no reason you couldn't just 'git reset HEAD^' once you\n> realise that the branch isn't ready. If you want to see the changes from\n> master, you could just merge that into your branch. If you just want to\n> see the content in master, you could use gitk or gitg, which allows you to\n> view files at any commit.\n> \n> Personally, I merge master into my branches, test and check, and fix, then\n> merge the branch into master. This sometimes results in a fast-forward, if\n> you haven't made changes to master. If you don't like that, you can always\n> use the --no-ff option, though.\n> \n\nI don't think 'git reset HEAD^' would work in my case as that only goes back\none commit. I may have made many other changes on the master branch that I\nwant to keep.\n\nBy merging from master into your branch, like you said, you get a nice graph\nview that shows what you've brought into your branch from master since you\nlast left off. But doesn't this goes against the idea that branches should\nbe independent, by bringing in changes from master?\n-- \nView this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3994102.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"128458","messageId":"1259239550525-4070977.post@n2.nabble.com","threadId":"21585","inReplyTo":"1258044562803-3994102.post@n2.nabble.com","subject":"Re: Working on merged branches whilst seeing current master","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2009-11-26T12:45:50Z","receivedAt":"2009-11-26T12:45:50Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n\nrhlee wrote:\n> \n> \n> Tim Mazid wrote:\n>> \n>> Actually, there's no reason you couldn't just 'git reset HEAD^' once you\n>> realise that the branch isn't ready. If you want to see the changes from\n>> master, you could just merge that into your branch. If you just want to\n>> see the content in master, you could use gitk or gitg, which allows you\n>> to view files at any commit.\n>> \n>> Personally, I merge master into my branches, test and check, and fix,\n>> then merge the branch into master. This sometimes results in a\n>> fast-forward, if you haven't made changes to master. If you don't like\n>> that, you can always use the --no-ff option, though.\n>> \n> \n> I don't think 'git reset HEAD^' would work in my case as that only goes\n> back one commit. I may have made many other changes on the master branch\n> that I want to keep.\n> \n> By merging from master into your branch, like you said, you get a nice\n> graph view that shows what you've brought into your branch from master\n> since you last left off. But doesn't this goes against the idea that\n> branches should be independent, by bringing in changes from master?\n> \n\nYup, you only need to 'git reset HEAD^' on the master branch to undo the\nmerge. Isn't that what you wanted?\n\nAnd yeah, I suppose it kind of does. But once again, you can 'git reset\nHEAD^'. And since you're merging master INTO the branches, you are keeping\nthe branches independent, anyway.\n-- \nView this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p4070977.html\nSent from the git mailing list archive at Nabble.com.\n"}]}