Cómo hacer copys de security de sucursales privadas en git

Tengo una sucursal local para el trabajo diario de desarrollo en git. Mi flujo de trabajo es:

  1. Haz cosas en local_branch, cometer
  2. Obtener origen / maestro
  3. Rebase local_branch para ponerse al día con cosas nuevas de origen / maestro

Todo funciona bien, sin embargo, la mayoría de las recomendaciones que encontré dicen que uno no debe "presionar" las twigs privadas, en las cuales se realiza regularmente la rebase.

El problema aquí es que en este caso la twig local no está respaldada en un server y la única manera de save el trabajo es fusionarlo de nuevo a una twig "empujable" (es decir, origen / máster)

¿Cuáles serían sus recomendaciones sobre el flujo de trabajo en este caso?

¡Gracias!

ACTUALIZACIÓN : me di count de que uno de los requisitos originales que tenía (evitando el uso de utilidades externas) es una limitación innecesaria.

Mi solución actual es almacenar todos mis repositorys en una carpeta sincronizada en la nube, de esta manera obtengo una copy de security de forma gratuita.

Utilizo la opción –mirror y paso a un repository de copy de security personal:

Añádalo como control remoto:

git remote add bak server:/path/to/backup/repo 

Haz la copy de security:

 git push --mirror bak 

Esto hará que tu repository de copy de security se vea automáticamente como tu activo: se crearán, eliminarán y actualizarán las ramificaciones (incluso forzadas / no rápidas) según sea necesario. Puedes hacer un alias para esto también:

 git config alias.bak "push --mirror bak" 

Entonces, solo es cuestión de ejecutar "git bak" cuando quieras hacer una copy de security. También podrías include esto en un trabajo de cron.

Otra opción sería presionar "local_branch" al repository de "origen", pero a su propia sucursal en ese repository (no "maestro"), es decir:

git push origin local_branch:local_backup

Luego, cuando esté listo para hacer otra copy de security (y después de haber estado trabajando y actualizando) simplemente elimine la twig de respaldo del repository de origen antes de volver a sacarlo:

git push origin :local_backup <=== elimina la twig del origen

git push origin local_branch:local_backup

De esta forma, no se encontrará con problemas al presionar "local_branch" después de haber sido networkingiseñado desde "origen / maestro".

Y si eliminar las twigs de respaldo te pone nervioso (hasta que finalmente hayas comprometido tu trabajo a "dominar"), siempre puedes seguir presionando a una nueva twig con un nuevo nombre (por ejemplo, "local_backup1", "local_backup2", etc.) .

No hay nada de malo en presionar sucursales personales. En general, se desaconseja porque las personas pueden comenzar a trabajar en function de su sucursal, y cuando se rebase, sus cambios se dejan flotando.

Lo que hago es usar un prefijo para indicar "esta es mi sucursal, úsala bajo tu propio riesgo", como: fc-general-cleanup .

No hay nada de malo en presionar a la misma twig desde la que está modificando. Estos diagtwigs deben ilustrar por qué esto funciona bien:

Digamos que este es el aspecto del gráfico de compromiso después de haber ramificado local_branch y hecho un par de confirmaciones (C y D). Alguien más ha hecho una commit (E) a origin / master desde que ramificó local_branch:

 A - B - E [origen / maestro]
       \
        \    
         \ - C - D [local_branch]

Luego, después de ejecutar "git rebase origin / master", el gráfico de confirmación se verá como el siguiente diagtwig. "origin / master" sigue siendo el mismo, pero "local_branch" ha sido rebasado:

 A - B - E [origen / maestro]
            \
             \
              \ - C - D [local_branch]

En esta etapa, si haces "git push origin local_branch: master", entonces dará como resultado un simple avance rápido. "origin / master" y "local_branch" serán idénticos:

 A - B - E - C - D [origen / maestro], [twig local]

Ahora eres libre de hacer más trabajo en "local_branch". Eventualmente, puede get algo como esto:

 A - B - E - C - D - G - I [origen / maestro]
                      \
                       \
                        \ - F - H [local_branch]

Tenga en count que esto se parece mucho al gráfico de inicio. Puedes seguir repitiendo este process una y otra vez.

Debes evitar presionar a otra twig, una de la que no estés networkingefiniendo. Ahí es donde se encontrará con problemas (para la otra twig, parecerá que la historia de su "bifurcación local" ha sido reescrita de repente, después de que haya cambiado su location desde "origen / maestro").

¿Puedes configurar otro repository remoto al que presionas todas tus twigs? La otra cosa a tener en count es simplemente realizar una copy de security de todo (importante) en su máquina local, incluido el repository git.

Esto es lo que hago . Pero – esto no es privado. Hago esto para poder queueborar conmigo mismo (por así decirlo). Me permite trabajar en la misma twig en dos o más cajas. si otras personas tuvieran acceso al repository compartido, podrían ver el trabajo que estoy haciendo en la sucursal. Por supuesto, en mis repositorys domésticos, nadie más tiene acceso, por lo que sigue siendo privado. En github, todo el mundo podría ver mis cosas. Como si realmente les importara 😉

En lugar de confiar en Dropbox para sincronizar todos los files de un git repo, preferiría usar git bundle , que produce solo un file (incluidas todas sus sucursales privadas) y sincronizar ese file con DropBox.
Ver " Git con Dropbox "

En " Copia de security de un repository local de Git ", Yars mencionó tener errores de synchronization con Dropbox.