Workflow for long-running fork

gistfile1.md

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://rfay@git-testing.drupal.org:2222/sandbox/rfay/1056659.git.
2. Clone the views repository into a directory named my_views_feature: git clone --branch 7.x-3.x git://git-testing.drupal.org/project/views my_views_feature cd my_views_feature
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). git checkout -b cool_new_public_branch
4. Delete the 7.x-3.x branch, as we could just get confused by it. git branch -d 7.x-3.x # Don't want this around to confuse us
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. git remote rename origin views_official
6. Now set the "origin" remote to our sandbox and push our code to it: git remote add origin ssh://rfay@git-testing.drupal.org:2222/sandbox/rfay/1056659.git git push origin cool_new_public_branch
7. If we're using git 7.0+, we can turn our branch into a tracking branch git branch --set-upstream cool_new_public_branch origin/cool_new_public_branch
8. Now people can clone this: # Committers: git clone --branch cool_new_public_branch ssh://somebody@git-testing.drupal.org: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
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). # 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
11. When the time comes to create a patch XXX

1. If we have a list of things and
   nohup run this
   this should be a code block

This is some text going on and on and on.

  But this is a codeblock
  A real codeblock

1. This is a test
   this is a codeblock
   this is a codeblock too

1. This is a tesst

   this is a codeblock
   yup, a codeblock

This is a test
this is a codeblock
yup a codblcoke

1. This is a test
2. And this is a test too
   this is a code block
   more code blocak

1. This is a test

        More codeblock
        More codeblock
   

1. This is a test
   Indented
   Code
   Block