Je suis le seul membre de mon organisation à s'engager avec le message suivant:
Fusionner origine / développement de la branche de suivi à distance en développement
Pas sûr de ce que je fais pour les causer, mais j'aimerais arrêter.
Quelle commande est-ce que je lance pour créer ce commit, et quelle est la commande appropriée que je devrais utiliser pour ne pas le produire?
Merci,
~ J
git pull est probablement la création de la commettre. Si vous faites une validation puis exécutez git pull , après que quelqu'un pousse un engager dans le dépôt Git de téléchargements de l'autre développeur commit, puis les fusionne dans votre succursale locale.
Vous pouvez utiliser git pull --rebase pour éviter que cela se reproduise à l'avenir, mais rebasage a ses périls, et je vous recommande d'éviter pull au total.
Au lieu de cela, je vous encourage à suivre ce modèle d'utilisation:
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
git remote update -p téléchargements de tous les commits dans les dépôts distants et les mises à jour du suivi à distance des branches (par exemple, origin/master). Elle ne touche PAS votre répertoire de travail, de l'index ou de branches locales.
L' -p argument pruneaux supprimé en amont des branches. Ainsi, si l' foo branche est supprimée dans l' origin référentiel, git remote update -p sera automatiquement supprimer votre origin/foo réf.
git merge --ff-only @{u} indique à Git merge de l'amont de la branche ( @{u} argument) dans votre branche locale, mais seulement si votre succursale locale peut être "avance rapide" à l'amont de la branche (en d'autres termes, s'il n'a pas divergé).
git rebase -p @{u} déplace effectivement les commits que vous avez fait, mais qui n'ont pas encore poussé sur le dessus de l'amont de la branche, ce qui élimine le besoin de créer le ridicule de fusion engage que vous essayez d'éviter. Cela améliore la linéarité de l'histoire du développement, en la rendant plus facile à examiner.
L' -p option indique à Git pour préserver les fusions. Cela empêche Git à partir de linéarisant les commits d'être relocalisée. Ceci est important si, par exemple, vous de fusionner une branche en master. Sans -p, chaque commit sur la branche serait dupliqué sur master dans le cadre de la linéarisation fait par git rebase. Ce serait faire l'histoire du développement plus difficile à suivre, pas plus facile.
Méfiez-vous: git rebase ne pourrait pas faire ce que vous vous attendez à faire, afin de passer en revue les résultats avant de pousser. Par exemple:
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
Je préfère cette approche plus git pull --rebase , pour les raisons suivantes:
-p (--preserve-merges) option d' git rebase dans le cas où vous avez besoin de rebase intentionnelle de fusion (par exemple, la fusion d'un déjà-poussé branche en master).git up au lieu de git pull
Pour le rendre facile à faire la-dessus, je vous recommande de créer un alias appelé up:
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
Maintenant, tout ce que vous devez faire pour apporter votre branche jusqu'à la date de l'exécution:
git up
au lieu de git pull. Si vous obtenez une erreur parce que votre succursale locale a divergé à partir de l'amont de la branche, c'est votre signal pour rebase.
git pull --rebase?L'exécution git pull --rebase est équivalent à l'exécution d' git fetch suivie par git rebase. Celui-ci tente d'avancer rapidement à la nouvelle en amont s'engage, mais si ce n'est pas possible, alors il sera de rebase de votre région s'engage sur la nouvelle en amont s'engage. C'est généralement OK, mais attention:
git pull --rebase ne vous donne pas la possibilité d'examiner les commits avant de les incorporer. Selon ce qui a changé en amont, c'est tout à fait possible que rebase est le mauvais fonctionnement- rebase --onto, merge, resetou push -f pourrait être plus approprié qu'un simple rebase.--preserve-merges pour le rebase opération, de sorte que toute intentionnel de la fusion d'une branche va être linéarisé, la relecture (et donc de la duplication) de la totalité de la branche s'engage.git pull
Si vous n'avez pas encore poussé une fusion de commettre créé par git pull, vous pouvez rebase la fusion s'engager. En supposant que vous n'avez pas fait toute intentionnelle fusionne (par exemple, la fusion d'un déjà-poussé branche dans votre direction), la suite devrait le faire:
git rebase @{u}
La commande ci-dessus indique à Git pour sélectionner tous les non-fusion s'engage accessible à partir d' HEAD (commit), moins tous les commits accessible à partir d' @{u} (qui est un raccourci pour "l'amont de la branche", c'est à dire, origin/master si HEAD est master), la relecture (cherry-pick) sur le dessus de l'amont de la branche, puis déplacer la direction de la référence au point à la suite de la relecture de la commet. Ce déplace effectivement la non-fusion s'engage sur la plus récente en amont s'engager, ce qui élimine la fusion créé par git pull.
Si vous avez un intentionnelle de fusion engager, vous ne voulez pas exécuter git rebase @{u} parce qu'il va rejouer tout de l'autre branche. Traitant de ce cas est beaucoup plus compliqué, c'est pourquoi il est bon d'utiliser git up et d'éviter git pull tout à fait. Vous aurez probablement à utiliser reset pour annuler la fusion créé par pull puis effectuez l' git rebase -p @{u}. L' -p argument git rebase n'a pas fonctionné de manière fiable, pour moi, de sorte que vous pourriez avoir à utiliser reset pour annuler le intentionnelle de fusion, de mise à jour de votre agence locale pour @{u}, et ensuite refaire le intentionnelle de fusion (ce qui est une douleur si il y avait beaucoup de poilus les conflits de fusion).
git fetch
git rebase origin/master
Cela devrait le faire. Ou si vous souhaitez continuer à utiliser tirez
git pull --rebase
Vous pouvez également configurer cette branche dans votre config pour rebase automatiquement, ou être configuré comme ça automatiquement pour toute autre avenir le suivi des branches que vous faites. Ensuite, vous pouvez revenir juste à l'aide de
git pull
Plus à ce sujet dans le "pull avec rebase au lieu de fusionner" l'article de cette page:
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
