Opinions on my GIT model

julia· Jan 19, 2011, 19:33 UTC · lore

Hi All,

Working on a GIT model for my projects.

1.  Three main repositories, bare public repo, maintainer repo, developer
repo
2.  Developer1 clones the public repo and makes feature1 branch, updates,
commits changes and pulls/pushes.
3.  Developer2 on their local repo does the same thing and pushes updates.
4.  Maintainer get the green light to rebase feature1 branch with master -
they pull the whole repo, rebase the feature1 branch with master and then
push feature1.
5.  Developer1 pulls feature1 brach again and continues to work, does a
pull/push to feature1 on public repo.

Now, main question is - given that in step 4 maintainer rebase the feature branch with master then pushed, he is committing a cardinal sin by rebasing a branch that has already been pushed to the public repo, so if anyone has made any changes based on the commits originally pushed that now have been rebased - developer who tries to push those changes will have issues.

Will these be solved by executing of a pull?

Sorry if these are trivial questions...still trying to wrap my head around GIT.

Thank you for your help.

Cheers,

Julia

-- 
View this message in context: http://git.661346.n2.nabble.com/Opinions-on-my-GIT-model-tp5941048p5941048.html
Sent from the git mailing list archive at Nabble.com.

Ramkumar Ramachandra· Jan 20, 2011, 04:33 UTC · re: julia · lore

Re: Opinions on my GIT model

Hi Julia,

julia writes:

Show 12 quoted lines

> Working on a GIT model for my projects.
> 
> 1.  Three main repositories, bare public repo, maintainer repo, developer
> repo
> 2.  Developer1 clones the public repo and makes feature1 branch, updates,
> commits changes and pulls/pushes.
> 3.  Developer2 on their local repo does the same thing and pushes updates.
> 4.  Maintainer get the green light to rebase feature1 branch with master -
> they pull the whole repo, rebase the feature1 branch with master and then
> push feature1.
> 5.  Developer1 pulls feature1 brach again and continues to work, does a
> pull/push to feature1 on public repo.

Having a mainline + feature branches is a very common development model.

Show 7 quoted lines

> Now, main question is - given that in step 4 maintainer rebase the feature
> branch with master then pushed, he is committing a cardinal sin by rebasing
> a branch that has already been pushed to the public repo, so if anyone has
> made any changes based on the commits originally pushed that now have been
> rebased - developer who tries to push those changes will have issues.
> 
> Will these be solved by executing of a pull?

In many projects, including git.git itself, master's history is never overwritten. Feature branches are merged into `pu`, then into `next`, and finally graduate to `master`. I suppose it's a matter of convinience- you should have atleast one stable branch (ie. `master`) so that developers know what to base their work on.

git-pull.sh is a porcelain-level helper that executes a fetch and performs a kind of merge/ rebase depending on the situation and command-line flags. I'd encourage you to read the manpage and shell script itself and see what all these options are, and how they work.

Finally, I think the merge operation is what you're looking for. Please read git-merge(1).

-- Ram