This is for a long-running feature with multiple collaborators... and a moving project behind it.

Shared branch workflow for sandboxes

Sandboxes can be used for many things, and one of the things they will be used for is for teams collaborating on larger projects, or adding large features to existing modules, etc.

In that situation we have a couple of new complexities:

* We (possibly) have multiple collaborators who can commit.
* If this is a feature of an existing project we will occasionally have to sync it up with that project so we don't have a massive soul-crushing merge when the time comes to do so.

This is one possible workflow for this situation:

1. Create a new sandbox on drupal.org. Mine will be named my_views_feature, and it will be a new feature for the views project. The commmitter URL will be ssh://[email protected]:2222/sandbox/rfay/1056659.git.
2. Clone the views repository into a directory named my_views_feature:
   <code>git clone --branch 7.x-3.x git://git-testing.drupal.org/project/views my_views_feature
   cd my_views_feature
   </code>
3. Create a branch that we'll use as a public branch (one that will be pushed to the Drupal.org repository and can be cloned and contributed to by others).
   <code>git checkout -b cool_new_public_branch</code>
4. Delete the 7.x-3.x branch, as we could just get confused by it.
   <code>git branch -d 7.x-3.x # Don't want this around to confuse us</code>
5. We're not going to be working off of the official views repository, but 
   we still need it for syncing up, so we'll rename it. 
   <code>git remote rename origin views_official</code>
6. Now set the "origin" remote to our sandbox and push our code to it:
   <code>git remote add origin ssh://[email protected]:2222/sandbox/rfay/1056659.git
   git push origin cool_new_public_branch
   </code>
7. If we're using git 7.0+, we can turn our branch into a tracking branch
   <code>git branch --set-upstream cool_new_public_branch origin/cool_new_public_branch</code>
8. Now people can clone this:
   <code># Committers:
   git clone --branch cool_new_public_branch ssh://[email protected]:2222/sandbox/rfay/1056659.git
   # Non-committers using patch workflow:
   git clone --branch cool_new_public_branch http://git-testing.drupal.org/sandbox/rfay/1056659.git
   </code>
9. Now work goes on. The team can use a rebase workflow or a patch workflow or an integration manager workflow. But somehow the branch named cool_new_public_branch has new commits on it.
10. Avoid merging in the ongoing work in the Views 7.x-3.x branch unless you know there's a significant collision or a feature you need or something like that. But when you need work that's going on there, merge it in with this code. Note that we cannot rebase here because this is a publicly exposed branch and we'd be rewriting the history (and not just doing fast-forward commits).
    <code># Make sure we have the latest
    git pull
    # Fetch the current views work from the views repo
    git fetch views_official
    # Merge the views work into ours
    git merge views_official/7.x-3.x
    # Push the changes up to cool_new_public_branch
    git push origin cool_new_public_branch
    </code>
11. When the time comes to create a patch
    XXX