2017-08-10 1 views
0

J'ai deux objectifs, et j'ai besoin d'un workflow pour les réaliser tout en travaillant sur mes fonctionnalités (master est un github repo d'entreprise).Flux de travail recommandé pour maintenir la branche git à jour

Objectifs:

  • Observe mes branche à jour

  • être en mesure de voir les changements que j'effectués à l'aide git diff et git show

Je suis nouveau à github, mais je essayé quelques scénarios pour y parvenir et ils ne m'aident pas.

Initialement, je crée une nouvelle branche (pistes origine/maître) et je fais un changement de code.

Je valide la modification et utilise git push origin pour publier cette modification dans github. Ensuite, je crée un PR et laisse les gens commenter.

Je reçois un bon feedback, je fais des changements de code et je commets en plus de mon 1er commit. Que faire pour synchroniser ma branche avec l'origine/le maître?

J'ai essayé de mettre à jour ma branche locale en fusionnant via git pull. Ca va bien, mais maintenant si je le fais git show je ne verrai pas mes changements, je verrai le dernier commit principal.

J'ai essayé de mettre à jour ma branche locale en rebasant via git pull --rebase. Je peux utiliser git show pour voir mes changements, mais mes branches locales et distantes sont désynchronisées, et je dois utiliser git push origin -f pour mettre à jour mon PR github avec le deuxième changement.

Je suis ouvert aux suggestions, merci!

+1

Tout ce que vous avez mentionné semble correct. Si votre seule question est de savoir comment afficher un diff d'un fichier d'un commit à un autre, puis-je vous recommander d'avoir un plugin Git pour votre IDE? IntelliJ, par exemple, fait un excellent travail en vous permettant de comparer un fichier avec n'importe quel commit dans la même branche, ou même avec d'autres branches. Beaucoup plus agréable que la ligne de commande. –

+0

Avez-vous trouvé la réponse pour résoudre le problème? Si oui, vous pouvez le marquer comme réponse. Et cela aidera les autres qui ont des questions similaires. –

Répondre

1

Ce que vous faites est une approche correcte. Il y a une grande différence entre pull et pull --rebase. Il fera git fetch && git merge origin/master resp. git fetch && git rebase origin/master. Les deux sont une approche correcte. La différence est dans l'histoire de l'arbre et dans la plupart des cas, c'est la politique de l'entreprise que d'utiliser plutôt. Avec rebase vous changerez toujours l'histoire et devrez forcer la poussée. Avec la fusion, vous ne modifierez pas l'historique, mais le dernier commit est la fusion.

Ne vous attendez pas à ce que vous ayez un seul commit qui sera poussé, donc le diff ne devrait pas être seulement pour un commit mais pour toute la branche. Si vous ne devez voir la diff, vous pouvez exécuter:

git show HEAD~1 

ou git show HEAD ~ 4..HEAD ~ 1

pour voir tous les changements de derniers commits sauf la dernière (fusionner).

Ou vous pouvez essayer quelque chose comme ça

git diff --boundary HEAD~1..origin/master 

P.S .: rebasage et pousser de force peut être assez dangereux quand plus de gens travaillent sur la même branche.Forcez la poussée seulement quand vous êtes sûr que vous êtes le seul à travailler sur la branche.

Il peut également y avoir des problèmes avec les commentaires. Je ne sais pas comment Github, mais Gitlab ne montrera pas les commentaires pour les lignes complètement modifiées ou supprimées après un effort forcé.