Comment puis-je rejeu mes commits d'un dépôt Git local, sur un projet, je bifurqué sur github.com?
https://stackoverflow.com/questions/1457248
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Oui, je sais que je aurais dû fourchue le projet depuis le début, mais c'est quelle situation je suis maintenant. :)
J'ai un dépôt Git local qui contient mon blog, sur mon ordinateur local, qui a plusieurs mois de commettre l'histoire. A l'origine, j'ai simplement téléchargé les fichiers à partir du référentiel http://github.com/mojombo/mojombo.github.com , et je continué avec mon dépôt Git local, avec le premier engagement à la recherche comme les derniers fichiers de référentiel de mojombo.
Je voudrais maintenant bifurquer le projet et que mon dépôt Git local commits être rejoué sur le dessus de celui-ci, il semble que je bifurqué le projet depuis le début, puis poussé revenir à ma version fourchue du dépôt de mojombo, sur mon compte GitHub:
http://github.com/program247365/mojombo.github.com
Alors peut-être l'histoire alors ressembler à ceci:
mobjombo repository: 1---2---3----23
\
my blog repository commits: 24---25---
Qu'est-ce que les commandes Git puis-je utiliser exactement à ce faire?
J'ai regardé cette question. Est-ce que je dois ajouter le dépôt de mojombo comme télécommande pour mon projet, puis tirez dans, fusionner, résoudre les conflits, puis pousser à mon projet en forme de fourche sur GitHub?
La solution 2
Quand j'ai essayé git pull il m'a donné l'erreur suivante:
$ git pull grid master:master
! [rejected] master -> master (non fast forward)
Dans mon cas particulier, il semblait que git rebase était la voie à suivre pour moi, comme le montrent les étapes ici:
#Clone my forked project from github
git clone git@github.com:program247365/mojombo.github.com.git
#Add my repo as a remote repo, with the alias 'grid'
git remote add grid "path/to/remote/gitrep/with/all/history/unrelated/to/mojombo/"
#Rebase my commits on top of mojombo's
git rebase master grid/master
#Switch to the local master branch
git checkout master
#Call up my mergetool via git, to start rectifying the conflicts that emerge between my repo, and mojombo's
git mergetool
#Push my rebased/combined repo back to Github.com
git push github
Autres conseils
En bref:
Une solution consiste à utiliser greffes pour se connecter histoire, puis utilisez git filter-branch pour réécrire l'histoire en fonction de ces greffes, puis éventuellement faire une fusionner .
Notez que la solution à rejouer vos modifications (vos commits) sur le dessus du nouveau développement dans le référentiel d'origine ( rebasage solution) est une autre solution viable.
version plus longue:
Supposons que vous soit souvenez, ou vous pouvez trouver en examinant la source et / ou à l'aide des commandes git la révision du référentiel que vous avez téléchargé instantané, et a commencé le développement local. Appelons cette révision START ou A.
Supposons que vous l'histoire locale est déconnecté dans le clone du référentiel d'origine. Cela signifie que votre développement local est déconnecté dans le même référentiel que l'histoire complète d'un projet. Supposons que vous les branches locales sont en « maître » branche (et pour la simplicité qu'il n'y a qu'une seule branche).
Si vous avez projet ne tiré par les cheveux dans le référentiel avec votre travail déconnecté local, vous pouvez le faire avec:
$ git remote add origin git://github.com/mojombo/mojombo.github.com.git
$ git fetch origin
L'histoire ressemble maintenant à ce qui suit:
*---*---*---*---*---A---*---*---*---* <--- origin/master (remote-tracking branch)
x---y---*---*---* <--- master (your local disconnected history)
Le nom de commettre un dans le diagramme ci-dessus est le début vous engagerez-vous téléchargé comme instantané et a commencé votre développement local au large.
Il y a deux possibilités:. Vous avez comitted instantané de « A » comme un premier commit « x », ou la première vous engagerez-vous fait était avec vos modifications locales
En premier cas (vous avez commis état de départ d'origine, par exemple comme « commit initial » ou « d'importation ») que vous voulez l'histoire connecté à ressembler à ceci:
*---*---*---*---*---A---*---*---*---* <--- origin/master (remote-tracking branch)
\
\-y---*---*---* <--- master (your local disconnected history)
i.e.. votre premier original commit 'y' pour avoir 'A' en tant que parent.
Dans le second cas (vous engagé avec vos changements) que vous voulez l'histoire connecté à ressembler à ceci:
*---*---*---*---*---A---*---*---*---* <--- origin/master (remote-tracking branch)
\
\-x---y---*---*---* <--- master (your local disconnected history)
i.e.. vous voulez d'abord commit 'x' avoir « A » en tant que parent.
Dans les deux cas, vous voulez trouver plein identifiant SHA-1 de commit 'A', et pleins identifiants SHA-1 de x »commits et 'y'.
Vous pouvez trouver SHA-1 de commit 'A' (en supposant que vous ne connaissez pas déjà) avec git rev-parse :
$ git rev-parse A # or A^{commit}
437b1b20df4b356c9342dac8d38849f24ef44f27
(la '^ {commit}' suffixe pourrait être nécessaire pour vous assurer que vous avez trouvé commit SHA-1, ce qui est important si vous par exemple savoir 'A » par son étiquette, par exemple' v0.99' . dans votre cas il ne faut pas, comme le dépôt en question ne pas utiliser les tags)
Vous pouvez trouver SHA-1 de commits x »et 'y' en utilisant git rev-list (en supposant que vous le développement a été fait sur la branche 'maître'):
$ git rev-list --topo-order master | tail -2
8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
e83c5163316f89bfbde7d9ab23ca2e25604af290
(la « | tail -2 » est ici pour les deux derniers commits dans la liste générée, vous n'avez pas besoin de l'utiliser si vous ne l'avez pas).
Remarque: dans tous les exemples ci-dessus complète SHA-1 sont Exemples , et ne doit pas être utilisé comme est
Appelons le commit que vous voulez avoir « A » (ou « START ») en tant que parent comme premier (il serait « x » ou « y », selon vous cas, comme indiqué ci-dessus). Maintenant, nous utiliser mécanisme greffons pour se connecter histoire:
$ echo "<SHA-1 of FIRST> <SHA-1 of START>" > .git/info/grafts
Ensuite, vous devriez vérifier si vous l'histoire avez maintenant correctement connecté (joint), en utilisant le navigateur de l'histoire graphique tels que gitk, ou QGit ou GitX est que vous êtes sur Mac OS X, ou même « git log --graph » ou « git show-branch », par exemple:
$ gitk master origin/master # or --all
(où gitk est ici à titre d'exemple, si vous utilisez « git show branch » vous ne peut pas toujours utiliser l'option « --all »).
Enfin, nous voudrions probablement faire les changementss permanent, de sorte que tous ceux qui se vendraient de notre dépôt aurait aussi l'histoire connecté. Nous pouvons le faire en utilisant git Filtre- branche :
$ git filter-branch master
Vous auriez l'histoire originale (déconnecté) dans 'refs / original / maître.
Maintenant, vous pouvez supprimer des greffons fichier:
$ rm .git/info/grafts
Maintenant, vous seriez en mesure de fusionner dans le nouveau développement de référentiel d'origine:
$ git merge origin/master
Configuration de la configuration par branche, de sorte qu'il serait suffisant pour faire simplement « git pull » quand sur la branche « maître » pour tirer des changements (de fusion) d'origine référentiel (al) est laissé comme exercice pour le lecteur .. .: -)
Note: entraînerait l'histoire suivante solution rebasage (en supposant que nous avons le cas où le premier comit était simple importation):
*---*---*---*---*---A---*---*---*---* <--- origin/master (remote-tracking branch)
\
\-y'---*'---*'---*' <--- master (your local disconnected history)
(où les moyens de y' qui allouent y a été modifié: il devrait être sur le même changeset, mais il est différent comme commit).
Voici une idée sur ce que vous pourriez faire. Il est un peu à l'opposé de l'idée que vous résumez au fond de votre question.
- repo de fourchette mojombo dans GitHub.
- Cloner votre copie fourchue.
- Fusionner vos modifications de votre référentiel existant (original).
- Supprimer votre référentiel d'origine (si on le souhaite, mais vous ne vraiment pas besoin plus).
Donc, fondamentalement, après bifurquer sur GitHub, vous pouvez utiliser la séquence de commandes suivantes:
$ git clone git://github.com/$YOUR_USERNAME/$YOUR_PROJECT.git # Clone your GitHub fork (#2 from above)
$ git pull /path/to/your/original/repo master:master # Clone your original repo's master branch into your new repo (cloned from GitHub)
$ rm -rf /path/to/your/original/repo # Might as well delete the original -- you don't need it anymore, since all your history is in your new repo
En résumé, cette méthode de fusion dans tous les changements que vous avez apportées dans le repo (préservant ainsi votre histoire du développement) plus, tout en tirant dans l'histoire de mojombo, et vous permettant de suivre avec les changements de mojombo / facilement contribuer modifications à sa mise en pension, le cas échéant.
