Comment importer dépôt Git dans un autre?

J'ai un dépôt Git dans un dossier appelé XXX, et je de deuxième dépôt Git appelé YYY.

Je veux importer le XXX le dépôt dans le YYY référentiel comme un sous-répertoire nommé ZZZ et ajoutez tous les XXX's l'historique des modifications pour YYY.

Structure de dossier avant:

XXX
 |- .git
 |- (project files)
YYY
 |- .git
 |- (project files)

Structure de dossier après:

YYY
 |- .git  <-- This now contains the change history from XXX
 |-  ZZZ  <-- This was originally XXX
      |- (project files)
 |-  (project files)

Est-ce possible, ou dois-je recourir à l'aide de sous-modules?

InformationsquelleAutor Vijay Patel | 2009-11-05
  1. 388

    Probablement la façon la plus simple serait de tirer la XXX des choses dans une succursale dans YYY puis de les fusionner en master:

    Dans YYY:

    git remote add other /path/to/XXX
git fetch other
git checkout -b ZZZ other/master
mkdir ZZZ
git mv stuff ZZZ/stuff                      # repeat as necessary for each file/dir
git commit -m "Moved stuff to ZZZ"
git checkout master                
git merge ZZZ --allow-unrelated-histories   # should add ZZZ/to master
git commit
git remote rm other
git branch -d ZZZ                           # to get rid of the extra branch before pushing
git push                                    # if you have a remote, that is

    En fait je viens d'essayer avec un couple de mon repos, et cela fonctionne. Contrairement à Jörg réponse il ne sera pas vous permettre de continuer à utiliser les autres pensions, mais je ne pense pas que vous avez spécifié que, de toute façon.

    Remarque: Depuis que ceci a été écrit à l'origine en 2009, git a ajouté le sous-arbre de fusion mentionné dans la réponse ci-dessous. Je serais probablement utiliser cette méthode, aujourd'hui, même si bien sûr, cette méthode ne fonctionnent toujours.

    • Merci. J'ai utilisé une version légèrement modifiée de votre technique: j'ai créé une "mise en scène" de la branche sur XXX où j'ai créé le ZZZ dossier, et déplacé les "choses" en elle. Puis j'ai fusionné XXX à YYY.
    • Cela a très bien fonctionné pour moi. Les seuls changements que j'ai faits étaient les suivants: 1) "git branch-d ZZZ" avant de le pousser parce que je ne voulais pas que cela temp direction de la traîner. 2) "git push" a été de me donner le message d'erreur: "Pas de refs en commun et aucune n'est spécifiée; ne rien faire. Peut-être vous devez spécifier une branche comme "maître"." (À l'origine j'ai été pousser à a été un vide dépôt nu.) Mais "git push --tous" a travaillé comme un champion.
    • Je ne vois aucune raison pourquoi vous ne pouvez pas continuer à utiliser l'autre référentiel. Il semble être possible de fusionner les changements de l'autre référentiel à condition que vous utilisez git merge -s subtree.
    • Je voulais terminer avec seulement le ZZZ dossier plus l'histoire dans le YYY repo: j'ai voulu supprimer l'original XXX repo, et le ZZZ branche dans la YYY repo. J'ai trouvé la suppression de l'ZZZ de la branche de @CrazyPyro suggéré retiré l'histoire — pour le garder j'ai fusionné les ZZZ branche en maître avant de le supprimer.
    • Est-ce juste moi, ou est-ce la solution de préserver l'histoire? Je l'ai essayé avec un fichier et après le départ de maître, le fichier n'apparaît que comme ajouté. Après la validation, je n'ai qu'une dans l'histoire. Le résultat est le même que si j'avais ajouté le fichier au moyen de copier coller et ajout manuel.
    • Je l'ai fait plusieurs fois, et il n'est de préserver l'histoire — c'est le point de l'utilisation de télécommandes, etc.
    • peut-être qu'il ne fonctionne plus ou il manque quelque chose? Je suis à l'aide de git version 1.7.10.4... après git mv, git status dit "renommé: trucs -> ZZZ/stuff" mais ensuite, après le départ de maître: "nouveau fichier: ZZZ/stuff" après la validation, la commande git log ne donne que ce ce commit git le blâme ne pas montrer quoi que ce soit, mais le dernier commit soit.
    • J'ai juste foiré autour avec cette avec deux de mes repos, et se rendit compte qu'il manque une étape, que personne n'a semblé remarquer, malgré mon faire upvotes sur cela pendant des années. 🙂 J' mentionnés fusion en maître, mais n'a pas vraiment le montrer. L'édition de maintenant...
    • Est-il un moyen de le faire sans impliquer un git mv commande? Par exemple, si l'historique est conservé dans le "git log de la commande" sans l'aide de l' --suivez argument.
    • Je ne le crois pas — vous sont en train de changer l'emplacement des fichiers, donc il n'y a pas moyen de contourner cela. Vous pouvez utiliser ColinM du sous-arbre de fusion de la solution ci-dessous, mais je ne suis pas sûr de ce que l'histoire ressemble dans le journal que je n'ai jamais fait.
    • Merci pour cette. Nous avons juste été vécu cela, mais nous avons voulu apporter deux branches avec nous, ZZZ notre suivi de branche et d'AAA, une branche de ZZZ. Il nous a fallu un certain temps. Voici mes résumés notes: 1) avant de retirer la télécommande, tandis que dans ./YYY répertoire git checkout -b AAA origin/AAA, 2) interrupteur à YYY et git fetch, 3) d'apporter autre branche avec git checkout -b AAA other/AAA, 4) fusion de la porté des branches git merge. (Regardez le film Inception, pour préparer votre esprit pour la nécessaire Gitfoo)
    • vous pouvez ajouter quelque chose comme cela, lorsque vous déplacez des fichiers dans votre sous-dossier: git mv $(ls|grep -v <your foldername>) <your foldername>/ Cela va copier tous les fichiers et dossiers dans votre nouveau dossier
    • Il fonctionne comme prévu, mais chaque fois que je déplacer des fichiers dans l'autre référentiel, la fusion échoue avec both deleted ../../*, added by us, by them. -Xtheirs n'a pas vraiment changer quoi que ce soit, quelqu'un sait comment rendre le contenu de ZZZ dossier à suivre les fichiers d'origine à l'emplacement et renommer/déplacer des fichiers en conséquence?
    • Est-il possible de lier à la sous-arborescence de fusion réponse? ("En-dessous" les changements au fil du temps)

    InformationsquelleAutor ebneter
  2. 350

    Si vous souhaitez conserver l'exacte commettre l'histoire de la seconde référentiel et donc aussi la capacité de fusionner facilement en amont des changements dans l'avenir, alors voici la méthode que vous souhaitez. Il en résulte non modifiée de l'histoire de la sous-arborescence d'être importés dans votre repo plus une fusion s'engager à déplacer la fusion de dépôt de la sous-répertoire.

    git remote add XXX_remote <path-or-url-to-XXX-repo>
