Remise à zéro des branches distantes dans Git

Question

J'utilise un dépôt Git intermédiaire pour refléter un dépôt SVN distant, à partir duquel les gens peuvent cloner et travailler. La branche master du dépôt intermédiaire est rebasée chaque nuit à partir du SVN amont, et nous travaillons sur des branches de fonctionnalités. Par exemple :

remote:
  master

local:
  master
  feature

Je peux pousser avec succès ma branche de fonctionnalité vers la télécommande, et obtenir ce que j'attends :

remote:
  master
  feature

local:
  master
  feature

J'ai ensuite réorganisé la branche pour suivre la télécommande :

remote:
  master
  feature

local:
  master
  feature -> origin/feature

Et tout va bien. Ce que je voudrais faire à partir d'ici, c'est rebaser la branche feature sur la branche master sur la machine distante, mais je voudrais le faire depuis ma machine locale. J'aimerais être capable de le faire :

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

Pour garder la branche de fonctionnalité distante à jour avec le master distant. Cependant, cette méthode provoque une plainte de Git :

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull fait l'affaire mais provoque un commit de fusion que j'aimerais éviter. Je suis préoccupé par le fait que le message indique feature -> feature plutôt que feature -> origin/feature mais c'est peut-être juste une question de présentation.

Est-ce que j'ai raté quelque chose, ou est-ce que je m'y prends de la mauvaise façon ? Il n'est pas essentiel d'éviter d'effectuer le rebasement sur le serveur distant, mais cela rend la résolution de tout conflit de fusion à partir du rebasement beaucoup plus difficile.

Answer 1

Il s'agit de savoir si la fonction est utilisée par une seule personne ou si d'autres personnes l'utilisent.

Vous pouvez forcer le push après le rebasement s'il n'y a que vous :

git push origin feature -f

Cependant, si d'autres personnes travaillent dessus, vous devez fusionner et non pas rebaser à partir de master.

git merge master
git push origin feature

Cela vous permettra de vous assurer que vous avez une histoire commune avec les personnes avec lesquelles vous collaborez.

A un autre niveau, vous ne devriez pas faire de back-merges. Ce que vous faites, c'est polluer l'historique de votre branche feature avec d'autres commits qui n'appartiennent pas à la feature, ce qui rend plus difficile le travail ultérieur avec cette branche - rebasement ou non.

Voici mon article sur le sujet intitulé branche par fonction .

J'espère que cela vous aidera.

Answer 2

C'est bien que vous ayez abordé ce sujet.

Il s'agit d'une chose/concept important dans git qu'un grand nombre d'utilisateurs de git auraient intérêt à connaître. git rebase est un outil très puissant qui vous permet de regrouper des commits, de supprimer des commits, etc. Mais comme avec tout outil puissant, vous devez savoir ce que vous faites ou quelque chose pourrait mal tourner.

Lorsque vous travaillez localement et que vous manipulez vos branches locales, vous pouvez faire ce que vous voulez tant que vous n'avez pas poussé les changements vers le dépôt central. Cela signifie que vous pouvez réécrire votre propre histoire, mais pas celle des autres. En ne manipulant que votre matériel local, rien n'aura d'impact sur les autres dépôts.

C'est pourquoi il est important de se rappeler qu'une fois que vous avez poussé des commits, vous ne devez pas les rebaser par la suite. La raison pour laquelle c'est important, c'est que d'autres personnes pourraient tirer vos commits et baser leur travail sur vos contributions à la base de code, et si vous décidez plus tard de déplacer ce contenu d'un endroit à un autre (rebasez-le) et de pousser ces changements, alors d'autres personnes auront des problèmes et devront rebaser leur code. Imaginez maintenant que vous ayez 1000 développeurs :) Cela entraîne beaucoup de remaniements inutiles.

Answer 3

Parce que vous avez rebasculé feature en plus de la nouvelle master votre bureau local feature n'est pas un fast-forward de origin/feature plus. Donc, je pense que c'est parfaitement bien dans ce cas de passer outre la vérification de l'avance rapide en faisant git push origin +feature . Vous pouvez également le spécifier dans votre configuration

git config remote.origin.push +refs/heads/feature:refs/heads/feature

Si d'autres personnes travaillent sur le dessus de origin/feature ils seront perturbés par cette mise à jour forcée. Vous pouvez éviter cela en fusionnant dans le nouveau fichier master en feature au lieu de rebaser. Le résultat sera effectivement une avance rapide.

Answer 4

Je ne suis pas familier avec l'utilisation de GitBash et j'ajoute une réponse utilisant TortoiseGit (GUI pour les novices) ici pour les développeurs utilisant Windows :

Comme beaucoup l'ont mentionné plus haut, faites-le ne serait-ce qu'avec votre branche de repo "privée" et cela signifie que personne ne vous jettera jamais la pierre pour avoir re-basé la branche "development" ou "feature" distante avec votre copie locale. Les autres développeurs qui ont commis et poussé leur semaine de travail (ou plus) seront EFFACÉS de l'historique (log) de la branche.

Il n'y aura aucun moyen de les récupérer - bien sûr, vos co-développeurs auront toujours leurs modifications sur les leurs, car leur PULL lancera très probablement une erreur car ils seront très en avance sur l'historique actuel de la branche ou les derniers commits par rapport aux leurs. Une bonne chose que Git soit un système de versionnement distribué.

Donc, soyez prudent avec ce pouvoir de rétablir une branche distante. Vous êtes prévenus ;)

Answer 5

Vous pouvez désactiver cette vérification (si vous êtes vraiment sûr de savoir ce que vous faites) en utilisant la fonction --force option pour git push .