{"thread":{"id":"12626","subject":"Git workflow","startedAt":"2008-03-10T12:37:43Z","lastAt":"2008-03-11T05:15:20Z","messageCount":3,"participants":["Peter Gordon","Thomas Harning","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71635","messageId":"1205152663.3470.12.camel@tigger","threadId":"12626","inReplyTo":null,"subject":"Git workflow","fromName":"Peter Gordon","fromEmail":"peter@pg-consultants.com","sentAt":"2008-03-10T12:37:43Z","receivedAt":"2008-03-10T12:37:43Z","isPatch":false,"sender":{"key":"peter@pg-consultants.com","avatar":null},"body":"Hi.\n\nThere are a number of us working on a project. We each have a HEAD, and\nwork on branches, using git-checkout -b MyPatch. When we have finished\nworking on the branch, we move back to the HEAD, with \ngit-checkout master, do a \ngit-pull\nand then git-cherry-pick sha1.....\n\nI have two questions. \n\n1) Is this the normal way to work with git.\n\n2) Also, we sometimes get a log of \nMerge branch 'master' of git://sgit/MyProject which has no commits. Why\ndoes this happen?\n\nThanks,\n\nPeter\n"},{"id":"71640","messageId":"20080310215852.7f4d7ab5@shiva","threadId":"12626","inReplyTo":"1205152663.3470.12.camel@tigger","subject":"Re: Git workflow","fromName":"Thomas Harning","fromEmail":"harningt@gmail.com","sentAt":"2008-03-11T01:58:52Z","receivedAt":"2008-03-11T01:58:52Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"On Mon, 10 Mar 2008 14:37:43 +0200\nPeter Gordon <peter@pg-consultants.com> wrote:\n\n> Hi.\n> \n> There are a number of us working on a project. We each have a HEAD,\n> and work on branches, using git-checkout -b MyPatch. When we have\n> finished working on the branch, we move back to the HEAD, with \n> git-checkout master, do a \n> git-pull\n> and then git-cherry-pick sha1.....\n> \n> I have two questions. \n> \n> 1) Is this the normal way to work with git.\nSince you always work on your own 'branch', you have no need to check\nout a new branch to be independent of others.\nIf you 'do' work on your own branch, the easier way would be to do one\nof the following:\na) git pull\nb) Separate branches for separation..\n  git checkout master\n  git pull -- may cause a merge\n  git merge <your branch> -- if you worked on your own branch..git pull\nc) Get the latest changes and linearize history\n  git fetch\n  git rebase origin/master\n\na - Easiest and more sane\n\tIf you want to work on your own branches you can always\n\twork on that branch and pull updates from the master\nb - Might keep workflow simpler and follows your workflow without\ncherry-picks\nc - Might be good if you create a simple patch and don't care about the\nhistory and haven't published the branch\n> \n> 2) Also, we sometimes get a log of \n> Merge branch 'master' of git://sgit/MyProject which has no commits.\n> Why does this happen?\ngit pull performs explicit merges if your repository is not at the\nexact same point as another.  Depending on what has happened, there\nmight be no code changes, but the history is different (perhaps\nout-of-order 'cherry-picks')\n"},{"id":"71650","messageId":"7vr6ehg7tj.fsf@gitster.siamese.dyndns.org","threadId":"12626","inReplyTo":"1205152663.3470.12.camel@tigger","subject":"Re: Git workflow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-11T05:15:20Z","receivedAt":"2008-03-11T05:15:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Gordon <peter@pg-consultants.com> writes:\n\n> ... When we have finished\n> working on the branch, we move back to the HEAD, with \n> git-checkout master, do a \n> git-pull\n> and then git-cherry-pick sha1.....\n> ...\n> 1) Is this the normal way to work with git.\n\nIt does not look \"normal\" in that I do not see anything that pushes\nyour change back so others can build on top of it.  Also cherry-pick is\nvalid but it probably is easier to use \"git rebase\" frontend.\n\nYou need to answer one policy question at the project level.  Do you want\nthe shared central repository to be a place for your developers to also\nshare their not-quite-ready-for-master-work-in-progress? \n\nAssuming you don't, for the sake of simplicity for now, you can simplify\nthe workflow by dividing it conceptually into two levels:\n\n * shared repository 'master' branch is where everybody meets.  Birds-eye\n   view of what you do is:\n\n   (0) git clone;\n\n   (1) work locally to advance your 'master';\n\n   (2) \"git fetch origin\", followed by \"git rebase remotes/origin\" to make\n       sure your changes come on top of whatever others have done while\n       you were working in step (1);\n\n   (3) \"git push origin master\", which pushes back your 'master', so that\n       others can build on what you did in step (1);\n\n   (4) go back to (1) to work further.\n\n * because you always push your 'master' in step (3) above, as long as you\n   have what you want in your 'master' at that point, it does not matter\n   _how_ you work towards that state in step (1) above.\n\n   You can employ local topic branches (or you can use guilt patch stack),\n   and nobody else needs to know about it.  If you have a long-running\n   work that won't be ready for the shared 'master', you may locally:\n\n   (a) \"git checkout -b my-topic master\";\n\n   (b) work locally whenever you find time;\n\n   (c) \"git checkout master\" if you get interrupted and have more urgent\n       things to do;\n\n   (d) \"git checkout my-topic\" to continue, but from time to time, it\n       would be a good idea to \"git rebase remotes/origin\" while on that\n       branch, and when you are finally done with my-topic, then\n\n   (e) after making sure with (2) above that your 'master' is up-to-date,\n      \"git checkout master\", \"git merge my-topic\".\n\n   (f) then finally \"git push origin master\".\n\n   But you can consider these steps (a)-(e) merely \"implementation\n   details\" of how you would perform (1) above.\n\nOnce you got comfortable with the workflow without topics, more advanced\ndevelopers among you would find local topic branches handy way to organize\ntheir work.  But you do not have to.  And if you do not use local topics,\nthere is no reason to avoid working directly on 'master'.\n"}]}