2016-06-15 2 views
0

Donc, cela fait partie d'un projet de planification beaucoup plus important sur lequel je travaille ... Je ne suis pas sûr que le contexte aiderait à répondre à cette question.Utiliser le tag Git comme version vérifiée pour la production

Je suis un peu nouveau à Git - utilisé depuis environ 5 mois - J'ai aussi de l'expérience avec SVN. Ma question est: Serait-il une mauvaise pratique d'utiliser un tag Git pour la production?

Par exemple, disons que la vie de production dans/var/www/live ... Je considère ce qui suit dans le cadre d'un plan de déploiement:

  • branche de sortie se transforme en maître maître
  • est tiré sur un serveur aperçu
  • une fois approuvé, un feu de processus pour faire une étiquette de cette version, accédez à l'emplacement de la production, et de vérifier cette étiquette

convient de garder à l'esprit que j'apprends aussi comment nous pourrions appliquer Git Flow, et nous utilisons Bamboo pour le déploiement (que je n'ai jamais utilisé), donc tout est assez désordonné en ce moment. Merci!

Répondre

0

Ceci est une très bonne pratique. Je pense que c'est le but pour lequel les balises ont été envisagées. De cette façon, il n'y a jamais de confusion sur le code qui est à la pointe de la branche "production" éphémère. Il y a une distinction cimentée à propos de l'état du référentiel et de ses fichiers.

Même Github lie les étiquettes à releases.

0

Je pense que vous êtes sur la bonne voie, et ceci est une utilisation parfaitement valide pour un Tag sur git. Puisque vous avez mentionné Gitflow, votre modèle de branchement envisagé deviendrait un peu plus mature, séparant les branches de développement des branches release et master, ayant un moyen rapide de se ramifier et de fusionner les hotfixes et d'utiliser des balises pour chaque fusion sur master (ce qui serait toujours une nouvelle version de prod). Plan Bamboo peut marquer ces commits automatiquement, btw.