Workflow question

> Hi,
> 
> I've been trying to think of a git workflow that we could use to replace
> our current svn/svk setup without simply using git in exactly the same
> way that we use svn/svk.
> 
> Basically, we develop, maintain and enhance a website. On the central
> repo is trunk which represents live, and any number of project branches.
> Developers don't use local branches: they check out the project branches
> they're working on and commit to those. Developers merge from trunk to
> project branch from time to time to keep them current, and when a
> project rolls out the branch is merged to trunk.
> 
> In addition to the obvious advantages that git would give us (such as
> properly tracking that code author as opposed to the person who did the
> merge), I'm wanting to gain the following benefits:
> 
>  * The repository is very large (multiple gigabytes) and mirroring using
> svk obviously takes a lot of time and space, so I'm keen to bring that
> down, most likely by the developer not needing to mirror branches he
> doesn't care about, or by being able to throw away branches he's done with.
>  * The repository is full of revisions that fail review (or break
> things) and are fixed by subsequent revisions. We'd much rather be able
> to have the developer fix his revisions before they get committed
> 'upstream' (whatever that ends up meaning).
> 
> I asked earlier about the email-based model that git itself uses, and
> while it appears to work very well for a widely-dispersed open-source
> project, I think it will be too cumbersome and slow for a fast-paced
> internal development team who make a number of live releases every day.
> 

> So, I've been thinking and have come up with this, which I'd appreciate
> comments about:
> 
>  1. On a server we stick a git repository which contains the master
> branch, which represents what trunk did (i.e. the live platform). This
> branch contains the full history for the live platform.

>  6. If all is not well, the developer creates a new local branch and
> moves good revisions from his previous one to the new one, modifying
> things as he goes, and republishes his new branch.
>  7. If all is well, their works gets merged or rebased onto the main
> project branch, and once that's ready it gets pushed to the master and
> rolled to live. The developer's individual branches get deleted from the
> dev repo since they're no longer required.

> On Tue, Sep 25, 2007 at 09:09:00PM +0200, Andreas Ericsson wrote:
>
>> We came to the same conclusion at our workplace. Email works  
>> great, but
>> it's faster and better to just walk over to your colleague and ask  
>> what
>> he/she thinks about something.
>
> One of the projects I am working on does things this way, but I  
> have to
> admit that I miss the email code-review process. There are often small
> fixups (stylistic, minor nits, "I would have done it this way...",  
> etc)
> that are worth pointing out at the time, but are more painful to go  
> back
> and correct much later.
>
> And documenting those discussions can really help other developers
> besides the author and reviewer.

> On Tue, Sep 25, 2007 at 09:50:34PM +0200, Wincent Colaiuta wrote:
>
>> Google has a pretty interesting internal code review system:
>>
>> <http://video.google.com/videoplay?docid=-8502904076440714866>
>
> Interesting pointer, thanks. Though I did get a little concerned  
> when I
> saw that it is based on Perforce. ;)

> Russ Brown wrote:
>> Hi,
>>
>> I've been trying to think of a git workflow that we could use to replace
>> our current svn/svk setup without simply using git in exactly the same
>> way that we use svn/svk.
>>
>> Basically, we develop, maintain and enhance a website. On the central
>> repo is trunk which represents live, and any number of project branches.
>> Developers don't use local branches: they check out the project branches
>> they're working on and commit to those. Developers merge from trunk to
>> project branch from time to time to keep them current, and when a
>> project rolls out the branch is merged to trunk.
>>
>> In addition to the obvious advantages that git would give us (such as
>> properly tracking that code author as opposed to the person who did the
>> merge), I'm wanting to gain the following benefits:
>>
>>  * The repository is very large (multiple gigabytes) and mirroring using
>> svk obviously takes a lot of time and space, so I'm keen to bring that
>> down, most likely by the developer not needing to mirror branches he
>> doesn't care about, or by being able to throw away branches he's done
>> with.
>>  * The repository is full of revisions that fail review (or break
>> things) and are fixed by subsequent revisions. We'd much rather be able
>> to have the developer fix his revisions before they get committed
>> 'upstream' (whatever that ends up meaning).
>>
>> I asked earlier about the email-based model that git itself uses, and
>> while it appears to work very well for a widely-dispersed open-source
>> project, I think it will be too cumbersome and slow for a fast-paced
>> internal development team who make a number of live releases every day.
>>
> 
> We came to the same conclusion at our workplace. Email works great, but
> it's faster and better to just walk over to your colleague and ask what
> he/she thinks about something.
> 

