Généralement, il existe plusieurs branches : master develop, branches de fonctionnalités diverses, branche bug_fix, branche hot_fix
Master est généralement la version officielle en ligne. Inutile de dire que develop est développé, mais la branche placée dans develop est déjà une branche relativement stable. Lorsque vous souhaitez développer de nouvelles fonctionnalités, assurez-vous de créer une nouvelle branche feature_XXX sur la branche develop. Divers commit commit commit,
Si un bug est détecté ultérieurement dans la version précédente, une branche bug_fix_XXX sera créée si elle n'affecte pas la version en ligne, et une branche hot_fix sera créée pour les bugs sérieux qui affectent la version en ligne. hot_fix est différent de bug_fix. Une fois le bug résolu, la branche hot_fix sera fusionnée avec le master.
De plus, si vous souhaitez garder votre branche propre et nette, vous devrez peut-être utiliser rebase pour fusionner le code au lieu de fusionner
Pour les trucs git, je vous recommande de consulter progit, c'est très complet.
Même si vous ajoutez simplement une ligne de code, elle peut être traitée comme un commit.
Ne soumettez pas de code non pertinent à ce commit.
Vous devez savoir que l'effet que vous voulez obtenir est que si un jour je veux que vous reveniez à un certain état historique, vous pouvez rapidement retrouver cette soumission et revenir en arrière. Si vous n’y parvenez pas, la manière dont vous vous engagez n’a pas d’importance.
Par exemple, une fois que vous modifiez une valeur par défaut de 50 à 100, cela doit être traité comme une validation. Si vous corrigez un bug par accident, il ne peut pas être inclus dans ce commit. Sinon, comment pouvez-vous le ramener à 50 ? Devez-vous corriger à nouveau le bug après l'avoir annulé ?
Vous ne savez pas comment vous soumettre parce que vous n’avez pas d’objectif précis.
Si vous souhaitez être très détaillé, vous ne pouvez soumettre qu'une fonction spécifique.
Mais c’est tellement gênant.
De plus, vous pouvez également utiliser git gui pour soumettre en chinois et le décrire clairement.
Ceci est facultatif. C'est principalement pour votre commodité ou celle des autres à l'avenir. Je préciserai également dans les informations de validation de vos informations de validation que vous avez modifié les pages qui n'ont rien à voir avec la fonction. Quoi qu'il en soit, si vous faites preuve de diligence dans votre engagement, soumettre une fonctionnalité une seule fois n'est certainement pas suffisant
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Vous pouvez vous référer à git flow, je pense que cela peut résoudre vos doutes dans une large mesure
http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
Généralement, il existe plusieurs branches : master develop, branches de fonctionnalités diverses, branche bug_fix, branche hot_fix
Master est généralement la version officielle en ligne. Inutile de dire que develop est développé, mais la branche placée dans develop est déjà une branche relativement stable. Lorsque vous souhaitez développer de nouvelles fonctionnalités, assurez-vous de créer une nouvelle branche feature_XXX sur la branche develop. Divers commit commit commit,
Si un bug est détecté ultérieurement dans la version précédente, une branche bug_fix_XXX sera créée si elle n'affecte pas la version en ligne, et une branche hot_fix sera créée pour les bugs sérieux qui affectent la version en ligne. hot_fix est différent de bug_fix. Une fois le bug résolu, la branche hot_fix sera fusionnée avec le master.
De plus, si vous souhaitez garder votre branche propre et nette, vous devrez peut-être utiliser rebase pour fusionner le code au lieu de fusionner
Pour les trucs git, je vous recommande de consulter progit, c'est très complet.
Je le suis habituellement
Même si vous ajoutez simplement une ligne de code, elle peut être traitée comme un commit.
Ne soumettez pas de code non pertinent à ce commit.
Vous devez savoir que l'effet que vous voulez obtenir est que si un jour je veux que vous reveniez à un certain état historique, vous pouvez rapidement retrouver cette soumission et revenir en arrière. Si vous n’y parvenez pas, la manière dont vous vous engagez n’a pas d’importance.
Par exemple, une fois que vous modifiez une valeur par défaut de 50 à 100, cela doit être traité comme une validation. Si vous corrigez un bug par accident, il ne peut pas être inclus dans ce commit. Sinon, comment pouvez-vous le ramener à 50 ? Devez-vous corriger à nouveau le bug après l'avoir annulé ?
Vous ne savez pas comment vous soumettre parce que vous n’avez pas d’objectif précis.
Je pense que oui.
Si vous souhaitez être très détaillé, vous ne pouvez soumettre qu'une fonction spécifique.
Mais c’est tellement gênant.
De plus, vous pouvez également utiliser git gui pour soumettre en chinois et le décrire clairement.
Ceci est facultatif. C'est principalement pour votre commodité ou celle des autres à l'avenir. Je préciserai également dans les informations de validation de vos informations de validation que vous avez modifié les pages qui n'ont rien à voir avec la fonction. Quoi qu'il en soit, si vous faites preuve de diligence dans votre engagement, soumettre une fonctionnalité une seule fois n'est certainement pas suffisant
Utilisez davantage le rebase et fusionnez moins