Rebasage des branches distantes dans Git

J'utilise un référentiel Git intermédiaire pour mettre en miroir un référentiel SVN distant, à partir duquel les gens peuvent cloner et travailler. Le référentiel intermédiaire a sa branche principale rebasée tous les soirs à partir du SVN en amont, et nous travaillons sur des branches de fonctionnalités. Par exemple:

remote:
  master

local:
  master
  feature

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

remote:
  master
  feature

local:
  master
  feature

Je reconfigure ensuite 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 est de rebaser la branche de fonctionnalité vers la branche principale de la télécommande, mais je voudrais le faire à partir de ma machine locale. J'aimerais pouvoir faire:

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

Pour maintenir la branche de fonctionnalité distante à jour avec le maître distant. Cependant, cette méthode amène Git à se plaindre:

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 pullfait l'affaire mais provoque un commit de fusion que j'aimerais éviter. Je crains que le message indique feature -> featureplutôt que, feature -> origin/featuremais ce n'est peut-être qu'une présentation.

Suis-je en train de rater quelque chose ou de m'y prendre complètement de la mauvaise manière? Il n'est pas essentiel d'éviter de faire le rebase sur le serveur distant, mais cela rend la résolution des conflits de fusion à partir du rebase beaucoup plus difficile.

Il s'agit de savoir si la fonctionnalité est utilisée par une personne ou si d'autres y travaillent.

Vous pouvez forcer la poussée après le rebase si ce n'est que vous:

git push origin feature -f

Cependant, si d'autres travaillent dessus, vous devez fusionner et ne pas rebaser hors de master.

git merge master
git push origin feature

Cela garantira que vous avez une histoire commune avec les personnes avec lesquelles vous collaborez.

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

Ceci est mon article sur le sujet appelé branche par fonctionnalité .

J'espère que cela t'aides.

Bien que vous ayez abordé ce sujet.

C'est une chose / un concept important dans git que beaucoup d'utilisateurs de git gagneraient à connaître. git rebase est un outil très puissant et vous permet d'écraser les commits ensemble, de supprimer les commits, etc. Mais comme avec tout outil puissant, vous devez essentiellement savoir ce que vous faites ou quelque chose pourrait vraiment mal tourner.

Lorsque vous travaillez localement et que vous dérangez vos succursales locales, vous pouvez faire ce que vous voulez tant que vous n'avez pas poussé les modifications vers le référentiel central. Cela signifie que vous pouvez réécrire votre propre histoire, mais pas celle des autres. En ne jouant qu'avec vos trucs locaux, rien n'aura d'impact sur les autres référentiels.

C'est pourquoi il est important de se rappeler qu'une fois que vous avez poussé les commits, vous ne devez pas les rebaser plus tard. La raison pour laquelle c'est important, c'est que d'autres personnes pourraient tirer dans 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 les pousser changements, alors d'autres personnes auront des problèmes et devront rebaser leur code. Imaginez maintenant que vous avez 1000 développeurs :) Cela ne fait que causer beaucoup de retouches inutiles.

Parce que vous avez rebasé featureau-dessus du nouveau master, votre local featuren'est plus une avance rapide origin/feature. Donc, je pense qu'il est parfaitement bien dans ce cas d'annuler la vérification d'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 dessus origin/feature, elles seront dérangées par cette mise à jour forcée. Vous pouvez éviter cela en fusionnant le nouveau masterdans featureau lieu de le rebaser. Le résultat sera en effet une avance rapide.

Vous pouvez désactiver la vérification (si vous êtes vraiment sûr de savoir ce que vous faites) en utilisant l' --forceoption à git push.