Comment sauvegarder des branches privées dans git
J'ai une branche locale pour le travail de développement quotidien dans git. Mon flux de travail est:
- Faites des choses sur local_branch, commit
- récupère l'origine / le maître
- Rebase local_branch pour rattraper les nouvelles choses de origin / master
Tout fonctionne bien, mais la plupart des recommandations que j'ai rencontrées disent qu'il ne faut pas "pousser" les branches privées, sur lesquelles le rebase est régulièrement effectué.
Le problème ici est que dans ce cas, la branche locale n'est pas sauvegardée sur un serveur et la seule façon d'enregistrer le travail est de le fusionner à la branche" pushable " (c'est-à-dire origin/master)
Quelles seraient vos recommandations sur le flux de travail dans ce cas?
Merci!
UPDATE : j'ai réalisé que l'une des exigences d'origine que j'avais (en évitant l'utilisation d'utilitaires externes) est une limitation inutile.
Ma solution actuelle est de stocker tous mes dépôts dans un dossier synchronisé dans le cloud - de cette façon, je reçois une sauvegarde gratuitement.
7 réponses
J'utilise l'option -- mirror et pousse vers un dépôt de sauvegarde personnel:
Ajoutez - le en tant que télécommande:
git remote add bak server:/path/to/backup/repo
Faites la sauvegarde:
git push --mirror bak
Cela fera automatiquement ressembler votre référentiel de sauvegarde à votre référentiel actif - les branches seront créées, supprimées, mises à jour (même forcées/Non-fastforwards) au besoin. Vous pouvez aussi créer un alias pour cela:
git config alias.bak "push --mirror bak"
Ensuite, il s'agit simplement d'exécuter "git bak" lorsque vous voulez faire une sauvegarde. Vous pouvez également jeter cela dans un cron emploi.
Il n'y a rien de mal à pousser des branches personnelles. Il est généralement découragé parce que les gens peuvent commencer à travailler en fonction de votre branche, et lorsque vous rebase, leurs changements sont laissés flottants.
Ce que je fais c'est d'utiliser un préfixe pour désigner "c'est ma branche, l'utiliser sur vos propres risques", comme: fc-général-nettoyage de.
Une autre option serait de pousser "local_branch" vers le repo "origin", mais vers sa propre branche dans ce repo (pas "master"), c'est-à-dire:
git push origin local_branch:local_backup
Ensuite, lorsque vous êtes prêt à faire une autre sauvegarde (et après avoir travaillé et rebasé), supprimez simplement la branche de sauvegarde du dépôt d'origine avant de la repousser à nouveau:
git push origin :local_backup
git push origin local_branch:local_backup
De cette façon, vous ne rencontrerez pas de problèmes en poussant " local_branch" après avoir été rebasé de "origine / maître".
Et si la suppression de vos branches de sauvegarde vous rend nerveux (jusqu'à ce que vous ayez finalement commis votre travail à "master"), vous pouvez toujours continuer à pousser vers une nouvelle branche avec un nouveau nom (par exemple "local_backup1", "local_backup2", etc).
Il n'y a rien de mal à pousser vers la même branche que vous rebasez. Ces diagrammes devraient illustrer pourquoi cela fonctionne bien:
Disons que c'est à quoi ressemble le graphique de validation après avoir ramifié local_branch et fait quelques commits (C et D). Quelqu'un d'autre a fait un commit (E) à origin / master depuis que vous avez ramifié local_branch:
A -- B -- E [origin/master]
\
\
\-- C -- D [local_branch]
Ensuite, après avoir exécuté "git rebase origin / master", le graphique de validation ressemblera au diagramme suivant. "origin / master" est toujours le même, mais "local_branch" a été rebasé:
A -- B -- E [origin/master]
\
\
\-- C -- D [local_branch]
À ce stade, si vous faites "git push origin local_branch: master", cela se traduira par un simple avance rapide. "origin / master "et" local_branch " seront identiques:
A -- B -- E -- C -- D [origin/master],[local_branch]
Maintenant, vous êtes libre de faire plus de travail sur "local_branch". Finalement, vous pourriez obtenir quelque chose comme ceci:
A -- B -- E -- C -- D -- G -- I [origin/master]
\
\
\-- F -- H [local_branch]
Notez que cela ressemble beaucoup au graphique de départ. Vous pouvez continuer à répéter ce processus et plus.
Vous devriez éviter de pousser vers une brancheautre , une branche dont vous ne rebasez pas. C'est là que vous rencontrerez des problèmes (à l'autre branche, il semblera que votre historique "local_branch" a soudainement été réécrit, après avoir rebasé de "origin/master").
Pouvez-vous configurer un autre référentiel distant vers lequel vous poussez toutes vos branches? L'autre chose à considérer est simplement de sauvegarder tout (important) sur votre machine locale, y compris le repo git.
Voici ce que je fais. Mais ce n'est pas privé. Je fais cela pour que je puisse collaborer avec moi-même (pour ainsi dire). Il me permet de travailler sur la même branche sur deux boîtes ou plus. si d'autres personnes avaient accès au repo partagé, elles pouvaient voir le travail que je fais sur la branche. Bien sûr, sur mes repos à domicile, personne d'autre n'a accès, donc c'est toujours privé. Sur github, tout le monde pouvait voir mes trucs. Comme ils se soucient vraiment. ;)
Plutôt que de compter sur Dropbox pour synchroniser tous les fichiers d'un repo git, je préfère utiliser git bundle, qui ne produit que un fichier (y compris toutes vos branches privées) et synchronise ce fichier avec DropBox.
Voir "Git avec Dropbox"
Dans "Sauvegarde d'un Dépôt Git Local", Yars mentionné avoir des erreurs de synchronisation avec Dropbox.