En tant que développeur unique (pour l'instant), comment dois-je utiliser Git?
J'ai plusieurs projets sur Git dans lesquels je veux éventuellement en amener d'autres. Cependant, en ce moment, c'est juste moi et j'utilise Git et GitHub de manière très simpliste: pas de branches et simplement utiliser les commits comme sauvegarde de mes fichiers locaux. Parfois, je vais revenir en arrière et regarder les versions précédentes de mes fichiers pour référence, mais je n'ai pas eu besoin de faire de restauration à ce stade, bien que j'apprécie l'option si j'en ai besoin à l'avenir.
En tant que développeur unique, quelles fonctionnalités Git ou GitHub pourrais-je tirer parti de cela me bénéficieraient en ce moment? À quoi devrait ressembler mon flux de travail?
De plus, y a-t-il des pratiques particulières que je dois commencer à faire en prévision d'en ajouter d'autres à mes projets à l'avenir?
De plus, y a-t-il des pratiques particulières que je dois commencer à faire en prévision d'en ajouter d'autres à mes projets à l'avenir?
Bien sûr. Il existe une bonne pratique simple que vous pouvez utiliser même si vous n'avez pas d'équipe pour le moment: créer une branche séparée pour le développement. L'idée est que la branche principale ne contiendra que des versions de code publiées ou des changements majeurs. Cela peut être facilement adopté par les nouveaux développeurs qui rejoignent votre projet.
De plus, le branchement est utile même si vous travaillez en solo. Par exemple, vous trouvez un bogue pendant le processus de codage d'une nouvelle fonctionnalité. Si vous n'utilisez pas de branches, vous devrez faire les deux: ajouter de nouvelles fonctionnalités et corriger le bug dans la même branche. Ce n'est pas bon: P D'un autre côté, si vous avez créé une nouvelle branche pour créer votre nouvelle fonctionnalité, vous pouvez simplement extraire la branche de développement, corriger le bogue et extraire la nouvelle branche de fonctionnalité.
Ceci n'est qu'un bref exemple de ce que vous pouvez faire en tant que seul programmeur. Je suis sûr qu'il doit y avoir plus de bonnes pratiques.
Je vous recommande fortement cet article: n modèle de branchement Git réussi
Je suis exactement dans cette situation mais j'ai opté pour un workflow légèrement plus complexe mais pas nécessairement plus compliqué avec Git.
L'objectif au début était d'apprendre la manière git, j'ai donc fait un peu d'exploration. puis est revenu à peu près au flux de travail que vous avez décrit.
Après un certain temps, cela est devenu difficile à travailler car certaines situations se sont également produites, cela m'a donné de mauvaises habitudes qui seraient difficiles à briser une fois que je rejoindrais une équipe.
alors je me suis contenté de ce qui suit:
- Dépôt local pour travailler.
- Branche maître en tant que tronc stable pour l'application
- Une branche pour chaque fonctionnalité/refactor, essentiellement une branche pour chaque modification importante qui sera effectuée.
- Fusionner à nouveau vers le tronc lorsque la branche est stable et tous les tests réussis.
J'ai également configuré un compte hub git où je synchronise le tronc. Cela m'a permis de commencer facilement à travailler sur différents ordinateurs. C'était par nécessité mais cela m'a permis de trouver des bugs liés à l'environnement dans lequel j'étais et qui n'étaient pas disponibles sur les autres ordinateurs. Alors maintenant, je prends l'habitude d'essayer au moins une fois un projet sur un système "vierge" différent. Cela m'évite beaucoup de maux de tête quand vient le temps de se déployer chez le client.
- J'étiquette toutes les versions qui en font github en tant que version libérable.
- En cas de publication au client, je créerai une branche à partir de cette version pour créer un deuxième tronc stable pour les corrections de bogues déclarées par le client.
Au début, les multiples branches semblaient exagérées, mais cela a vraiment beaucoup aidé. Je pourrais commencer une idée dans une branche, y travailler pendant un certain temps et quand je commence à faire des cercles, j'ai abandonné et j'ai commencé une autre branche pour travailler sur autre chose. Plus tard, une idée est venue où je reviendrais à la branche à moitié cuite et explorerais cette idée. Dans l'ensemble, cela m'a rendu BEAUCOUP plus productif, car je pouvais agir très rapidement sur les flashs et les idées et voir si cela fonctionnait. Le coût de changement de branche avec GIT est extrêmement faible, ce qui me rend très agile avec ma base de code. Cela dit, je dois encore maîtriser le concept de rebase pour nettoyer mon histoire, mais comme je suis tout seul, je doute que j'en ai vraiment besoin. Poussé comme "Nice to learn".
Lorsque toutes les branches sont devenues compliquées, j'ai exploré l'option log pour dessiner un arbre de changements et voir quelles branches sont où.
Pour faire court, git n'est pas comme SVN, CVS ou (brrr) TFS. La ramification est très bon marché et faire des erreurs qui anéantiront le travail est en fait assez difficile. Une seule fois, j'ai perdu du travail et c'est parce que j'ai fait mes commits trop gros (voir les mauvaises habitudes ci-dessus). Si vous vous engagez souvent, par petits morceaux, git sera définitivement votre meilleur allié.
Pour moi, git m'a ouvert l'esprit sur le véritable contrôle des sources. Tout le reste n'était que des tentatives pour l'obtenir, git est le premier, qui dans mon esprit, l'a eu. Cela dit, je n'ai pas essayé d'autres DVCS, très probablement cette déclaration pourrait être étendue à toute la famille.
Un dernier conseil, la ligne de commande est votre amie. Pour ne pas dire que les outils graphiques ne sont pas bons, bien au contraire, mais j'ai vraiment grogné git quand je suis descendu en ligne de commande et l'ai essayé moi-même. Il est en fait très bien fait, facile à suivre avec un système d'aide très complet. Mon plus gros problème était lié à la console mais laide de Windows jusqu'à ce que je trouve des alternatives.
Maintenant, j'utilise les deux, l'intégration d'Eclipse avec Git pour voir ce qui se passe en temps réel et effectuer certaines opérations comme les différences, explorer l'historique d'un fichier, etc. Et la ligne de commande pour créer des branches, fusionner, pousser, obtenir et les arbres de journaux plus complexes . quelques scripts de base et je n'ai jamais été aussi productif en ce qui concerne le contrôle des sources et je n'ai jamais eu autant de contrôle sur ma source.
Bonne chance, j'espère que cela a aidé.
Je connais bien plusieurs modèles de branchement sophistiqués et j'en utilise certains au travail. Cependant, lorsque je travaille seul sur des projets, je fais à peu près exactement ce que vous faites maintenant. Je peux toujours créer une branche après coup si j'en ai besoin, mais je ne le fais presque jamais. Travaillant seul, j'ai rarement des corrections de bugs qui ne peuvent pas attendre la fin de ma tâche actuelle. Mon conseil est de vous familiariser avec certains modèles de branchement, mais cela n'a aucun sens de compliquer les choses jusqu'à ce que vous en ayez besoin.
Pour un modèle plus simple, vous pouvez regarder ce que fait GitHub. "GitHub flow" est très simple, et il y a un excellent guide ici: https://guides.github.com/introduction/flow/index.html
Résumé (extrait de blog de Scott Chacon ):
Alors, qu'est-ce que GitHub Flow?
- Tout dans la branche principale est déployable
- Pour travailler sur quelque chose de nouveau, créez une branche nommée de manière principale hors du maître (par exemple: new-oauth2-scopes)
- Validez cette branche localement et régulièrement Poussez votre travail vers la même branche nommée sur le serveur
- Lorsque vous avez besoin de commentaires ou d'aide, ou si vous pensez que la succursale est prête à fusionner, ouvrez une demande de tirage
- Une fois que quelqu'un d'autre a révisé et approuvé la fonctionnalité, vous pouvez la fusionner dans master
- Une fois fusionné et poussé vers "maître", vous pouvez et devez déployer immédiatement