¿Flujo de trabajo de Git para múltiples proyectos basados ​​en mi propio proyecto inicial?

Estoy creando un proyecto inicial (para mí) que utilizaré como base para muchos otros proyectos. Después de search las mejores prácticas para hacer esto, he encontrado algunas estrategias útiles. Pero no estoy seguro de qué estrategia usar y no siento que tenga una solución completa; un flujo de trabajo que explica todos los pasos necesarios para satisfacer mis necesidades.

Hasta ahora he encontrado 2 estrategias principales.

  1. Usa múltiples controles remotos:

git clone -o seed ssh://git@github.com/user/seed.git new_project_name
La semilla -o cambia el nombre del origen a seed que todavía se puede usar para extraer los cambios.

Cree su nuevo repository de GitHub new_project_name vacío. Entonces
git remote add origin ssh://git@github.com/user/new_project_name.git

( ¿Cuál es el flujo de trabajo de git adecuado para basar un proyecto en un repository 'semilla'? )

  1. Usa múltiples twigs:

git clone https://github.com/username/seed.git / n

git branch myproject

git checkout myproject

Todos sus cambios serán independientes del proyecto inicial. Si desea mantenerse al día y ver dónde está todo lo que necesita hacer es:

git checkout master

git pull

Ahora todos sus files se habrán ido y verá qué aspecto tienen las últimas novedades en 'seed'. Si desea que su proyecto obtenga sus cambios, debe hacer esto:

git checkout myproject

git merge master

( Cómo organizar repositorys GIT cuando se construye sobre un proyecto inicial )

Si utilizo la estrategia de 'múltiples remotos', supongo que no podré realizar ningún cambio que realice en el código que se origina en el proyecto de initialization, ya que el proyecto de initialization obtendrá todo el código relacionado con el proyecto del que estoy trabajando ( ?).

Si utilizo la estrategia de "múltiples sucursales", supongo que tendré que enviar todos los proyectos a mi repository de semillas como twigs diferentes (?). Si deseo cambiar cualquier código que se origine en el proyecto inicial, siempre puedo verificar y cambiar el maestro y luego combinar los cambios en las twigs.

Siento que se supone que debo usar algún tipo de combinación entre estas dos estrategias (o algo completamente diferente). Porque de inmediato me encontré con el problema de que quería cambiar el file readme.md, package.json, gulpfile, etc. en cada proyecto (que se basa en el proyecto inicial). Si luego git pull cualquier mejora realizada en el proyecto inicial, supongo que se sobrescribirán los cambios en estos files, o al less existe un gran riesgo de tener que lidiar con problemas constantes de fusión. ¿Qué estrategia debo usar para hacer que estos problemas potencialmente desorderados sean lo más simples posible?

(También estaba buscando bifurcaciones, pero no parece relevante a less que todos los repositorys sean solo versiones alternativas del mismo software (?) Y desea que una persona se encargue de fusionarse con la versión principal (?)).