>> So, I've been thinking and have come up with this, which I'd appreciate
>> comments about:
>>
>>  1. On a server we stick a git repository which contains the master
>> branch, which represents what trunk did (i.e. the live platform). This
>> branch contains the full history for the live platform.
> 
> A must-have for any more-than-two-developers setup, so so far so good ;-)
> 
>>  2. On the same server we clone that repo to create a second repository
>> which is the developer area. In this we track master from the live repo,
>> and also create project branches.
> 
> This isn't necessary. Branches in git are very nearly zero-cost, so having
> them in the same repo as the master branch won't hurt a bit. You can add
> an update-hook on the mothership repo to restrict access to the master
> branch if you like, but creating two separate repos will likely give
> more headache than it's worth.
> 

>>  3. Developers clone this developer repo, but I'd like them to be able
>> to decide which branches they actually want to clone from that
>> repository rather than simply cloning them all. Is this possible?
> 
> Yes, although I'd actually recommend you to clone the full repo anyway.
> Since the various branches are likely to share quite a lot of history
> the added overhead of a few extra branches will most likely be negligible.
> git makes even very large codebases appear small and unobtrusive. The
> linux kernel history since 2.6.12 contains 554853 objects and compresses
> down to 178MiB.
> 

> I think KDE is the largest repo imported to git so far. I've forgotten
> the exact numbers, but everyone was very impressed, and quite surprised,
> at the vast difference between SVN and git storage requirements.
> 
> 
>>  4. Developers create a local branch of the project they
>> are working on and commit to that.
>>  5. Once they think they're done, they publish their branch to the
>> development repo and request for comments.
> 
> Using topic-branches is a much better strategy, usually, since that
> allows each feature to be evaluated and improved on on its own, rather
> than having to merge *all* of a particular developers changes just to
> get desirable feature X. Note that cherry-pick provides ways of doing
> that anyways, but in a much less elegant way, and your integrator/
> release engineer will likely tear his hair out on a daily basis without
> topic branches.
> 

>>  6. If all is not well, the developer creates a new local branch and
>> moves good revisions from his previous one to the new one, modifying
>> things as he goes, and republishes his new branch.
>>  7. If all is well, their works gets merged or rebased onto the main
>> project branch, and once that's ready it gets pushed to the master and
>> rolled to live. The developer's individual branches get deleted from the
>> dev repo since they're no longer required.
> 
> Topic branches would work the same, basically, except they can be pushed up
> for review a lot faster.
> 
> If all the pushing gets cumbersome, it also makes it easy to send the
> patches
> out as emails for discussion. It's usually easier to let git handle the
> actual code transmissions, but discussing patches in emails works quite
> well if it's intended for a wider audience.
> 

>>  8. From time to time the master branch gets merged to the project
>> branches. Developer's local branches can be rebased against the project
>> branch as they please.
>>
> 
> criss-cross merging can turn kinda nasty though, as you may have a hard
> time
> finding *the* common point when you run into that rogue merge with conflict
> markers everywhere (it happens for everyone sooner or later).
> 
> I'd suggest you rebase the developer/topic branches onto master with
> regular
> intervals instead.
> 

> > This isn't necessary. Branches in git are very nearly zero-cost, so having
> > them in the same repo as the master branch won't hurt a bit. You can add
> > an update-hook on the mothership repo to restrict access to the master
> > branch if you like, but creating two separate repos will likely give
> > more headache than it's worth.
> > 
> 
> Ah, right. I'm just trying to remember why it was I came up with that
> idea in the first place, but I'm struggling a bit. :)

> Here's a question: is the creation and deletion of a branch also version
> controlled as it is in Subversion? In other words, if I create a branch,
> develop on it and delete it without merging it anywhere, will the
> revisions hang around and get pulled down by future people cloning the
> repository, or do they get thrown away?

> I've seen the term 'topic-branch' used here quite a bit but it's
> unfamiliar to me. It is basically synonymous with what we call a
> 'project branch'? i.e. Management decide that feature X is required so
> we create a branch to develop it on which all developers on the project
> commit to.

> Having been using git-svn for a while I really like the clean history
> result that rebase gives, however my understanding was that you should
> never rebase any published branch as it could screw up clones of that
> branch. In fact, this is what has me the most confused: how to rebase a
> project branch that is on a shared repository against master when
> everyone will have it cloned? Or is this something that I clearly don't
> understand properly?

> On Tue, Sep 25, 2007 at 02:42:11PM -0500, Russ Brown wrote:
> 
>>> This isn't necessary. Branches in git are very nearly zero-cost, so having
>>> them in the same repo as the master branch won't hurt a bit. You can add
>>> an update-hook on the mothership repo to restrict access to the master
>>> branch if you like, but creating two separate repos will likely give
>>> more headache than it's worth.
>>>
>> Ah, right. I'm just trying to remember why it was I came up with that
>> idea in the first place, but I'm struggling a bit. :)
> 
> It's not entirely true that branches are zero-cost. They cost nothing to
> make, but fetching a branch that has commits that you don't want is
> going to cost something. And since git-clone doesn't have good support
> for "fetch only this subset of the branches" you end up getting them
> all.
> 
> That being said, you will be amazed how _little_ that cost is unless
> one of the branches doesn't delta well (e.g., if one branch introduces 100M
> of unrelated images, then getting that branch is going to cost). But
> it's almost certainly worth seeing what your workload is like.
> 

>> Here's a question: is the creation and deletion of a branch also version
>> controlled as it is in Subversion? In other words, if I create a branch,
>> develop on it and delete it without merging it anywhere, will the
>> revisions hang around and get pulled down by future people cloning the
>> repository, or do they get thrown away?
> 
> Branch creation isn't version controlled, but your frame of reference is
> obviously svn branches, not git branches. A git repo is just a
> collection of refs, and each ref is a pointer to some commit (which
> points to a tree and to further commits). Branches are just refs in a
> given namespace (where the namespace refs/heads/ indicates "it's ok to
> make further commits on top of these").
> 

> So if you create a branch in your private repo, it is a totally private
> thing; the central repo has no notion of it. When you push that branch
> to the central repo, you are creating a new ref at the central location
> that points to some commits you made. People who clone it will clone
> that ref and your commits. If you delete the branch locally, again it
> has no effect on the master repo. If you delete the branch from the
> central repo, then nobody will fetch those commits anymore (since
> nothing will be pointing to them).
> 

>> I've seen the term 'topic-branch' used here quite a bit but it's
>> unfamiliar to me. It is basically synonymous with what we call a
>> 'project branch'? i.e. Management decide that feature X is required so
>> we create a branch to develop it on which all developers on the project
>> commit to.
> 
> Yes, that's exactly right. You have a "branch" for working on a "topic".
> 
>> Note that in step 4 above I mean the developer takes a local branch of
>> the topic branch. For example, we start projectX/main, and create branch
>> projectX on the shared repo. Developer 'jeff' works on the project and
>> so creates local branch projectX/jeff and begins work. In step 5 they
> 
> You are actually talking about per-developer, per-topic branches. Which
> is fine, too. It sounds like these projects are big (many participants
> over an extended period), so you may want to do things hierarchically:
> 
>   1. project X starts, so you make a branch projectX and assign Bob to
>      be the integrator (or if you prefer, nobody is the integrator).
>   2. Jeff starts to work on project X, feature Y. He makes a branch
>      projectX/featureY, based on projectX. He may publish this to the
>      shared repo if he wants to communicate his progress.
>   3. When featureY is "ready", he tells Bob to pull it into the main
>      projectX branch (or if no integrator, he does it himself).
> 
> Any developer can see the progress of any "topic" by looking at its
> branch. But only things which have advanced to the main "projectX"
> branch are used as the basis for other topics. If you want, you can
> replace featureY with "jeff" to indicate "this is the work Jeff is doing
> on projectX", but then you will run into issues when Jeff is working on
> two different topics of projectY.
> 

>> Having been using git-svn for a while I really like the clean history
>> result that rebase gives, however my understanding was that you should
>> never rebase any published branch as it could screw up clones of that
>> branch. In fact, this is what has me the most confused: how to rebase a
>> project branch that is on a shared repository against master when
>> everyone will have it cloned? Or is this something that I clearly don't
>> understand properly?
> 
> You generally don't want to rebase that branch. If there are other
> branches based on some work, then it will become more difficult to merge
> those branches into the rebased work. IOW, rebase works well only at the
> "outermost" level of development. So if branch "featureY" is branched from
> "projectX" which is branched from "main", then it is reasonable to
> rebase featureY against projectX. But rebasing projectX against master
> will make integrating "featureY" more difficult. So you should either:
>   - just do regular merges of projectX into main (and hopefully, if
>     projectX is an aggregate of features, it won't have _that_ many
>     merges, so the history should still be quite readable)
>   - wait until all such "featureY" branches are merged into projectX,
>     announce a freeze of branching from projectX, and then rebase it
>     forward.
> 
> -Peff

> I keep reading things similar to this and bit by bit I'm starting to get
> it. :) I suppose this is one case in which it's definitely a
> disadvantage to have a good understanding of svn before coming to git...
>
> <yoda>You must unlearn what you have learned</yoda>

