...

If your feature is not speculative – it will definitely be in ACME – but will take a long time, you should develop directly in master.

...

Development in ACME-Climate/ACME (recommended)

1. Split the long-term development in to pieces that can be checked in to master as they are finished.
2. Add pieces back to master with PRs as is done for mainline regular ACME development.
3. When you enough code to execute some of your feature, add a test or tests for it.  These tests won't be added to the main acme test suites until the feature is "officially added".  If you have more then one, they could be part of a separate test suite.  Your PR must still pass the standard ACME testing.
4. Develop the next piece of your feature with a new branch from the head of master.

...

Long-lived branch off of ACME-Climate/ACME master (or from an integration branch)

1. Start a branch for your development as is done for any ACME development.
2. Make As you develop code on your branch, make a test or tests for your feature
3. Keep your branch up-to-date by the following:
   
   1. PREFERRED: Periodically rebase your branch to the head of master (or head of the integration branch)
   2. OR you can merge master to your long-lived branch IF AND ONLY IF:
      1. A subroutine or function your feature depends on has changed its API OR
      2. A tag has been made on ACME master (so you get a known state).   Do NOT make random "oh its been a while" merges of master to your branch.
      3. DO NOT merge from master just for machine config updates.  Cherry pick those or copy them.
4. Run acme_developer on your branch along with tests for your feature as development proceeds.
5. When finished, make a PR as for normal ACME development.

Features lives on your branch until it is finished.   Maintaining the branch (with rebases or occasional merge from master) could become arbitrarily hard if related codes diverge.  Other developers unaware of feature until its finished. 

...