J'essaie de trouver un flux de travail personnel. J'ai mis en place un organigramme de la durée de vie hypothétique d'une version: un développeur poussant vers un référentiel github public + un ami aidant avec certaines fonctionnalités et corrigeant un bug.
Est-ce une approche raisonnable du contrôle de version?
L'idée principale est de garder le repo bien rangé:
Chaque nouvelle version obtient sa propre branche jusqu'à ce qu'elle soit finalement balisée dans la branche principale lorsqu'elle est terminée.
Tout le travail est effectué sur les branches "fonctionnalité" ou "hotfix", jamais sur une branche de version réelle, pour éviter les anomalies.
Les fusions vers les branches de niveau supérieur sont toujours rebasées ou écrasées (pour éviter l'encombrement).
Si c'est exagéré, cela ne me dérange pas parce que le but est pour moi d'apprendre les compétences dont j'ai besoin pour un projet plus vaste. Le seul problème serait que je fasse quelque chose de mal ou de inutile.
édition 2: correction d'une mauvaise idée dans l'organigramme d'origine et facilité la navigation.
la source
--squasherreur et ajouté une grille pour la rendre plus facile à suivre.Réponses:
Ce que je vois beaucoup dans la communauté git / github, c'est ceci
master branches développer
Vous et les contributeurs travaillez principalement dans le développement, mais quelqu'un peut avoir une idée ou une nouvelle fonctionnalité, vous créez donc une branche de sujet comme git checkout -b user_comments.
Ensuite, au fur et à mesure que vous progressez dans le développement, vous poussez pour maîtriser une fois que vous avez défini une version qui vous convient et la marquez dans la branche principale comme 1.0 ou 1.1.2, etc. (recherchez le versioning sémantique)
la source