Re: Opinions on my GIT model

[Ramkumar Ramachandra <artagnon@gmail.com>]

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