Git pour le développement d'une personne

Question

J'ai essayé d'apprendre et de m'habituer au contrôle de version, plus spécifiquement git. Cependant, mon équipe de développement est actuellement (et pour l'avenir prévisible) composée uniquement par moi, et donc, mon objectif avec git a été d'essayer de maîtriser les techniques de branchement et d'engagement.

J'ai vu et essayé quelques exemples de flux de travail, tels que git-flow. Cependant, je n'arrive pas à maîtriser vraiment comment les utiliser. Par exemple, à quelle fréquence et quel type de contenu les commits doivent-ils avoir? Quand devrais-je réellement me brancher pour une nouvelle fonctionnalité? Je me retrouve très souvent dans des situations où j'écris une nouvelle fonctionnalité, et je me rends compte soudainement que je dois corriger une erreur de codage précédente, ou supposer finir une nouvelle fonctionnalité et plus tard réaliser que certaines choses me manquent encore. Cela conduit à des branchements et à des validations qui ne prêtent absolument à rien. Et je me demande à quel point le contrôle de la version d'aide est vraiment efficace.

Qu'est-ce que je fais de mal? Ou est-ce que les systèmes de contrôle git/version ne sont pas conçus pour le développement d'une seule personne?

Answer 1

Si vous débutez avec le contrôle de version, pour un projet d'une seule personne, ne vous inquiétez pas de tous ces flux de travail, etc. D'abord, s'habituer à commettre.

Avez-vous simplement exécuté votre programme et testé quelque chose, et cela a fonctionné? Génial, commettez. Au sujet de faire quelque chose que vous n'êtes pas sûr que cela fonctionnera? Commettre. S'engager tôt et souvent. La bonne chose à propos de git est que les commits sont annulables si vous avez choisi un mauvais endroit pour commettre (indice: s'il ne compile pas, c'est probablement un mauvais endroit - mais il y a des exceptions à cela, une fois que vous êtes satisfait avec git rebase -i et git add -i (un peu comme un outil avancé, alors commencez par vous familiariser avec les bases (les parenthèses imbriquées sont amusantes!))). Maintenant, à propos de la commutation focus - git a un certain nombre d'outils utiles pour cela.

Par exemple, si vous voulez corriger un bug, mais un tas d'autres travaux déjà ...

git stash save 

Git prend alors toutes les modifications non validées, les enregistre, et revient à la dernière validation. Vous pouvez corriger le bug, test, validation, puis

git stash pop 

Toutes ces modifications sont ensuite réappliquées au-dessus du bugfix.

Si vous travaillez sur une petite fonctionnalité, mais réaliser c'est en fait un peu compliqué et vous engager probablement plus d'une fois ...

git checkout -b mynewbranch 

Et là, vous allez - vous êtes maintenant sur une nouvelle branche. Vous pouvez revenir à une autre branche à tout moment avec

git checkout someotherbranch 

Vous pouvez utiliser ainsi git stash pour enregistrer les modifications non engagés, puis échanger à une autre branche à faire quelque chose de complètement différent. Et quand vous voulez revenir, git checkout mynewbranch.

Comme outil un peu plus avancé, si vous avez un petit bugfix à faire, et ne veulent pas se préoccuper de toute chose Stashing, vous pouvez faire

git add -i 
# select what changes to include 
git commit # commits only what you selected 

Ceci est grâce à l'indice git - git add -i vous permet de sélectionner, au niveau de la ligne individuelle, exactement ce qu'il faut copier de la copie de travail à l'index, puis git commit l'enregistre en tant que validation. En faisant cela, vous pouvez très rapidement et facilement extraire les corrections mineures à partir d'un tas d'autres changements. Notez, cependant, que cela signifie que vous venez de commettre quelque chose qui n'a jamais été compilé ou testé sous cette forme; il faut donc faire attention de ne pas commettre quelque chose qui est complètement cassé (vous devriez généralement éviter de commettre un code complètement brisé car il casse git bisect - un outil très pratique pour dépister les régressions). Une fois que vous avez l'habitude de ce flux de base, vous pouvez commencer à ajouter un processus à celui-ci. Par exemple, vous pouvez conserver une branche v1.x pour les corrections de bugs uniquement dans la série 1.x. Ou peu importe. Utilisez un flux de travail qui fonctionne pour vous.