Écraser les commits Git

J'utilise Git tous les jours et j'ai écrit unGuide Gitet unAide-mémoire Gitdans le passé.

Je me considère comme un fan de Git, mais… je ne suis pas un expert de Git.

Valider, récupérer l'origine, extraire l'origine, pousser vers l'origine ... c'est mon utilisation quotidienne de Git.

Et je faisquelquesGit:

Les choses avancées que Git peut faire m'époustouflent. Cela peut être très complexe et j'ai tendance à éviter toute cette complexité. Je n'utilise presque jamais Git en ligne de commande et j'utiliseBureau GitHubqui est le client Git le plus simple et le plus agréable jamais créé.

Cependant, deux choses que j'utilise parfois sontcueillette des cerisesetsquashing commet.

Parlons-en.

Dans les projets où je suis le seul développeur, ce qui signifie tous mes projets personnels, j'ai tendance à travailler sur master quand je le peux. Par exemple, si je fais un simple changement ou que j'ajoute un nouveau message au blog. Des trucs rapides et insécables.

Dans certains cas, cependant, je n'utilise pas cette approche, et à la place je crée une branche pour une grande fonctionnalité.

C'est également la valeur par défaut lorsque vous travaillez sur un projet en équipe ou open source.

Vous créez une branche et vous vous engagez souvent. S'engager tôt et souvent est un grand avantage car vous pouvez travailler sur votre code avec la certitude que vous pouvez toujours revenir à un état de fonctionnement, ou du moins à un état dans lequel vous savez que quelque chose a fonctionné.

Vous pouvez faire une série de commits rapides où le message est «ok», «essayez ceci» ou «corrigez une erreur stupide».

Mais à un moment donné, vous devez converger vers un état stable et valider les modifications vers master, ou vers n'importe quelle branche de votre choix.

Vous voulez faire une chose avant cela: écraser vos commits.

GitHubpeut le faire pour vous automatiquement lorsque vous fusionnez une Pull Request, et c'est un flux de travail que j'ai beaucoup utilisé sur les référentiels Open Source publics dans le passé.

Au lieu de voir tous les commits individuels contenus dans une Pull Request, vous ne voyez qu'un seul commit, et dans le processus de fusion PR, vous pouvez écrire un message et une description de commit détaillés et dédiés.

Cela éliminera tous les commits Git précédents qui divergent de la tête de la branche vers laquelle vous fusionnez, et supprimera également tous ces commits où vous avez peut-être annulé les modifications, et ainsi de suite.

C'est écrasant dans le processus GitHub PR. Vous pouvez également écraser vos commits en dehors de GitHub.

Une fois votre travail sur une branche terminé, vous fusionnez le master (ou toute autre branche dans laquelle vous souhaitez fusionner):

git merge master

vous pouvez donc y gérer tout conflit de mise à jour.

Ensuite, vous contrôlez le maître et à partir de là, vous exécutez:

git merge --squash <your-feature-branch>

puis

git commit

Ce n'est que l'un des flux de travail possibles que vous pouvez utiliser, et tout faire avec GitHub est très simple et l'option qui peut vous donner le moins de maux de tête.


Plus de tutoriels git: