git merging workflows

Question

I found the following stuff from progit. I do not understand the portion in bold style. Could anyone kindly explain.

The Git project has four long-running branches: master, next, and pu (proposed updates) for new work, and maint for maintenance backports. When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what I’ve described (see Figure 5-24). At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. If they’re safe, they’re merged into next, and that branch is pushed up so everyone can try the topics integrated together.

Figure 5-24. Managing a complex series of parallel contributed topic branches.

If the topics still need work, they’re merged into pu instead. When it’s determined that they’re totally stable, the topics are re-merged into master and are then rebuilt from the topics that were in next but didn’t yet graduate to master. This means master almost always moves forward, next is rebased occasionally, and pu is rebased even more often (see Figure 5-25).

Figure 5-25. Merging contributed topic branches into long-term integration branches.

When a topic branch has finally been merged into master, it’s removed from the repository. The Git project also has a maint branch that is forked off from the last release to provide backported patches in case a maintenance release is required. Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions.

Answer 1

You might find it more helpful to read git's internal documentation about the workflow.

The big summary is that pu is always built out of the topics which aren't in next, and it's built starting from next. The relevant section from the file I linked to:

 $ git checkout pu
 $ git reset --hard next
 $ git merge ai/topic     ;# repeat for all remaining topics
 $ make test

Clearly with that hard reset, pu is going to end up rebased a lot.

And in reality, next is very very rarely rebased:

The tips of 'master', 'maint' and 'next' branches will always fast-forward, to allow people to build their own customization on top of them.

next does tend to have a zillion merge commits in it, as topics are continually being merged into it, while they're merged more cleanly into master. I don't remember the last time I saw it do anything but fast-forward, but I think it tends to be a way to clean up all those extra merge commits from time to time.

That paragraph you quoted really just isn't well-written. When topics are fairly stable, they move from pu to next, and pu is rebuilt starting from the new next, with all topics that haven't graduated to next or master (which means rebasing, done by reset and re-merge as described above). When they're totally stable, they're merged into master. So yes, master always moves forward, next essentially always moves forward, and pu gets rebased all the time.