Disons que nous avons la situation suivante dans Git :
-
Un référentiel créé :
mkdir GitTest2 cd GitTest2 git init
-
Certaines modifications du maître ont lieu et sont enregistrées :
echo "On Master" > file git commit -a -m "Initial commit"
-
Feature1 s'est branché sur master et du travail a été fait :
git branch feature1 git checkout feature1 echo "Feature1" > featureFile git commit -a -m "Commit for feature1"
-
Pendant ce temps, un bogue est découvert dans le code maître et une branche de correction est établie :
git checkout master git branch hotfix1 git checkout hotfix1
-
Le bogue est corrigé dans la branche hotfix et réintégré dans le master (peut-être après une pull request/une révision du code) :
echo "Bugfix" > bugfixFile git commit -a -m "Bugfix Commit" git checkout master git merge --no-ff hotfix1
-
Le développement de la fonctionnalité 1 se poursuit :
git checkout feature1
Disons que j'ai besoin du correctif dans ma branche de fonctionnalité, peut-être parce que le bogue s'y produit également. Comment puis-je y parvenir sans dupliquer les commits dans ma branche de fonctionnalités ?
Je veux éviter de recevoir deux nouveaux commits sur ma branche de fonctionnalité qui n'ont aucun rapport avec l'implémentation de la fonctionnalité. Cela me semble particulièrement important si j'utilise des demandes de téléchargement : Tous ces commits seront également inclus dans la demande de pull et devront être revus bien que cela ait déjà été fait (puisque le correctif est déjà dans le master).
Je ne peux pas faire un git merge master --ff-only
: "fatal : Impossible d'effectuer une avance rapide, abandon", mais je ne suis pas sûr que cela m'ait aidé.
13 votes
Si la branche
feature1
est complètement local, jetez un coup d'œil àgit rebase
.31 votes
Merci, en tant que débutant de git,
git rebase
ça ressemble à de la magie noire pour moi....13 votes
Si la branche est fonctionnalité -Seulement, la correction du bug ne devrait pas avoir lieu ici (du moins si ce n'est pas un bug bloquant) puisque le but de cette branche est de montrer une nouvelle fonctionnalité. Le bug sera corrigé lors de la fusion avec le master où le commit avec la correction est présent.
0 votes
@theomega 1,5 ans plus tard, je me retrouve avec la même question que vous. Avez-vous jamais trouvé une approche satisfaisante pour accomplir ce que vous vouliez ?
26 votes
Il est probablement intéressant de noter pour les débutants que dans 3.
git branch feature1
ygit checkout feature1
pourraient être combinés engit checkout -b feature1
et 4. pourraient être entièrement réduits àgit checkout -b hotfix1 master
1 votes
@gipi il peut y avoir quelques scénarios. probablement la fonctionnalité dépend d'une autre partie qui a été corrigée par le hotfix. De plus, j'ai eu le cas où j'ai fait une branche à un moment où un test était cassé. C'est ennuyeux d'avoir des tests ratés de quelqu'un d'autre qui polluent les résultats de ses propres tests.
4 votes
Seriez-vous prêt à revenir et à changer la réponse acceptée, parce que la réponse acceptée actuelle est affreuse.
2 votes
@Omnifarious, il serait utile que vous puissiez identifier la réponse que vous avez trouvée affreuse. À ce stade, la réponse acceptée pourrait avoir changé, donc on ne sait pas laquelle est à éviter. Merci. (Bien que j'admette que la réponse acceptée en ce moment, par David Sulc, me semble très peu attrayante, même si elle fonctionne et serait utile dans certaines situations.
rebase
devrait être un dernier recours, imo, et "gérer tous les conflits qui se présentent" ... bien.)2 votes
@Mars - J'aurais dû préciser. Je voulais dire cette réponse : stackoverflow.com/a/16957483/167958
1 votes
@Mars et pour être clair, c'est la réponse que je pense. devrait être accepté.
0 votes
git fetch && git rebase -i origin/master
est définitivement la voie à suivre si votre branche de fonctionnalités est locale... J'ai le même problème, mais la branche de fonctionnalités est dans le nuage et plusieurs développeurs travaillent dessus.0 votes
Aux étapes 2, 3 et 5, le drapeau -a de git commit ne fait pas ce que vous sous-entendez. Pour les nouveaux fichiers qui ne sont pas déjà connus du repo, vous devez manuellement
git add
. Une fois qu'ils ont été livrés une fois, les changements futurs peuvent être ajoutés automatiquement au moment de la livraison avecgit commit -a
0 votes
Veuillez envisager d'accepter la "bonne" réponse, plutôt qu'une réponse potentiellement trompeuse au mieux, et horriblement trompeuse au pire.
0 votes
Un bon article de synthèse pour référence. gist.github.com/digitaljhelms/4287848
0 votes
C'est une question bien structurée @theomega. Cela correspond au scénario qui m'a amené ici. Si les questions étaient posées de cette manière, il serait plus facile d'y répondre.