> I suppose what has me the most confused is how a developer works with a
> remote branch: I've come to understand that a developer should never
> check out and work on a remote branch, and always create a local one and
> work on that. If he does that using the above hierarchy, there then
> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
> is possible for a developer to work directory on a remote branch?

> Russ Brown <pickscrape@gmail.com> writes:
> 
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
> 
> You do not have to unlearn; if Jeff truly unlearned he wouldn't
> have spotted you were trapped in SVN mentality.  You just need
> to learn there could be other ways ;-).
> 

>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
> 
> Yes, eventually.
> 
>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
> 
> The statement in the last sentence does not make any sense.
> Remote is called remote because it is remote and supposed to be
> out of reach ;-)
> 

> More seriously, remotes are used as reference points so if you
> "work directly on them", you cannot use them as reference points
> any more; you defeat the sole purpose of existence of remotes.
> 
> You can work _without_ using remote tracking branches, but that
> is mostly for merge based workflow.  It appears that you are
> leaning towards rebase-heavy workflow, so I do not think it is
> applicable to your project.

> I keep reading things similar to this and bit by bit I'm starting to get
> it. :) I suppose this is one case in which it's definitely a
> disadvantage to have a good understanding of svn before coming to git...
> 
> <yoda>You must unlearn what you have learned</yoda>

> I suppose what has me the most confused is how a developer works with a
> remote branch: I've come to understand that a developer should never
> check out and work on a remote branch, and always create a local one and
> work on that. If he does that using the above hierarchy, there then
> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
> is possible for a developer to work directory on a remote branch?

> Ah,I see... The light is beginning to come on somewhat here, though it's
> dimmed somewhat by the remote/local branch confusion I mention above,
> which tends to imply that rebase is only really useful in local branches
> since it is always the outer-most branch (assuming that my understanding
> on that is correct, which it may well not be).

> Personally, I think it pays to learn a little about what's going on
> under the hood, and then all of the commands Just Make Sense.
>
> There are several explanations floating around; this is a pretty
> concise one:
>
>   http://eagain.net/articles/git-for-computer-scientists/

> On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:
> 
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
> 
> I prefer to think of it like a war movie, where I keep having
> nightmarish flashbacks to CVS.
> 
> But yes, from the outside git _looks_ a lot like other SCMs you may have
> used, and so it's tempting to keep their mental models. But that can
> easily end up being confusing, as you have found. Personally, I think it
> pays to learn a little about what's going on under the hood, and then
> all of the commands Just Make Sense.
> 
> There are several explanations floating around; this is a pretty concise
> one:
> 
>   http://eagain.net/articles/git-for-computer-scientists/
> 

>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
> 
> The 'git-prune' command will do this, though it is not run as part of
> git-gc unless you specify --prune.
> 

