En tant que développeur unique (pour le moment), comment devrais-je utiliser Git? [fermé]

J'ai plusieurs projets sur Git dans lesquels je veux éventuellement amener d'autres personnes. Cependant, pour l’instant, c’est juste moi et j’utilise Git et GitHub de façon très simpliste: pas de branches et, fondamentalement, je n’utilise que 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 jusqu'à maintenant, bien que j'apprécie l'option si j'en avais besoin à l'avenir.

En tant que développeur unique, quelles fonctionnalités Git ou GitHub puis-je utiliser pour en tirer profit? À 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’ajouter d’autres projets à mes projets à l’avenir?

De plus, y a-t-il des pratiques particulières que je dois commencer à faire en prévision d’ajouter d’autres projets à 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éez 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 modifications majeures. Cela peut être facilement adopté par les nouveaux développeurs qui rejoignent votre projet.

En outre, la création de branches 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: ajoutez de nouvelles fonctionnalités et corrigez le bogue dans la même branche. Cela n’est pas bon: P En revanche, 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 récupérer la nouvelle branche.

Ceci est juste un bref exemple de ce que vous pouvez faire en tant que programmeur unique. Je suis sûr qu'il doit y avoir plus de bonnes pratiques.

Je vous recommande vivement cet article: Un modèle de branchement Git réussi

Je suis exactement dans cette situation, mais j’ai opté pour un flux de travail légèrement plus complexe bien que pas nécessairement plus compliqué avec Git.

Au début, l’objectif était d’apprendre les techniques de git, alors j’ai exploré un peu. est ensuite revenu à peu près au flux de travail que vous avez décrit.

Après un moment, il devint difficile de travailler avec, certaines situations apparaissant, cela me donna de mauvaises habitudes qu'il serait difficile de rompre une fois que je rejoindrais une équipe.

alors je me suis installé pour ce qui suit:

• Dépôt local pour travailler.
• Branche principale en tant que coffre stable pour l'application
• Une branche pour chaque entité / refactor, en gros une branche pour chaque changement important qui sera effectué.
• Fusionner vers le tronc lorsque la branche est stable et que tous les tests réussissent.

J'ai également configuré un compte hub Git sur lequel je synchronise le trunk. 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 un projet sur un autre système "vierge" au moins une fois. Me épargne beaucoup de maux de tête quand vient le temps de déployer chez le client.

• Je balise toutes les versions qui en font github en tant que version amovible.
• Si cette version est communiquée au client, je créerai une deuxième ligne de distribution stable pour les corrections de bogues déclarées par le client.

Au début, les multiples succursales semblaient excessives, mais cela a VRAIMENT beaucoup aidé. Je pouvais commencer une idée dans une branche, travailler dessus pendant un moment et quand je commence à exécuter des cercles, j'ai abandonné et j'ai démarré une autre branche pour travailler sur autre chose. Plus tard, une idée est venue où je revenais à la branche à moitié cuite et explorais cette idée. Cela m'a rendu BEAUCOUP plus productif, car je pouvais agir très rapidement 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 mon code base. Cela dit, je dois encore maîtriser le concept de rebase pour nettoyer mon histoire, mais comme je suis toute seule, je doute que j'en ai vraiment besoin. Poussé comme "agréable à apprendre".

Lorsque toutes les branches sont devenues compliquées, j'ai exploré l'option de journalisation pour dessiner une arborescence de modifications et voir quelles branches se trouvaient où.

En bref, git n’est pas comme SVN, CVS ou (brrr) TFS. Le branchement est très bon marché et il est en fait assez difficile de faire des erreurs qui effaceront le travail. Une seule fois, j’ai perdu du travail et c’est parce que j’ai fait mes commits trop gros (voir mauvaises habitudes ci-dessus). Si vous vous engagez souvent, par petits morceaux, Git sera définitivement votre meilleur allié.

Pour moi, il m'a ouvert l'esprit sur le contrôle des sources. N'importe quoi d'autre avant consistait simplement à tenter de l'obtenir, git est le premier qui, dans mon esprit, l'a obtenu. Cela dit, je n’ai pas essayé d’autres DVCS, il est fort possible que cette déclaration puisse être élargie à toute la famille.

Un dernier conseil, la ligne de commande est votre ami. Cela ne veut pas dire que les outils graphiques ne sont pas bons, bien au contraire, mais j’ai vraiment moqué quand je suis passé en ligne de commande et que j’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 de rester lié à la console laide mais moche de Windows jusqu'à ce que je trouve des alternatives.

Maintenant, j’utilise l’intégration d’Eclipse avec Git pour voir ce qui se passe en temps réel et effectuer des opérations telles que diffs, explorer l’histoire d’un fichier, etc. . certains scripts de base et je n'ai jamais été aussi productif en ce qui concerne le contrôle de source et je n'ai jamais eu autant de contrôle sur ma source.

Bonne chance, espéré 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 se familiariser avec certains modèles de branchement, mais il est inutile de compliquer les choses tant que vous n'en avez pas besoin

Pour un modèle plus simple, vous pouvez regarder ce que fait GitHub. "GitHub flow" est très simple, et voici un excellent guide: https://guides.github.com/introduction/flow/index.html

Résumé (du blog de Scott Chacon ):

Alors, quel est GitHub Flow?

• Tout ce qui se trouve dans la branche principale est déployable
• Pour travailler sur quelque chose de nouveau, créez une branche nommée de façon descriptive à partir du maître (par exemple: new-oauth2-scopes)
• S'engager sur cette branche localement et pousser régulièrement votre travail sur la même branche nommée sur le serveur
• Lorsque vous avez besoin de commentaires ou d'aide, ou que vous pensez que la branche est prête pour la fusion, ouvrez une demande d'extraction.
• Une fois la fonctionnalité vérifiée et validée par une autre personne, vous pouvez la fusionner en une version principale.
• Une fois qu'il est fusionné et poussé à «maîtriser», vous pouvez et devez déployer immédiatement