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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html