git fetch XXX_remote
git merge -s ours --no-commit --allow-unrelated-histories XXX_remote/master
git read-tree --prefix=ZZZ/-u XXX_remote/master
git commit -m "Imported XXX as a subtree."

    Vous pouvez suivre les changements en amont de la sorte:

    git pull -s subtree XXX_remote master

    Git chiffres sur son propre, où les racines sont avant de faire la fusion, de sorte que vous n'avez pas besoin de spécifier le préfixe sur les fusions.

    Git versions avant de 2,9: Vous n'avez pas besoin de passer le --allow-unrelated-histories option pour git merge.

    La méthode dans l'autre réponse qui utilise read-tree et ignore le merge -s ours étape est effectivement pas différent que de copier les fichiers du cp et d'engager le résultat.

    Source d'origine était de github est "sous-arbre de Fusion" article d'aide.

    • cela ne semble pas avoir conservé de l'histoire... si je fais un git log sur l'un des fichiers que j'ai tiré dans je viens de voir la seule fusion s'engager et rien de sa vie antérieure dans l'autre repo? Git 1.8.0
    • hmm, d'autre part, je ne vois commits de la importées repo si je viens de git log au niveau de la racine, de sorte que son une limitation de la façon dont j'ai essayé d'afficher l'historique des fichiers importés existe - il un moyen?
    • aha! si j'utilise l'ancien chemin d'accès du fichier importé, c'est à dire omettre le subdir il a été importé dans, puis la commande git log va me donner de la validation de l'histoire, par exemple, git log -- myfile au lieu de git log -- rack/myfile
    • À l'aide de la commande git pull comme vous l'avez dit, a importé le connecte à mon maître. Que puis-je faire?
    • n'est-ce pas souhaitable? Amener l'histoire en est un la fonction de cette méthode.
    • Il est devenu difficile de parcourir l'histoire et je ne suis pas intéressé par mon projet dépendances de l'histoire.
    • si vous ne voulez pas de l'histoire, pourquoi ne pas tout simplement faire une copie régulière? Je suis en train d'essayer de comprendre ce qui vous attire à cette méthode si ce n'est pour l'histoire, c'est la seule raison pour laquelle j'ai utilisé cette méthode!
    • Je cherchais un moyen propre pour avoir des dépendances. Il existe peut-être une meilleure solution pour mon type de problème (je ne suis pas git d'experts).
    • Avez-vous essayé le "--suivre" l'option de la "git log"?
    • Un lien alternatif, en référence à la Github lien: kernel.org/pub/software/scm/git/docs/howto/... Il contient de plus d'explications et de raisonnement, et est un peu plus facile à suivre que de Github exemple.
    • Vous pouvez trouver cette information dans ici help.github.com/articles/working-with-subtree-merge
    • Excellente solution, il fonctionne très bien. Je voudrais juste rajouter un commentaire si vous souhaitez fusionner les deux référentiels, mais la seconde sera de fusion dans le premier (pas de nouveau dépôt parent) remplacer le lire-ligne d'arbre avec: git lecture de l'arbre -mu rack_remote/master - cela signifie que le deuxième référentiel sera de fusion de la première.
    • Si cette solution est utilisée, est-il sécuritaire de supprimer le rack dépôt après la fusion est terminée?
    • Je suppose que vous voulez dire la "distance", puisqu'il y est un seul des pensions de cause. C'est sûr, bien que vous ne serez probablement pas en économisant beaucoup d'espace en faisant ainsi, depuis les commits qui ont été fusionnées restera dans votre pension. C'est, de toutes de votre propre s'engage et la fusion s'engage vivre dans le même repo après cette opération.
    • Donc je veux savoir si j'ai fusionner les pensions de A dans des pensions de B avec cette méthode, est-il alors sûr de supprimer complètement repo A?
    • Si vous omettez de manière explicite de la fusion, ce qui devrait remplacer les submodules pour toujours.
    • Depuis Git 2.9, vous avez besoin de l'option --allow-unrelated-histories lors de la fusion.
    • Cela fonctionne très bien, merci. Toute chance de ne pas importer les balises de l'autre référentiel?
    • Quant à l'histoire, ce lien semble être fournir une certaine façon de réécrire l'histoire, de sorte que les chemins de pointer vers le nouveau sous-répertoire. N'avez pas encore essayé, donc je ne suis pas sûr si cela fonctionne: gofore.com/...
    • J'adore ce; le seul changement que je vous suggère est de drapeau arbitraire des valeurs d'option comme, eh bien, arbitraire. J'ai supposé que "rack" est un mot-clé et ainsi de suite.
    • Cela doit-il garder l'onglet historique dans bitbucket à jour? Ou est la préoccupation la plus importante en préservant la commande git log de l'histoire? Je vois la commande git log indiquant toutes les dernières validations et bitbucket montre aussi l'histoire par la "faute" bouton mais quand je le fait aller dans l'onglet historique dans le repo sur bitbucket lui-même, je ne vois que ma récente fusion..je suis en train de penser l'onglet historique est lié à ce fichier??
    • Puis-je ajouter des patchs sur le dessus de XXX/ZZZ? Ce qui se passe à la commande git pull si j'avais des patchs dans ce sous-dossier?
    • Vous pouvez modifier votre importés sous-arbre de fusion des mises à jour à partir de l'amont. Lorsque vous fusionnez les changements en amont les conflits seront résolus comme n'importe quel autre fusion.
    • C'est tout droit jusqu'à la magie noire. Solution fantastique.

    InformationsquelleAutor ColinM
  3. 69

    git-sous-arborescence est un script conçu précisément pour ce cas d'utilisation de la fusion de plusieurs référentiels dans l'un, tout en préservant l'histoire (et/ou le fractionnement de l'histoire de sous-arbres, mais qui semble indifférent à cette question). Il est distribué en tant que partie de l'arbre git depuis la version 1.7.11.

    Pour fusionner un référentiel <repo> à la révision <rev> en tant que sous-répertoire <prefix>, utilisez git subtree add comme suit:

    git subtree add -P <prefix> <repo> <rev>

    git-sous-arborescence met en œuvre la sous-arbre de fusion de la stratégie dans une manière plus conviviale.

    Pour votre cas, à l'intérieur du référentiel YYY, vous devez exécuter:

    git subtree add -P ZZZ /path/to/XXX.git master
    • Si vous avez un répertoire de fusionner au lieu d'un dépôt nu ou à distance, git subtree add -P name-of-desired-prefix ~/location/of/git/repo-without-.git branch-name
    • Noob expérience: git (version 2.9.0.de windows.1) répond "fatal: ambigu argument "CHEF": inconnu révision ou le chemin d'accès pas dans l'arbre de travail" quand j'ai essayé ceci dans un fraîchement initialisé, local, non-dépôt nu, Mais il a bien fonctionné après je vraiment, a obtenu le nouveau référentiel va, c'est à dire après l'ajout d'un fichier brut et la validation de la façon habituelle.
    • Bien que cela fonctionne, il n'y a pas d'histoire maintenu.
    • histoire est maintenu, c'est l'ensemble de point.
    • Merci! Cela fonctionne comme un charme! Un liner! 😀
    • A fonctionné à merveille pour mon scénario.

    InformationsquelleAutor kynan
  4. 47

    Il est bien connu instance de cette dans le dépôt Git de lui-même, qui est collectivement connu dans le Git de la communauté comme "le plus cool de fusion jamais" (après la ligne d'objet de Linus Torvalds utilisé dans l'e-mail à l'Git liste de diffusion qui décrit cette fusion). Dans ce cas, le gitk Git GUI qui fait maintenant partie de Git bon, en fait utilisé pour être un projet distinct. Linus a réussi à fusionner le dépôt dans le dépôt Git de manière

    • il apparaît dans le dépôt Git comme si elle avait toujours été élaboré dans le cadre de Git,
    • tout l'historique est conservé intact et
    • il peut encore être développé indépendamment de son ancien référentiel, avec des changements de simplement git pulled.

    L'e-mail contient les étapes nécessaires pour reproduire, mais ce n'est pas pour les faibles de cœur: tout d'abord, Linus a écrit Git, donc il est probable qu'il en sait un peu plus sur le sujet que vous ou moi, et la deuxième, c'était presque 5 ans et Git a amélioré considérablement depuis, alors peut-être qu'il est maintenant beaucoup plus facile.

    En particulier, je suppose que de nos jours on utilise une gitk sous-module, dans ce cas précis.

    • BTW. la stratégie utilisée pour les fusions (si il y en a) est appelé sous-arborescence fusionner, et il y a une troisième partie git-subtree outil qui peut vous aider avec ceci: github.com/apenwarr/git-subtree
    • Merci, j'ai oublié à ce sujet. Le subtree de fusion de la stratégie, en particulier en conjonction avec la git-subtree outil est un gentil, peut-être même la meilleure alternative à submodules.
    • Jakub du lien est obsolète... voici un bel article de blog sur subtree: blogs.atlassian.com/2013/05/...
    • Pour ceux qui sont curieux, voici une mise à jour du lien! gelato.unsw.edu.au/archives/git/0506/5511.html
    InformationsquelleAutor Jörg W Mittag
  5. 12

    La façon simple de le faire est d'utiliser git format-patch.

    Supposons que nous disposons de 2 dépôts git foo et bar.

    foo contient:

    • foo.txt
    • .git

    bar contient:

    • bar.txt
    • .git

    et nous voulons finir avec foo contenant le bar histoire et ces fichiers:

    • foo.txt
    • .git
    • foobar/bar.txt

    Donc pour cela:

     1. create a temporary directory eg PATH_YOU_WANT/patch-bar
 2. go in bar directory
 3. git format-patch --root HEAD --no-stat -o PATH_YOU_WANT/patch-bar --src-prefix=a/foobar/--dst-prefix=b/foobar/
 4. go in foo directory
 5. git am PATH_YOU_WANT/patch-bar/*

    Et si nous voulons réécrire tous les messages de commits depuis la barre de nous peut le faire, par exemple sur Linux:

    git filter-branch --msg-filter 'sed "1s/^/\[bar\] /"' COMMIT_SHA1_OF_THE_PARENT_OF_THE_FIRST_BAR_COMMIT..HEAD

    Cela va ajouter "[bar] " au début de chaque message de commit.

    • Si le dépôt original contenait les branches et les fusionne, git am échouera probablement.
    • Mineur gotcha: git am bandes de quoi que ce soit dans [ ] à partir du message de commit. Donc, vous devriez utiliser un autre marqueur de [bar]
    • Ne fonctionne pas pour moi. A eu "erreur: foobar/mySubDir/test_host1: n'existe pas dans l'index. La copie de la pièce qui a échoué est trouvé dans: /home/monuser/src/proj/.git/git rebase-appliquer/patch Lorsque vous avez résolu ce problème, exécutez "git am --continuer". C'était après l'application de 11 parcelles (sur 60).
    • Ce blog a une semblable réponse à une autre question (déplacement uniquement les fichiers sélectionnés).
    • J'en vois un inconvénient, tous les commits sont ajoutés à la TÊTE de la cible de dépôt.
    InformationsquelleAutor Damien R.
  6. 7

    En fonction sur cet article, à l'aide de la sous-arborescence est ce qui a fonctionné pour moi et n'est valable que l'histoire a été transféré. Poster ici au cas où quelqu'un a besoin de l'escalier (assurez-vous de remplacer les espaces par des valeurs qui s'appliquent à vous):

    dans votre répertoire source de split sous-dossier dans une nouvelle branche

    git subtree split --prefix=<source-path-to-merge> -b subtree-split-result

    à destination des pensions de fusion dans la fraction de résultat de la branche

    git remote add merge-source-repo <path-to-your-source-repository>
git fetch merge-source-repo
git merge -s ours --no-commit merge-source-repo/subtree-split-result
git read-tree --prefix=<destination-path-to-merge-into> -u merge-source-repo/subtree-split-result

    vérifier vos modifications et de s'engager

    git status
git commit

    N'oubliez pas de

    Nettoyer par la suppression de la subtree-split-result branche

    git branch -D subtree-split-result

    Supprimer la distance que vous avez ajouté à extraire les données à partir de la source repo

    git remote rm merge-source-repo

    InformationsquelleAutor Alex
  7. 6

    Cette fonction permet de cloner à distance pensions dans les pensions de dir, après la fusion de tous les commits seront sauvés, git log sera afficher l'original s'engage et le bon chemin:

    function git-add-repo
{
    repo="$1"
    dir="$(echo "$2" | sed 's/\/$//')"
    path="$(pwd)"

    tmp="$(mktemp -d)"
    remote="$(echo "$tmp" | sed 's/\///g'| sed 's/\./_/g')"

    git clone "$repo" "$tmp"
    cd "$tmp"

    git filter-branch --index-filter '
        git ls-files -s |
        sed "s,\t,&'"$dir"'/," |
        GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
        mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
    ' HEAD

    cd "$path"
    git remote add -f "$remote" "file://$tmp/.git"
    git pull "$remote/master"
    git merge --allow-unrelated-histories -m "Merge repo $repo into master" --edit "$remote/master"
    git remote remove "$remote"
    rm -rf "$tmp"
}

    Comment utiliser:

    cd current/package
git-add-repo https://github.com/example/example dir/to/save

    Si faire un peu de changements que vous pouvez même déplacer des fichiers/répertoires de fusion des pensions dans des chemins différents, par exemple:

    repo="https://github.com/example/example"
path="$(pwd)"

tmp="$(mktemp -d)"
remote="$(echo "$tmp" | sed 's/\///g' | sed 's/\./_/g')"

git clone "$repo" "$tmp"
cd "$tmp"

GIT_ADD_STORED=""

function git-mv-store
{
    from="$(echo "$1" | sed 's/\./\\./')"
    to="$(echo "$2" | sed 's/\./\\./')"

    GIT_ADD_STORED+='s,\t'"$from"',\t'"$to"',;'
}

# NOTICE! This paths used for example! Use yours instead!
git-mv-store 'public/index.php' 'public/admin.php'
git-mv-store 'public/data' 'public/x/_data'
git-mv-store 'public/.htaccess' '.htaccess'
git-mv-store 'core/config' 'config/config'
git-mv-store 'core/defines.php' 'defines/defines.php'
git-mv-store 'README.md' 'doc/README.md'
git-mv-store '.gitignore' 'unneeded/.gitignore'

git filter-branch --index-filter '
    git ls-files -s |
    sed "'"$GIT_ADD_STORED"'" |
    GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
    mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
' HEAD

GIT_ADD_STORED=""

cd "$path"
git remote add -f "$remote" "file://$tmp/.git"
git pull "$remote/master"
git merge --allow-unrelated-histories -m "Merge repo $repo into master" --edit "$remote/master"
git remote remove "$remote"
rm -rf "$tmp"

    Avis

    Chemins remplace par sed, alors assurez-vous qu'il a déplacé dans le bon chemin après la fusion.

    Le --allow-unrelated-histories paramètre n'existe que depuis git >= 2.9.

    • Pour OS X des gens là-bas, installer gnu-sed pour obtenir le git-add-repo de la fonction de travail. Merci encore Andrey!
    InformationsquelleAutor Andrey Izman
  8. 3

    L'ajout d'une autre réponse que je pense que c'est un peu plus simple. Un pull de repo_dest est fait dans repo_to_import et puis un push --set-en amont url:repo_dest master est fait.

    Cette méthode a fonctionné pour moi l'importation de plusieurs petites repos dans un plus grand.

    Comment importer: repo1_to_import à repo_dest

    # checkout your repo1_to_import if you don't have it already 
git clone url:repo1_to_import repo1_to_import
cd repo1_to_import

# now. pull all of repo_dest
git pull url:repo_dest
ls 
git status # shows Your branch is ahead of 'origin/master' by xx commits.
# now push to repo_dest
git push --set-upstream url:repo_dest master

# repeat for other repositories you want to import

    Renommer ou déplacer des fichiers et des répertoires dans la position désirée dans l'original repo avant de faire l'importation. par exemple, 

    cd repo1_to_import
mkdir topDir
git add topDir
git mv this that and the other topDir/
git commit -m"move things into topDir in preparation for exporting into new repo"
# now do the pull and push to import

    La méthode décrite sur le lien suivant l'inspiration de cette réponse. Je l'ai aimé comme il semblait plus simple. MAIS Méfiez-vous! Il y a des dragons! https://help.github.com/articles/importing-an-external-git-repository git push --mirror url:repo_dest pousse vos locaux pensions de l'histoire et de l'état à distance (url:repo_dest). MAIS il supprime les anciens de l'histoire et de l'état de la télécommande. Le plaisir s'ensuit! :-E

    InformationsquelleAutor gaoithe
  9. 1

    Je voulais importer que des fichiers à partir de l'autre référentiel (XXX) dans mon cas. Le sous-arbre était trop compliqué pour moi et les autres solutions ne fonctionnent pas. C'est ce que j'ai fait:

    ALL_COMMITS=$(git log --reverse --pretty=format:%H -- ZZZ | tr '\n' ' ')

    Cela vous donne un espace séparé liste de tous les changements qui affectent les fichiers que je voulais importer (ZZZ) dans l'ordre inverse (vous pourriez avoir à ajouter --suivre pour capturer renomme ainsi). Ensuite, je suis allé dans le référentiel cible (YYY), a ajouté l'autre référentiel (XXX) à distance, a fait un fetch et enfin:

    git cherry-pick $ALL_COMMITS

    qui ajoute tous les commits de votre agence, vous aurez ainsi tous les fichiers avec leur histoire et pouvez faire ce que vous voulez avec eux comme si ils ont toujours été dans ce référentiel.

    InformationsquelleAutor Sebastian Blask
  10. 0

    J'étais dans une situation où j'ai été à la recherche pour -s theirs mais bien sûr, cette stratégie n'existe pas. Mon histoire c'est que j'avais fourche d'un projet sur GitHub, et maintenant, pour une raison quelconque, mon local master pourrait ne pas être fusionné avec upstream/master bien que je n'avait pas fait de modifications locales à cette branche. (Ne sais vraiment pas ce qui s'est passé là-je suppose en amont l'avaient fait certains sale pousse derrière les scènes, peut-être?)

    Ce que j'ai fait était

    # as per https://help.github.com/articles/syncing-a-fork/
git fetch upstream
git checkout master
git merge upstream/master
....
# Lots of conflicts, ended up just abandonging this approach
git reset --hard   # Ditch failed merge
git checkout upstream/master
# Now in detached state
git branch -d master # !
git checkout -b master   # create new master from upstream/master

    Alors maintenant, mon master est de nouveau en synchronisation avec upstream/master (on peut répéter l'opération pour toutes les autres directions, vous aussi, vous souhaitez synchroniser de la même façon).

    • Un git reset --hard upstream/master sur votre master direction de faire le travail. De cette façon, vous ne perdez pas de succursale locale conflg – des choses comme la valeur par défaut en amont.
    InformationsquelleAutor tripleee
  11. 0

    Voir exemple de Base dans cet article et tenir compte de la cartographie sur les référentiels:

    • A <-> YYY,
    • B <-> XXX

    Après toutes les activités décrites dans ce chapitre (après la fusion), retirez la branche B-master:

    $ git branch -d B-master

    Ensuite, poussez les changements.

    Cela fonctionne pour moi.

    InformationsquelleAutor VeLKerr
  12. 0

    Je peux vous proposer une autre solution (alternative à git-submodules) pour votre problème de gil git (liens) de l'outil

    Il permet de décrire et de gérer des dépôts git dépendances.

    Il fournit également une solution à la git récursive submodules problème de dépendances.

    Considérer que vous avez le projet suivant dépendances:
    exemple de référentiel git graphe de dépendance

    Ensuite, vous pouvez définir .gitlinks fichier avec des dépôts rapport description:

    # Projects
CppBenchmark CppBenchmark https://github.com/chronoxor/CppBenchmark.git master
CppCommon CppCommon https://github.com/chronoxor/CppCommon.git master
CppLogging CppLogging https://github.com/chronoxor/CppLogging.git master

# Modules
Catch2 modules/Catch2 https://github.com/catchorg/Catch2.git master
cpp-optparse modules/cpp-optparse https://github.com/weisslj/cpp-optparse.git master
fmt modules/fmt https://github.com/fmtlib/fmt.git master
HdrHistogram modules/HdrHistogram https://github.com/HdrHistogram/HdrHistogram_c.git master
zlib modules/zlib https://github.com/madler/zlib.git master

# Scripts
build scripts/build https://github.com/chronoxor/CppBuildScripts.git master
cmake scripts/cmake https://github.com/chronoxor/CppCMakeScripts.git master

    Chaque ligne de décrire git lien dans le format suivant:

    1. Unique nom du référentiel
    2. Chemin d'accès relatif du référentiel (démarré à partir du chemin d'accès .gitlinks fichier)
    3. Dépôt Git qui sera utilisé dans la commande git clone
      Référentiel de direction à la caisse
    4. Ligne vide ou de la ligne a commencé avec # ne sont pas analysés (traités comme commentaire).

    Enfin, vous devez mettre à jour le répertoire racine de votre référentiel exemple:

    # Clone and link all git links dependencies from .gitlinks file
gil clone
gil link

# The same result with a single command
gil update

    Que le résultat vous aurez clone tous les projets requis et de les lier les uns aux autres d'une manière appropriée.

    Si vous voulez enregistrer toutes les modifications dans certains référentiel avec toutes les modifications de l'enfant référentiels liés, vous pouvez le faire avec une seule commande:

    gil commit -a -m "Some big update"

    Tirer, pousser des commandes fonctionne de manière similaire:

    gil pull
gil push

    Gil (git liens) outil prend en charge les commandes suivantes:

    usage: gil command arguments
Supported commands:
    help - show this help
    context - command will show the current git link context of the current directory
    clone - clone all repositories that are missed in the current context
    link - link all repositories that are missed in the current context
    update - clone and link in a single operation
    pull - pull all repositories in the current directory
    push - push all repositories in the current directory
    commit - commit all repositories in the current directory

    Plus sur git récursive submodules problème de dépendances.

    InformationsquelleAutor chronoxor
  13. -1

    Je ne connais pas de moyen facile de le faire. Vous pouvez faire ceci:

    1. L'utilisation de git filter-branch pour ajouter un ZZZ super-répertoire sur le XXX référentiel
    2. Pousser la nouvelle branche de la YYY référentiel
    3. De fusion de la poussée de la direction, avec YYY du tronc.

    Je peux le modifier avec des détails si cela semble intéressant.

    InformationsquelleAutor Walter Mundt
  14. -2

    Je pense que vous pouvez le faire à l'aide de git mv " et "git pull".

    Je suis juste git noob - donc soyez prudent avec votre dépôt principal - mais j'ai juste essayé ce dans un temp dir et il semble fonctionner.

    Première renommer la structure de XXX pour correspondre à la façon dont vous voulez qu'il ressemble quand il est dans YYY:

    cd XXX
mkdir tmp
git mv ZZZ tmp/ZZZ
git mv tmp ZZZ

    Maintenant XXX ressemble à ceci:

    XXX
 |- ZZZ
     |- ZZZ

    Maintenant utiliser "git pull" pour récupérer les modifications dans:

    cd ../YYY
git pull ../XXX

    Maintenant YYY ressemble à ceci:

    YYY
 |- ZZZ
     |- ZZZ
 |- (other folders that already were in YYY)
    InformationsquelleAutor Aaron