Meilleure pratique de workflow avec git et github?

Question

J'utilise git et github avec ma petite équipe de développeurs pour nos projets. Je ne peux pas m'empêcher de penser que nous ne le faisons pas correctement. Je suis intéressé d'entendre comment d'autres personnes utilisent ce flux de travail dans leurs projets.

Comment nous l'utilisons: Nous brancheons avant chaque modification, nous fusionnons dans le maître, nous commettons localement et nous poussons dans notre dépôt github. Ensuite, nous ssh dans notre environnement de test et tirons la branche master du dépôt github. rebase , fetch ou balisage ne sont pas encore très bien compris.

Comment je voudrais l'utiliser: J'aimerais pouvoir utiliser ssh sur les différents serveurs et en extraire une version marquée spécifique, telle que "phase 1". dans le serveur. Est-ce possible ou aurais-je besoin de deux dépôts de github différents?

Êtes-vous censé git extraire une branche spécifique dans les serveurs Web ou créer un nouvel alias vers git push ?

Pouvez-vous contrôler les versions candidates ou les environnements (test, développement, production) dans un référentiel git? ou avez-vous besoin de plusieurs?

Si le tirage est la solution, pouvez-vous extraire une balise spécifique ?

Answer 1

En gros, vous pouvez très bien utiliser un seul "central". Référentiel GitHub.

• Les balises étant des pointeurs immuables, elles peuvent être utilisées (et poussées) à tout moment, afin d’être extraites de tout environnement de test ou de production. Cela permet une certaine validation mais ne sert généralement pas au développement.
• Le fait de tirer une branche signifie que vous pouvez apporter des modifications au sein de cette branche (en raison de corrections de bugs et d’ajustements à effectuer une fois le code en production) et de le repousser pour que tous les autres référentiels du développeur puissent les récupérer et les récupérer. en compte.

Tout dépend donc de ce que vous faites sur ces serveurs: uniquement la validation (avec un statut accepté ou rejeté) ou également des développements ultérieurs.
Dans tous les cas, une balise avec une convention de dénomination appropriée permet de garder une trace des commits spécifiques dans l'historique, mais des branches sont nécessaires à chaque fois que vous devez isoler un effort de développement.

Answer 2

Lisez le livre Pro Git . Vous pouvez lire des pages de manuel git pendant un an sans le comprendre: essayer d'apprendre git en lisant des pages de manuel, c'est comme essayer d'apprendre une nouvelle langue en lisant un dictionnaire, cela peut être fait. Le livre vous apprendra une poignée de flux de travaux que vous pouvez avoir avec git, ainsi que les commandes à utiliser et dans quel contexte les utiliser.

Answer 3

Sur GitHub, j’utilise un seul compte pour mon entreprise, où se trouve le compte "bienheureux". le code vit; Je garde ensuite une fourchette personnelle, où je travaille sur des choses qui ne sont pas encore stables. Sur ma machine locale, je gère les deux dans un même dépôt, de sorte que le code maître soit le code béni (et le compte client de la société), tandis que toutes les autres branches sont destinées à ma branche. Voici une partie de mon .git / config:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:xiongchiamiov/fourU.git
[branch "hacking"]
        remote = origin
        merge = refs/heads/hacking
[branch "editor"]
        remote = origin
        merge = refs/heads/editor
[branch "problem-utils"]
        remote = origin
        merge = refs/heads/problem-utils
[branch "tests"]
        remote = origin
        merge = refs/heads/tests

[remote "trunk"]
        fetch = +refs/heads/*:refs/remotes/trunk/*
        url = git@github.com:xyztextbooks/fourU.git
[branch "master"]
        remote = trunk
        merge = refs/heads/master

Étant donné que je dispose d'autorisations de validation pour le dépôt de la société, je peux simplement fusionner (ou effectuer une sélection sélective) des validations d'une branche à une autre et les transférer à l'emplacement approprié. Maintenant, des dépôts séparés ne sont certainement pas nécessaires, mais comme il s’agit d’un projet à source ouverte, j’aime bien garder le mot "officiel". repo libre de branches aléatoires créées par mes tangentes. Une fois qu'il aura atteint le point de versioning, il y aura une branche 0.x, avec des balises pour chaque version (0.1, 0.1.1, 0.2, etc.), ce qui est particulièrement avantageux car github crée automatiquement des archives des fichiers. à chaque balise, ce qui est bien adapté pour transférer une version spécifique sur une machine qui n’a pas besoin de l’historique complet.

Vous devriez lire le blog github; ils ont eu quelques bons articles décrivant leur flux de travail de déploiement, ce qui implique bien sûr fortement git.