Opinions on my GIT model

Opinions on my GIT model

[julia]

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.

Re: Opinions on my GIT model

[Ramkumar Ramachandra]

Hi Julia,

julia writes:
> 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.

> 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