>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
> 
> As Junio noted, you can't, because they're remote. What you have in your
> local repository is a remote _tracking branch_, which is a local ref
> that tracks your idea of what the remote's branches are. And git will
> feel free to overwrite the contents of that tracking branch whenever you
> do a fetch or pull. So if you make commits on it, they are subject to
> being overwritten (and we note this property of the refs by putting them
> in the refs/remotes hierarchy, rather than refs/heads).
> 
> So in the case of our developer Jeff, his local repository will have a
> "projectX/featureY" branch that he works on. And he will also have a
> remote tracking branch "origin/projectX/featureY" which indicates where
> his local repo thinks the remote repo points. And the remote repo will
> have a "projectX/featureY" branch, of course.
> 

>> Ah,I see... The light is beginning to come on somewhat here, though it's
>> dimmed somewhat by the remote/local branch confusion I mention above,
>> which tends to imply that rebase is only really useful in local branches
>> since it is always the outer-most branch (assuming that my understanding
>> on that is correct, which it may well not be).
> 
> Yes, although the important distinction is not so much "this is a local
> branch" but rather "this is a _published_ branch" which implies that
> other people are looking at (and possibly basing work on) it.
> 
>> I actually quite like the idea of the freezing before re-basing in the
>> sub-branches. However, to answer the question of which merge strategy
>> would work best for us I think I need to actually set this up and have a
>> play with it to see how it all pans out using the various options available.
> 
> Yes, it is easy to get into academic discussions of setups, but in
> practice you need to find a workflow that is smooth for your team.
> 
> On one web-based project I work on, we have a setup like this (which is
> very centralized):
> 
>   - a central repo resides on a development server with two branches,
>     "master" and "production"
>   - each developer clones the repo with a working tree
>   - some developers develop directly on 'master' if they have small
>     changes, or only work on one thing at a time; other developers use
>     topic branches to work on simultaneous changes
>   - any developer can push to master; it is expected that your code is
>     in a reasonable state, since it will now be consumed by other
>     developers. Anything that has made it into master is considered
>     published and should not be rebased. It is up to developers whether
>     they want to rebase their work before publishing or to simply merge.
>   - some developers communicate directly with each other: "hey, check
>     out branch 'foo' in my repo" or "what do you think of this patch?"
>   - The live site has a repo cloned from the central repo, pointing at
>     "production".
>   - there is a test site with a repo cloned from the master.
>     Occasionally the master branch is pulled and tested. If it passes,
>     it is pushed to the "production" branch. In addition, small
>     immediate fixes can go onto "production", tested, and then pushed to
>     the central repo's "production"
> 
> So this is not necessarily using the distributed nature of that much,
> but it allows those developers who aren't very comfortable with SCMs to
> stick to a "pull, hack, push" workflow. And those who want to can do
> more interesting things if it helps them.
> 

> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.

> Thanks for this, it's very useful to read examples of workflows in
> actual use. In fact, I was thinking the other day that it would be good
> to have a site that acts as a directory of many different workflows,
> including descriptions of how they work, how you actually go about
> setting it up and using it day to day (i.e. lists of commands for each
> role/task) and the pros/cons that it provides. I reckon that would help
> newbies out quite a bit (if only for the examples). I've seen a few
> individual examples of workflow but nothing like a comprehensive set of
> them.

> Andreas Ericsson wrote:
>> Russ Brown wrote:
>>> Hi,
>>>
>>> I've been trying to think of a git workflow that we could use to replace
>>> our current svn/svk setup without simply using git in exactly the same
>>> way that we use svn/svk.
>>>
>>> Basically, we develop, maintain and enhance a website. On the central
>>> repo is trunk which represents live, and any number of project branches.
>>> Developers don't use local branches: they check out the project branches
>>> they're working on and commit to those. Developers merge from trunk to
>>> project branch from time to time to keep them current, and when a
>>> project rolls out the branch is merged to trunk.
>>>
>>> In addition to the obvious advantages that git would give us (such as
>>> properly tracking that code author as opposed to the person who did the
>>> merge), I'm wanting to gain the following benefits:
>>>
>>>  * The repository is very large (multiple gigabytes) and mirroring using
>>> svk obviously takes a lot of time and space, so I'm keen to bring that
>>> down, most likely by the developer not needing to mirror branches he
>>> doesn't care about, or by being able to throw away branches he's done
>>> with.
>>>  * The repository is full of revisions that fail review (or break
>>> things) and are fixed by subsequent revisions. We'd much rather be able
>>> to have the developer fix his revisions before they get committed
>>> 'upstream' (whatever that ends up meaning).
>>>
>>> I asked earlier about the email-based model that git itself uses, and
>>> while it appears to work very well for a widely-dispersed open-source
>>> project, I think it will be too cumbersome and slow for a fast-paced
>>> internal development team who make a number of live releases every day.
>>>
>> We came to the same conclusion at our workplace. Email works great, but
>> it's faster and better to just walk over to your colleague and ask what
>> he/she thinks about something.
>>
> 
> Very true, with the minor exception that at my place there are
> developers working at different sites, so the walk-over method will only
> work for specific subsets of the team. :)
> 

