Git Merge s'engage dans une orpheline de la branche

Je suis curieux de savoir si vous POUVEZ et si il n'y a rien de mal avec la fusion s'engage DANS mon orphelin de la branche. Pour ce cas précis de mon Salesforce référentiel a une branche principale et une pré-version de la branche, mais parce que notre environnement sandbox a souvent des métadonnées qui ne fait pas partie de la production pourtant nous voulons de contrôle de version, mais assez séparés de notre propre pré-version de la branche.

Donc, comme il est nous avons les éléments suivants:

(Production Init Commit)    (official release)
 /                        /
o-------------------------o [master]
 \                       /
  o------o---------o----o [pre-release]
          \       /
           o-----O [feature]
                  \ <-- IS THIS ALLOWED/POSSIBLE/BAD IDEA?
                   \ 
       o------------O [DEV] (orphan branch)
      /
     (Initial commit from our sandbox environment)
Concernant votre ASCII graphiques, veuillez lire le haut de la cette réponse de la mine.
Vous pouvez certainement le faire -- et qu'il ne peut pas faire de mal à essayer. Si vous n'aimez pas les résultats, il suffit de le réinitialiser.

OriginalL'auteur Xtremefaith | 2014-12-24

  1. 9

    La fusion s'engage à ce que n'ont pas de racine commune commettre est permis avec Git. Le résultat contiendra l'union des fichiers présents dans les deux branches. C'est une pratique courante pour fusionner les deux projets en un seul référentiel (par exemple, le Git du projet lui-même a commencé à e83c51633, gitk a commencé à 1db95b00, et les deux projets ont fusionné plus tard, à 5569bf9bb).

    Maintenant, si vous voulez vraiment faire cela dépend vraiment sur le contenu de branches. Si vous fusionnez votre bac à sable de la branche dans votre branche, puis la fusion de votre branche, en maître va également apporter votre code de sandbox en maître, et vous ne voulez probablement pas.

    OriginalL'auteur Matthieu Moy

  2. 18

    Avec git 2.9 (juin 2016), la fusion des branches orphelines est toujours possible, mais ony avec le --allow-unrelated-histories option:

    git merge --allow-unrelated-histories a b

    Voir s'engager e379fdf (18 mars 2016) par Junio C Hamano (gitster).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager d04aa7e, 08 Avril 2016)

    de fusion: refuser de créer trop cool une fusion par défaut

    Alors qu'il fait sens pour permettre la fusion sans rapport avec les histoires de deux
    les projets qui ont commencé de manière indépendante, dans la façon dont "gitk" a été
    fusionné "git" aka "le plus cool de fusion jamais"    , une telle fusion est
    encore un événement inhabituel    .

    Pire, si quelqu'un crée une histoire indépendante à partir d'une archive d'un projet et envoie une demande d'extraction à l'origine du projet, "git merge" mais heureusement crée une telle fusion, sans aucun signe de quelque chose d'inhabituel se passe.

    Enseigner "git merge" de refuser de créer une telle fusion par défaut,
    à moins que l'utilisateur passe à une nouvelle "--allow-unrelated-histories" option de
    dire que l'utilisateur est conscient que les deux projets indépendants sont
    fusionné.

    Parce que ces deux "projet de fusion" est un événement rare, une configuration
    option toujours autoriser une telle fusion n'est pas ajouté.

    La git merge doc mentionne:

    Par défaut, git merge commande refuse de fusionner des histoires qui ne partagent un ancêtre commun. Cette option peut être utilisée pour passer outre cette sécurité lors de la fusion des histoires de deux projets qui ont commencé leur vie de façon indépendante.

    Comme c'est une occasion très rare, pas de variable de configuration pour activer cette fonction par défaut existe et ne sera pas ajouté, et la liste des options en haut de cette documentation ne mentionne pas cette option.

    Aussi git pull ne passe pas cette option en bas à git merge (au lieu de cela, vous git fetch tout d'abord, examinez ce que vous serez en fusion, puis git merge localement avec cette option).

    Voir s'engager de22496 (21 Avril 2016) par Junio C Hamano (gitster).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager 175008d, 29 Avril 2016)

    pull: passer --allow-unrelated-histories"git merge"

    Au lieu de:

    git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD

    Si quelqu'un est tenté d'ajouter une telle option, mise à jour des tests dans ce
    changement doivent être rajustés en fonction de l':

    git pull --allow-unrelated-histories something

    OriginalL'auteur VonC