git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Opinions on my GIT model

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Jan 20, 2011, 04:33 UTC
Message-ID
<20110120043322.GA9493@kytes>
In-Reply-To
<1295465635148-5941048.post@n2.nabble.com>
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
Previous: julia
Message 2 of 2 in “Opinions on my GIT model”
  1. juliaJan 19, 2011
  2. Ramkumar RamachandraJan 20, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.