ne peut pas pousser pour se ramifier après le rebase

Nous utilisons git et avons une twig principale et des agences de développement. Je dois append une nouvelle fonctionnalité, puis rebaser les validations à maîsortingser, puis transférer le maître vers le serveur CI.

Le problème est que si je suis en conflit pendant le rebase, je ne peux pas pousser sur ma twig de développeur distante (sur Github) une fois la réinitialisation terminée, jusqu’à ce que je retire ma twig distante. Cela provoque des commits en double. Lorsqu’il n’y a pas de conflit, fonctionne comme prévu.

question: après la résolution de rebase et de conflit, comment puis-je synchroniser mes twigs de développeur local et distant sans créer de commits en double

Installer:

// master branch is the main branch git checkout master git checkout -b myNewFeature // I will work on this at work and at home git push origin myNewFeature // work work work on myNewFeature // master branch has been updated and will conflict with myNewFeature git pull --rebase origin master // we have conflicts // solve conflict git rebase --continue //repeat until rebase is complete git push origin myNewFeature //ERROR error: failed to push some refs to 'git@github.com:ariklevy/dropLocker.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (eg 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. // do what git says and pull git pull origin myNewFeature git push origin myNewFeature // Now I have duplicate commits on the remote branch myNewFeature 

MODIFIER

Donc, il semble que cela va briser le stream de travail:

developer1 travaillant sur myNewFeature developer2 travaillant sur hisNewFeature utilisent tous deux master comme twig principale

developer2 fusionne myNewFeature dans hisNewFeature

developer1 se réinitialise, résout les conflits, puis force la poussée vers la twig distante pour myNewFeature

quelques jours plus tard, developer2 fusionne myNewFeature dans hisNewFeature

