{"thread":{"id":"26307","subject":"Opinions on my GIT model","startedAt":"2011-01-19T19:33:55Z","lastAt":"2011-01-20T04:33:27Z","messageCount":2,"participants":["julia","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159661","messageId":"1295465635148-5941048.post@n2.nabble.com","threadId":"26307","inReplyTo":null,"subject":"Opinions on my GIT model","fromName":"julia","fromEmail":"deborave@gmail.com","sentAt":"2011-01-19T19:33:55Z","receivedAt":"2011-01-19T19:33:55Z","isPatch":false,"sender":{"key":"deborave@gmail.com","avatar":null},"body":"\nHi All,\n\nWorking on a GIT model for my projects.\n\n1.  Three main repositories, bare public repo, maintainer repo, developer\nrepo\n2.  Developer1 clones the public repo and makes feature1 branch, updates,\ncommits changes and pulls/pushes.\n3.  Developer2 on their local repo does the same thing and pushes updates.\n4.  Maintainer get the green light to rebase feature1 branch with master -\nthey pull the whole repo, rebase the feature1 branch with master and then\npush feature1.\n5.  Developer1 pulls feature1 brach again and continues to work, does a\npull/push to feature1 on public repo.\n\nNow, main question is - given that in step 4 maintainer rebase the feature\nbranch with master then pushed, he is committing a cardinal sin by rebasing\na branch that has already been pushed to the public repo, so if anyone has\nmade any changes based on the commits originally pushed that now have been\nrebased - developer who tries to push those changes will have issues.\n\nWill these be solved by executing of a pull? \n\nSorry if these are trivial questions...still trying to wrap my head around\nGIT.\n\nThank you for your help.\n\nCheers,\n\nJulia\n-- \nView this message in context: http://git.661346.n2.nabble.com/Opinions-on-my-GIT-model-tp5941048p5941048.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"159680","messageId":"20110120043322.GA9493@kytes","threadId":"26307","inReplyTo":"1295465635148-5941048.post@n2.nabble.com","subject":"Re: Opinions on my GIT model","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-01-20T04:33:27Z","receivedAt":"2011-01-20T04:33:27Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Julia,\n\njulia writes:\n> Working on a GIT model for my projects.\n> \n> 1.  Three main repositories, bare public repo, maintainer repo, developer\n> repo\n> 2.  Developer1 clones the public repo and makes feature1 branch, updates,\n> commits changes and pulls/pushes.\n> 3.  Developer2 on their local repo does the same thing and pushes updates.\n> 4.  Maintainer get the green light to rebase feature1 branch with master -\n> they pull the whole repo, rebase the feature1 branch with master and then\n> push feature1.\n> 5.  Developer1 pulls feature1 brach again and continues to work, does a\n> pull/push to feature1 on public repo.\n\nHaving a mainline + feature branches is a very common development\nmodel.\n\n> Now, main question is - given that in step 4 maintainer rebase the feature\n> branch with master then pushed, he is committing a cardinal sin by rebasing\n> a branch that has already been pushed to the public repo, so if anyone has\n> made any changes based on the commits originally pushed that now have been\n> rebased - developer who tries to push those changes will have issues.\n> \n> Will these be solved by executing of a pull? \n\nIn many projects, including git.git itself, master's history is never\noverwritten. Feature branches are merged into `pu`, then into `next`,\nand finally graduate to `master`. I suppose it's a matter of\nconvinience- you should have atleast one stable branch (ie. `master`)\nso that developers know what to base their work on.\n\ngit-pull.sh is a porcelain-level helper that executes a fetch and\nperforms a kind of merge/ rebase depending on the situation and\ncommand-line flags. I'd encourage you to read the manpage and shell\nscript itself and see what all these options are, and how they work.\n\nFinally, I think the merge operation is what you're looking\nfor. Please read git-merge(1).\n\n-- Ram\n"}]}