> Here's a question: is the creation and deletion of a branch also version
> controlled as it is in Subversion? In other words, if I create a branch,
> develop on it and delete it without merging it anywhere, will the
> revisions hang around and get pulled down by future people cloning the
> repository, or do they get thrown away?
> 

>>
>>>  4. Developers create a local branch of the project they
>>> are working on and commit to that.
>>>  5. Once they think they're done, they publish their branch to the
>>> development repo and request for comments.
>> Using topic-branches is a much better strategy, usually, since that
>> allows each feature to be evaluated and improved on on its own, rather
>> than having to merge *all* of a particular developers changes just to
>> get desirable feature X. Note that cherry-pick provides ways of doing
>> that anyways, but in a much less elegant way, and your integrator/
>> release engineer will likely tear his hair out on a daily basis without
>> topic branches.
>>
> 
> I've seen the term 'topic-branch' used here quite a bit but it's
> unfamiliar to me. It is basically synonymous with what we call a
> 'project branch'? i.e. Management decide that feature X is required so
> we create a branch to develop it on which all developers on the project
> commit to.
> 

> Note that in step 4 above I mean the developer takes a local branch of
> the topic branch. For example, we start projectX/main, and create branch
> projectX on the shared repo. Developer 'jeff' works on the project and
> so creates local branch projectX/jeff and begins work. In step 5 they
> push this local branch to the shared repo so everyone can see it
> (alternative to the 'walk-over' method or emailing). Note that all
> changes jeff making in projectX/jeff are specific to the project branch,
> so he can rebase against other changes that get committed to that
> project branch.
> 
> If colleagues don't like his changes he can create projectXjeff2 and try
> again.
> 
> Jeff can also have other local branches to keep separate changes he is
> making on the other projects he is involved in.
> 
> That's how I'd thought of it happening...
> 

>>>  6. If all is not well, the developer creates a new local branch and
>>> moves good revisions from his previous one to the new one, modifying
>>> things as he goes, and republishes his new branch.
>>>  7. If all is well, their works gets merged or rebased onto the main
>>> project branch, and once that's ready it gets pushed to the master and
>>> rolled to live. The developer's individual branches get deleted from the
>>> dev repo since they're no longer required.
>> Topic branches would work the same, basically, except they can be pushed up
>> for review a lot faster.
>>
>> If all the pushing gets cumbersome, it also makes it easy to send the
>> patches
>> out as emails for discussion. It's usually easier to let git handle the
>> actual code transmissions, but discussing patches in emails works quite
>> well if it's intended for a wider audience.
>>
> 
> Yes, I am going to experiment with this a little too to see just how
> much work it would involve for the developers (if it's too much they
> won't do it) :)
> 

>>>  8. From time to time the master branch gets merged to the project
>>> branches. Developer's local branches can be rebased against the project
>>> branch as they please.
>>>
>> criss-cross merging can turn kinda nasty though, as you may have a hard
>> time
>> finding *the* common point when you run into that rogue merge with conflict
>> markers everywhere (it happens for everyone sooner or later).
>>
>> I'd suggest you rebase the developer/topic branches onto master with
>> regular
>> intervals instead.
>>
> 
> Having been using git-svn for a while I really like the clean history
> result that rebase gives, however my understanding was that you should
> never rebase any published branch as it could screw up clones of that
> branch. In fact, this is what has me the most confused: how to rebase a
> project branch that is on a shared repository against master when
> everyone will have it cloned? Or is this something that I clearly don't
> understand properly?
>