Est-ce mal de git pousser des branches de force?
Quand je travaille sur une branche de fonctionnalité, j'ai tendance à vouloir nettoyer les commits dans la branche en utilisant une rebase interactive avant que mon travail soit revu et intégré dans la branche principale.
Pendant le développement de la fonctionnalité, je souhaite transférer mon travail intermédiaire vers le référentiel distant comme mesure de sauvegarde. C'est à dire. lorsque mon disque dur tombe en panne, je ne veux pas que toute ma branche de fonctionnalités soit perdue.
Cependant, cela conduit au fait que je dois souvent faire un git Push --force au référentiel distant après un rebase, une action qui est généralement mal vue. Ou comme le dit la page github liée:
Étant donné que la modification de votre historique de validation peut rendre les choses difficiles pour tous les autres utilisateurs du référentiel, il est considéré comme une mauvaise pratique de rebaser les validations lorsque vous avez déjà poussé vers un référentiel.
Existe-t-il une politique (généralement acceptée) qui résout ce conflit?
Pourquoi ce n'est pas un doublon de Le git "Golden Rule of Rebasing" est-il si essentiel?
Ma question ici demande une politique pour résoudre le conflit entre vouloir sauvegarder votre travail dans le référentiel distant et rebaser votre travail , tandis que l'autre question essaie de nier qu'il y a un conflit et demande pourquoi certaines personnes pensent que le conflit existe, et demande donc pourquoi "il est essentiel" de ne pas pousser les rebases de force ?
La question clé à vous poser:
- Conservez-vous votre branche distante après avoir fusionné à nouveau dans master?
Si vous supprimez votre branche de fonctionnalité distante après avoir fusionné dans master, vous perdez déjà l'historique. En supposant que vous écrasiez/rebasiez la branche avant de faire votre fusion/RP, vous perdiez cet historique. Tout ce que votre force fait dans ce cas vous permet d'utiliser github comme sauvegarde.
La situation où vous souhaitez conserver l'historique et ne pas forcer Push est si votre branche distante est persistante après avoir été fusionnée et non seulement exister pendant une période temporaire.
Je suppose que vous demandez si je garderais la branche non révisée? Non, l'AFAIC. Pourtant, le forçage de Push pourrait théoriquement entraîner la perte de commits d'autres utilisateurs qui ont poussé vers la même branche
Il semble que vous ayez plusieurs personnes poussant simultanément vers cette branche. Cela signifie que vous faites vous souciez de l'historique de la branche.
Ce que vous pourriez faire à la place pour votre travail intermédiaire est de créer un fork de cette branche. Vous pouvez pousser à cela, puis rebaser toutes vos validations en une seule validation avant la fusion, donc lorsque vous les fusionnez dans votre branche de fonctionnalité, vous n'avez qu'une seule validation (avec l'historique rebasé de votre branche entière).
J'énumère ici quelques possibilités qui me viennent à l'esprit.
Toujours rebaser sur une nouvelle branche
Lorsque vous avez une branche en désordre some-feature, le rebaser sur une nouvelle branche. Par exemple.
$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..
Ensuite, ayez some-feature-rebase revu et intégré.
Problème: Un gros inconvénient est que, à proprement parler, vous avez besoin d'une nouvelle branche pour chaque rebase. (Vous pouvez avoir plusieurs rebases si vous apportez des modifications après une révision de code, par exemple)
Utilisation git Push --force-with-lease
Je viens d'apprendre sur le git Push --force-with-lease alternative à git Push --force , qui
refuse de mettre à jour une succursale à moins que ce soit l'état que nous attendons; c'est-à-dire que personne n'a mis à jour la branche en amont.
Problème : Cela semble améliorer directement la situation où nous utilisons juste --force, mais il y a encore quelques mises en garde, notamment lorsque je fais un git fetch au lieu d'un git pull, qui met à jour nos succursales en amont locales, tromper --force-with-lease en pensant qu'aucune modification non fusionnée n'a été effectuée sur la branche distante.