Est-ce que cela incitera les autres développeurs à détester developer1?

    Tout d’abord, vous et les personnes avec qui vous travaillez devez vous mettre d’accord sur le fait de savoir si une twig de sujet / de développement est destinée au développement partagé ou uniquement la vôtre. D’autres développeurs savent de ne pas fusionner sur mes twigs de développement car ils seront rebasés à tout moment. Le stream de travail est généralement le suivant:

     o-----o-----o-----o-----o-----o master \ o-----o-----o devel0 \ o-----o-----o devel1 

    Pour restr à jour avec remote, procédez comme suit:

      git fetch origin git checkout master git merge --ff origin/master 

    Je le fais pour deux raisons. D’abord parce que cela me permet de voir s’il y a des changements à distance sans avoir à changer de twig. Deuxièmement, il s’agit d’un mécanisme de sécurité permettant de ne pas écraser les modifications non dissimulées / validées. De plus, si je ne peux pas effectuer une fusion rapide avec la twig principale, cela signifie que quelqu’un a rebasé le maître distant (pour lequel il doit être sévèrement fouetté) ou je me suis engagé par mégarde à maisortingser et j’ai besoin de nettoyer mon extrémité.

    Ensuite, lorsque les changements à distance ont été apportés et que j’ai été rapidement transféré vers la dernière version, je rebase:

     git checkout devel0 git rebase master git push -f origin devel0 

    D’autres développeurs savent alors qu’ils devront rebaser leurs twigs de développement les plus récentes:

     git fetch  git checkout devel1 git rebase /devel0 

    Ce qui se traduit par une histoire beaucoup plus propre:

     o-----o master \ o-----o-----o devel0 \ o-----o-----o devel1 

    Ne fusionnez pas les commits d’avant en arrière à votre guise. Non seulement crée-t-il des commits en double et rend-il l’histoire impossible à suivre, trouver des régressions à partir d’un changement spécifique devient presque impossible (c’est pourquoi vous utilisez le contrôle de version en premier lieu, non?). Le problème que vous rencontrez est le résultat de cela.

    Il semblerait également que d’autres développeurs s’engagent dans vos twigs de développement. Pouvez-vous confirmer cela?

    Le seul moment pour fusionner est lorsque votre twig de sujet est prête à être acceptée dans le master .

    Sur une note latérale. Si plusieurs développeurs s’engagent dans le même référentiel, vous devriez tous envisager d’avoir des twigs nommées pour distinguer les twigs de développement des développeurs. Par exemple:

     git branch 'my-name/devel-branch' 

    Ainsi, toutes les twigs de sujet des développeurs résident dans leur propre ensemble nested.

    Vous devez forcer la poussée lorsque vous avez déplacé les commits plus bas sur la ligne que git s’attend à ce que vous ajoutiez des commits au bout de la twig. git push -f origin myNewFeature va résoudre votre problème.

    Conseil: Ci-dessus, il y a un usage légitime de la force. Ne jamais réécrire l’histoire sur un référentiel accessible au public ou beaucoup de gens vont vous détester.

    La principale chose à garder à l’esprit ici est ce que font les choses en coulisse.

    Une traction fera essentiellement deux choses: aller chercher et fusionner. Lorsque vous incluez –rebase, il fera un rebase au lieu de la fusion.

    Un rebase est un peu comme ranger toutes vos modifications locales depuis votre twigment, en transférant rapidement votre twig vers le dernier commit sur la cible et en décochant vos modifications par ordre.

    (Cela explique pourquoi vous pouvez obtenir plusieurs invites de résolution de conflit lorsque vous effectuez un rebase par rapport à la résolution de conflit que vous pouvez obtenir avec une fusion. Vous avez la possibilité de résoudre un conflit sur EACH commit qui est rebasé afin de préserver vos commits. )

    Vous ne voulez jamais pousser les modifications rebasées sur les twigs distantes car cela réécrit l’historique. De toute façon, jamais c’est un peu fort car il y a presque toujours des exceptions. Le cas où vous devez gérer une version distante de votre référentiel local pour travailler sur un environnement spécifique, par exemple.

    Cela vous obligera à pousser les modifications rebasées parfois en utilisant soit force:

     git push -f origin newfeature 

    Dans certains cas, votre administrateur a peut-être supprimé la possibilité de forcer. Vous devez donc supprimer et recréer:

     git push origin :newfeature git push origin newfeature 

    Dans les deux cas, vous devez être absolument certain de savoir ce que vous faites si quelqu’un d’autre collabore avec vous sur votre succursale distante. Cela peut signifier que vous travailliez initialement avec des fusions et que vous les rebasiez dans un format de validation plus gérable juste avant de passer à la maîsortingse et à la suppression de votre twig de travail.

    Rappelez-vous que vous pouvez presque toujours vous rabattre sur le GC de git en profitant de:

     git reflog 

    Ceci est un sauveur de vie énorme que vous pouvez revenir à un état plus stable si vous êtes perdu dans toute votre gestion de rebase / conflit.

    Vous devez effectuer une poussée forcée, c.-à-d. git push -f origin myNewFeature

    Oh, et vous feriez mieux de vous assurer que les gens ne basent rien sur votre twig dev – généralement vous n’êtes pas censé publier des twigs où vous réécrivez du tout l’historique (ou plutôt ne pas réécrire l’histoire une fois publiée). Une méthode consisterait à utiliser un nom de twig tel que wip/myNewFeature , puis à mentionner que les twigs wip seront rebasées de temps en temps.

    La réponse générale qui a déjà été donnée – pour utiliser git push -f origin myNewFeature lors de la modification des modifications – est un bon sharepoint départ. J’écris cette réponse pour répondre à la question de savoir si cela va casser votre stream de travail.

    Si nous supposons que vous allez utiliser git pull --rebase ... (ou une variante à ce sujet) suivi par une force-push sur la twig distante, alors ce qui casse le stream de travail dans votre exemple est que developer2 est fusion de myNewFeature dans hisNewFeature . Il est logique de pouvoir rebaser votre propre twig tant que personne ne travaille sur cette twig. Vous avez donc besoin de règles pour délimiter le territoire de la twig.

    Vous pouvez contourner ce myNewFeature en a) établissant une règle que vous ne fusionnez jamais avec master , ou b) en créant une twig de develop collectif sur laquelle vous myNewFeature votre propre twig myNewFeature et établissez une règle que vous ne fusionnez jamais. master sera alors réservé aux jalons ou aux versions (ou à tout autre élément que vous souhaitez définir), et le develop sera l’endroit où vous poussez chaque fonctionnalité lorsqu’elle est prête à être intégrée dans d’autres twigs.

    Je crois que cela pourrait être considéré comme une version simplifiée du workflow Gitflow.