{"thread":{"id":"24699","subject":"workflow for working on feature branches and incrementally incorporating \"master\" changes","startedAt":"2010-08-10T20:20:16Z","lastAt":"2010-08-13T20:38:56Z","messageCount":6,"participants":["Bradley Wagner","Ævar Arnfjörð Bjarmason","Chris Mear","Joshua Shrader","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147682","messageId":"AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com","threadId":"24699","inReplyTo":null,"subject":"workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Bradley Wagner","fromEmail":"bradley.wagner@hannonhill.com","sentAt":"2010-08-10T20:20:16Z","receivedAt":"2010-08-10T20:20:16Z","isPatch":false,"sender":{"key":"bradley.wagner@hannonhill.com","avatar":"https://gravatar.com/avatar/8304e5020b13d5f8102220fae2f5dd607a2e114dbe62bbd92c1ab38fe0b69fdb?d=mp&s=160"},"body":"If you're working on a feature branch by yourself, what is a good\nworkflow for keeping the branch in up-to-date with \"master\" as you're\ndeveloping on the feature branch or is this unnecessary? Should you\njust wait until you want to officially integrate the feature branch\ninto the \"master\"?\n\nWe were doing:\n\ncommit to local feature branch\npush to remote feature branch\n... repeat....\nrebase from master (occasionally)\npush to remote\n\nbut at this point the branches have diverged.\n\nWe're coming at this from SVN, so we might just be thinking about this\nthe wrong way.\n\nThanks!\n"},{"id":"147689","messageId":"AANLkTi=VpQcR3qY+ML0rbe_CEptEKsXpD0noPqpGJu3s@mail.gmail.com","threadId":"24699","inReplyTo":"AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com","subject":"Re: workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-10T21:02:05Z","receivedAt":"2010-08-10T21:02:05Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Aug 10, 2010 at 20:20, Bradley Wagner\n wrote:\n\n> We're coming at this from SVN, so we might just be thinking about this\n> the wrong way.\n\nWhat workflow did you use with SVN? Did it use branches? If so you\ncould just use that.\n"},{"id":"147692","messageId":"AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com","threadId":"24699","inReplyTo":"AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com","subject":"Re: workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Chris Mear","fromEmail":"chrismear@gmail.com","sentAt":"2010-08-10T22:05:16Z","receivedAt":"2010-08-10T22:05:16Z","isPatch":false,"sender":{"key":"chrismear@gmail.com","avatar":null},"body":"On 10 August 2010 21:20, Bradley Wagner wrote:\n> If you're working on a feature branch by yourself, what is a good\n> workflow for keeping the branch in up-to-date with \"master\" as you're\n> developing on the feature branch or is this unnecessary? Should you\n> just wait until you want to officially integrate the feature branch\n> into the \"master\"?\n>\n> We were doing:\n>\n> commit to local feature branch\n> push to remote feature branch\n> ... repeat....\n> rebase from master (occasionally)\n> push to remote\n>\n> but at this point the branches have diverged.\n>\n> We're coming at this from SVN, so we might just be thinking about this\n> the wrong way.\n\nGit's rebase feature is a *very* nice, clean way to keep a feature\nbranch up to date with the master branch. But, as you've seen,\nrebasing can make things a bit confusing you need to push that feature\nbranch to other people.\n\nI've found that a good rule of thumb is to never rewrite (i.e. rebase)\nbranches that have already been shared with others. Of course there's\nnothing impossible or fundamentally bad about pushing rewritten\nbranches like this. But, unless people are expecting it to happen and\nknow how to deal with it when they pull, it can cause confusion,\nparticularly on teams that are just getting acquainted with Git.\n\nInstead, if a feature branch is going to be shared with others, and\nit's going to be long-lived, then we keep it up-to-date by merging\nfrom master every now and again, rather than rebasing.\n\nOn the other hand, if I'm working on a feature branch by myself, and I\nhaven't shared it with anyone yet, I frequently rebase against master\nto keep things clean. I also use interactive rebase a lot to tidy up\ncommits. But as soon as I've shared my branch with the team, I no\nlonger do any rebasing/rewriting.\n\nIf there are Git wizards on your team, it is true that they may find\nthis an inflexible way of working. But I've found it to be a good\ncompromise between ease of pulling and maintaining a clean commit\nhistory.\n\nChris\n"},{"id":"147696","messageId":"AANLkTim8ALA++TS2SsOCxW50f98Q3ADtJgx4H9cF_=pn@mail.gmail.com","threadId":"24699","inReplyTo":"AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com","subject":"Re: workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Joshua Shrader","fromEmail":"jshrader83@gmail.com","sentAt":"2010-08-10T22:26:16Z","receivedAt":"2010-08-10T22:26:16Z","isPatch":false,"sender":{"key":"jshrader83@gmail.com","avatar":null},"body":"To elaborate on Chris's response, as an alternative to merging to\nfeature from master repeatedly, you may want to take a look at git\nrerere. The \"Discussion\" section at\nhttp://www.kernel.org/pub/software/scm/git/docs/git-rerere.html\nexplains a workflow where this feature is useful. You don't rebase,\nand so preserve where the feature originally branched, but you also\navoid multiple merge commits from master that may clutter the commit\nhistory. Essentially, you do a merge, resolve any conflicts, and then\nback out of the merge with git reset --hard HEAD^. This removes the\nmerge commit, but rerere remembers all of the conflicts that you\nresolved. When you repeat this process the next time, you won't have\nto re-resolve conflicts that you've already taken care of.\n\nEssentially, the history looks like you've developed the feature in\ncomplete isolation of master, and fixed all of the conflicts at once\nduring the only publicly visible merge commit from feature back to\nmaster. But what you've really done is solved the conflicts little by\nlittle, so the final merge isn't a huge pain in the *ss.\n\nThis is probably a more advanced use case, and so might not be the\nbest approach to a team just getting their feet wet with Git, but\nstill, it's a workflow that does what you're asking.\n\nOn Tue, Aug 10, 2010 at 6:05 PM, Chris Mear wrote:\n> On 10 August 2010 21:20, Bradley Wagner wrote:\n>> If you're working on a feature branch by yourself, what is a good\n>> workflow for keeping the branch in up-to-date with \"master\" as you're\n>> developing on the feature branch or is this unnecessary? Should you\n>> just wait until you want to officially integrate the feature branch\n>> into the \"master\"?\n>>\n>> We were doing:\n>>\n>> commit to local feature branch\n>> push to remote feature branch\n>> ... repeat....\n>> rebase from master (occasionally)\n>> push to remote\n>>\n>> but at this point the branches have diverged.\n>>\n>> We're coming at this from SVN, so we might just be thinking about this\n>> the wrong way.\n>\n> Git's rebase feature is a *very* nice, clean way to keep a feature\n> branch up to date with the master branch. But, as you've seen,\n> rebasing can make things a bit confusing you need to push that feature\n> branch to other people.\n>\n> I've found that a good rule of thumb is to never rewrite (i.e. rebase)\n> branches that have already been shared with others. Of course there's\n> nothing impossible or fundamentally bad about pushing rewritten\n> branches like this. But, unless people are expecting it to happen and\n> know how to deal with it when they pull, it can cause confusion,\n> particularly on teams that are just getting acquainted with Git.\n>\n> Instead, if a feature branch is going to be shared with others, and\n> it's going to be long-lived, then we keep it up-to-date by merging\n> from master every now and again, rather than rebasing.\n>\n> On the other hand, if I'm working on a feature branch by myself, and I\n> haven't shared it with anyone yet, I frequently rebase against master\n> to keep things clean. I also use interactive rebase a lot to tidy up\n> commits. But as soon as I've shared my branch with the team, I no\n> longer do any rebasing/rewriting.\n>\n> If there are Git wizards on your team, it is true that they may find\n> this an inflexible way of working. But I've found it to be a good\n> compromise between ease of pulling and maintaining a clean commit\n> history.\n>\n> Chris\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"147697","messageId":"AANLkTimd1z746ptjJmu_Ytqep1VwR7Hrr6bC4b6kw72w@mail.gmail.com","threadId":"24699","inReplyTo":"AANLkTi=h2MbSKmQk9p6w44WORAa8XzkpF0nBXKOgJ4T1@mail.gmail.com","subject":"Re: workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-08-10T22:32:19Z","receivedAt":"2010-08-10T22:32:19Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"I'll describe the workflow that works very well for me.\n\nI use a single branch, working, as a working branch. I NEVER publish\nthe tip of this branch. Rather, it always contains my working tree\nwhich consists of:\n\n- a base, which is a merge of:\n - completed work I have yet to publish\n - the upstream branch, as pulled at some previous time\n - fixes from other people that have yet to be integrated into the upstream\n- a linear series of one or more commits that I am currently working on\n- the tip, or HEAD of the working branch.\n\nHere are some typical workflows:\n\n- pull from upstream:\n\n - fetch the upstream (git fetch upstream)\n - checkout the branch tracking the BASE of my working branch (git\ncheckout working-base)\n - merge with the upstream (git merge upstream/master)\n - rebase the linear bit of my work on that (git rebase working-base working)\n\n- isolate some work as a fix to some upstream build tag (BUILD-XXXX)\n - fetch tags from upstream (git fetch upstream refs/tags/*:refs/tags/*)\n - create a new branch for the topic (git branch topic HEAD)\n - create a new base branch for the topic (git branch topic-base HEAD~N)\n - rebase the topic onto the BUILD-XXX tag (git rebase --onto\nBUILD-XXX topic-base topic && git branch -f topic-base BUILD-XXX)\n - merge the topic into the base of my working branch (git checkout\nworking-base && git merge topic)\n - rebase the remainder of the working branch onto the updated\nworking-base (git rebase working-base working)\n\n- patch a previously isolated topic with the top commit from the working branch\n - create a temporary branch for the fix ( git branch -f topic-fix\nHEAD && git rebase --onto topic HEAD~1 topic-fix)\n - update the topic ( git checkout topic && git merge --ff-only\ntopic-fix && git branch -d topic-fix)\n - merge the topic back into the base of my working tree ( git\ncheckout working-base && git merge topic && git rebase working-base\nworking)\n\n- publish a topic\n - git tag topic-XXX topic && git branch -f topic-base topic-XXX &&\ngit push public topic-XXXX\n\n- integrate a tag someone else has published into my base\n - git checkout working-base && git merge other-topic-XXX && git\nrebase working-base working\n\nThis way of working has some very nice properties:\n\n* the base of my working branch (working-base) contains all my\n_dependencies_, that is:\n * the upstream branch\n * my finished, but un-integrated work\n * other people's finished but un-integrated work\n\n* integrating dependencies is done the same way, irrespective of where\nthey come from, e.g.:\n\n git checkout working-base && git merge dependency && git rebase\nworking-base working\n\n* the base of my branch is a merge hell, but I don't care, because it\nis built from well known, relatively stable dependencies - I can throw\nit away and rebuild it any time relatively easily.\n\n* my working tree remains stable - it always contains stuff I have\nrecently worked on, or stuff I want\n\n* my topic branches remain clean and uncluttered with merges, so I can\nrelease them to others without dragging unwanted stuff along\n\n* merges tend to be trivial, since they are based on stable work.\nrebases are usually easy, because they are used only used on a\nrelatvely small amount on unpublished, unstable work\n\nThis only downside to the workflow is the complexity of using an extra\nbranch (working-base) to track the base of the working branch. If you\nforget to update it, you can accidentally do some stupid things (which\ncan be fixed by using the info in git reflog).\n\nIn fact, this workflow is so useful to me, that I believe it needs its\nown git porcelain to assist with the management. I am, in fact,\ndeveloping two commands to do just this: git base and git work.\n\ngit base manages the base of the branch (using a reference called\nrefs/bases/) while git work helps to manage the workflow of\nmaintaining the base of the branch. With these two (as yet unpublished\ncommands), the workflows above become as simple as:\n\n * initialise the base: git base set upstream/master\n * sync with upsteam: git work merge upstream/master\n * merge with some dependency: git work merge dependency-XXXX\n * create a new topic from recent work: git work create topic HEAD~N BUILD-XXX\n * update an existing topic with recent work: git work update topic HEAD~N\n * rebase onto a clean base: git work rebase BUILD-XXX\n * visualize just the current work: gitk $(git work) (which expands\nas gitk $(git base)..working or gitk refs/bases/working..working)\n etc.\n\nI hope to have time to release some feature stable contributions in a\nweek or two...stay tuned.\n\nRegards,\n\njon.\n\n\nOn Wed, Aug 11, 2010 at 6:20 AM, Bradley Wagner\n wrote:\n> If you're working on a feature branch by yourself, what is a good\n> workflow for keeping the branch in up-to-date with \"master\" as you're\n> developing on the feature branch or is this unnecessary? Should you\n> just wait until you want to officially integrate the feature branch\n> into the \"master\"?\n>\n> We were doing:\n>\n> commit to local feature branch\n> push to remote feature branch\n> ... repeat....\n> rebase from master (occasionally)\n> push to remote\n>\n> but at this point the branches have diverged.\n>\n> We're coming at this from SVN, so we might just be thinking about this\n> the wrong way.\n>\n> Thanks!\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"148020","messageId":"AANLkTi=tJ1i6C5WANY0qP1Zz1aa5HBAq7+-Ft4sa=+TE@mail.gmail.com","threadId":"24699","inReplyTo":"AANLkTi=vscGSErrV_6xBqmryc1hFqi4bjmyOTVgTLNsS@mail.gmail.com","subject":"Re: workflow for working on feature branches and incrementally incorporating \"master\" changes","fromName":"Bradley Wagner","fromEmail":"bradley.wagner@hannonhill.com","sentAt":"2010-08-13T20:38:56Z","receivedAt":"2010-08-13T20:38:56Z","isPatch":false,"sender":{"key":"bradley.wagner@hannonhill.com","avatar":"https://gravatar.com/avatar/8304e5020b13d5f8102220fae2f5dd607a2e114dbe62bbd92c1ab38fe0b69fdb?d=mp&s=160"},"body":"Thanks for the explanation Chris! That definitely helps.\n\n> > If you're working on a feature branch by yourself, what is a good\n> > workflow for keeping the branch in up-to-date with \"master\" as you're\n> > developing on the feature branch or is this unnecessary? Should you\n> > just wait until you want to officially integrate the feature branch\n> > into the \"master\"?\n> >\n> > We were doing:\n> >\n> > commit to local feature branch\n> > push to remote feature branch\n> > ... repeat....\n> > rebase from master (occasionally)\n> > push to remote\n> >\n> > but at this point the branches have diverged.\n> >\n> > We're coming at this from SVN, so we might just be thinking about this\n> > the wrong way.\n>\n> Git's rebase feature is a *very* nice, clean way to keep a feature\n> branch up to date with the master branch. But, as you've seen,\n> rebasing can make things a bit confusing you need to push that feature\n> branch to other people.\n>\n> I've found that a good rule of thumb is to never rewrite (i.e. rebase)\n> branches that have already been shared with others. Of course there's\n> nothing impossible or fundamentally bad about pushing rewritten\n> branches like this. But, unless people are expecting it to happen and\n> know how to deal with it when they pull, it can cause confusion,\n> particularly on teams that are just getting acquainted with Git.\n\nTwo questions here.\n\nFirst, the command to rebase based off another branch that is *not*\nthe upstream branch involves --onto, correct? For example, if I've\nbeen working on branch awesome_feature and I want to rebase using all\nthe work that's been done in master since my branch was created, would\nI use: \"git rebase --onto master \"\n\nSecondly, as someone pulling a branch that has been rewritten, do I\nuse the --force flag: \"git pull --force\" or will rebasing suffice?\n\n> Instead, if a feature branch is going to be shared with others, and\n> it's going to be long-lived, then we keep it up-to-date by merging\n> from master every now and again, rather than rebasing.\n>\n> On the other hand, if I'm working on a feature branch by myself, and I\n> haven't shared it with anyone yet, I frequently rebase against master\n> to keep things clean. I also use interactive rebase a lot to tidy up\n> commits. But as soon as I've shared my branch with the team, I no\n> longer do any rebasing/rewriting.\n>\n> If there are Git wizards on your team, it is true that they may find\n> this an inflexible way of working. But I've found it to be a good\n> compromise between ease of pulling and maintaining a clean commit\n> history.\n>\n> Chris\n"}]}