{"thread":{"id":"43150","subject":"Re: Workflow example for remote repository use of GIT","startedAt":"2006-11-28T15:08:49Z","lastAt":"2006-11-28T16:18:09Z","messageCount":4,"participants":["Jakub Narebski","Shawn Pearce","Johannes Schindelin","Sean Kelley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296854","messageId":"89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com","threadId":"43150","inReplyTo":null,"subject":"Workflow example for remote repository use of GIT","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2006-11-28T15:08:49Z","receivedAt":"2006-11-28T15:08:49Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"I have been trying to set-up a workflow for developers in my group\nusing GIT. I came up with this simplified flow.  Do you all see any\nproblems with this approach?\n\nThanks,\n\nSean\n\n\n\nAlways work out of master\n\n  git checkout master\n\nGetting The Latest Upstream Code into master\n\n  git pull origin master\n\nCreate a topic branch for your development work\n\n  git checkout -b <new topic branch name>\n\nDo your development in the topic branch\n\n  edit/debug/test\n\nCommitting Changes\n\n  git commit -a\n\nSwitch back to master\n\n  git checkout master\n\nUpdate the master branch from origin again\n\n  git pull origin master\n\nNow Merge your topic branch\n\n  git pull . <topic branch to merge into current branch>\n\nHow do I push my changes to the original repository?\n\n  git push origin master\n\n-- \n"},{"id":"296777","messageId":"Pine.LNX.4.63.0611281613330.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43150","inReplyTo":"89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com","subject":"Re: Workflow example for remote repository use of GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-28T15:15:06Z","receivedAt":"2006-11-28T15:15:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nall in all, a good quick start.\n\nOn Tue, 28 Nov 2006, Sean Kelley wrote:\n\n> Getting The Latest Upstream Code into master\n> \n>  git pull origin master\n\nThis gives the impression that the 2nd argument of pull specifies which \n_local_ branch stuff gets merged to. But it means that you pull into the \n_current_ branch from the _remote_ master.\n\nCiao,\nDscho\n\n"},{"id":"296586","messageId":"20061128152524.GA28337@spearce.org","threadId":"43150","inReplyTo":"89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com","subject":"Re: Workflow example for remote repository use of GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-28T15:25:24Z","receivedAt":"2006-11-28T15:25:24Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean Kelley <sean.v.kelley@gmail.com> wrote:\n> I have been trying to set-up a workflow for developers in my group\n> using GIT. I came up with this simplified flow.  Do you all see any\n> problems with this approach?\n...\n> Always work out of master\n> \n>  git checkout master\n> \n> Getting The Latest Upstream Code into master\n> \n>  git pull origin master\n> \n> Create a topic branch for your development work\n> \n>  git checkout -b <new topic branch name>\n\nThat can be streamlined slightly:\n\n  git fetch\n  git checkout -b <new-topic> origin\n\nas fetch would by default download from remote 'origin' and update\nthe tracking branches.  And of course developers may not want to\ncreate their new branch from origin, e.g. if they are doing a bug\nfix to an earlier release of the product.  I think its a good habit\nto be in to always specify the origination point for a branch when\ncreating it.\n \n> Do your development in the topic branch\n> \n>  edit/debug/test\n> \n> Committing Changes\n> \n>  git commit -a\n\nSure, that's CVS-like and rather simple.\n \n> Switch back to master\n> \n>  git checkout master\n> \n> Update the master branch from origin again\n> \n>  git pull origin master\n> \n> Now Merge your topic branch\n> \n>  git pull . <topic branch to merge into current branch>\n\nYes, that works and will get you a merge message like\n\n  Merge branch 'my-topic' into master\n\nwhich is probably what you want if there actually was a merge.\nIf there wasn't (its just a fast-forward) then you won't get the\nmerge message.  It also has the nice property that the \"trunk (if\nthere is such a thing)\" is the first parent in every merge, with\nthe topic(s) in the other parents.\n\nThough I tend to just pull the origin into the current branch\nand push that directly, e.g.:\n\n  git pull origin master\n  git push origin HEAD:master\n\n-- \n"},{"id":"293930","messageId":"ekhncj$1be$1@sea.gmane.org","threadId":"43150","inReplyTo":"89b129c60611280708x10a9c42fia23e6b7770971838@mail.gmail.com","subject":"Re: Workflow example for remote repository use of GIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T16:18:09Z","receivedAt":"2006-11-28T16:18:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sean Kelley wrote:\n\n> I have been trying to set-up a workflow for developers in my group\n> using GIT. I came up with this simplified flow.  Do you all see any\n> problems with this approach?\n> \n> Thanks,\n> \n> Sean\n> \n> \n> \n> Always work out of master\n> \n>   git checkout master\n\nThis conflicts a bit with later \"Create a topic branch\" statement.\nThe statement should be I think twofold: \"Never work out of tracking\nbranches\" (if you use separate remotes, git takes care of that for\nyourself), and for typical workflow \"Always work out of master\nor merge changes into master\".\n \nThis of course deopends on the structure of your repo. For example,\nhow many development branches are there. Git repository uses four\ndevelopment branches: 'maint' (maintenance, stable, bugfixes),\n'master' (trunk, main development, stable), 'next' (development)\nand 'pu' (proposed updates, a kind of topic branch digest).\n\n> Getting The Latest Upstream Code into master\n> \n>   git pull origin master\n\nIt always is \"merge into current branch\".\n\nPlease read what this mean in git-pull(1):\n\n    ?  A parameter <ref> without a colon is equivalent  to  <ref>:  when\n       pulling/fetching,  so  it  merges  <ref>  into the current branch\n       without storing the remote branch anywhere locally.\n\nSo what \"git pull origin master\" do is to fetch _single_ remote branch\n'master' from remote (repository) 'origin' _without_ storing it anywhere\nlocally (with separate remotes it would be 'remotes/origin/master',\nwithout separate remotes it would be 'origin'), and merge it into _current_\nbranch.\n\nWhat you usually want to do, when you are on branch \"master\", is\n\n  git pull origin\n\nor even\n\n  git pull\n\n> Create a topic branch for your development work\n> \n>   git checkout -b <new topic branch name>\n\nOne might want to create topic branch off other commit than HEAD,\nusing\n\n  git checkout -b <new topic branch name> <branch point>\n\n> Do your development in the topic branch\n> \n>   edit/debug/test\n> \n> Committing Changes\n> \n>   git commit -a\n\nDepending on your project policy, it might be \"git commit -a -s\",\ni.e. add signoff line.\n\n> Switch back to master\n> \n>   git checkout master\n> \n> Update the master branch from origin again\n> \n>   git pull origin master\n\nThe same comment as above.\n\nBy the way, this is _not_ CVS, you can merge your topic branch first,\n_then_ pull from origin.\n\n> Now Merge your topic branch\n> \n>   git pull . <topic branch to merge into current branch>\n\nI'd point out that '.' means current repository here.\n\n> How do I push my changes to the original repository?\n> \n>   git push origin master\n\nProbably (and better) just \"git push origin\" if everything is set up\ncorrectly.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"}]}