Prochaines étapes avec Git: Établir un flux de travail cohérent

Question

Je suis nouveau à Git et le contrôle de version distribué, mais j'ai réussi, sans beaucoup trébucher, init ma propre source locale, configurer un dépôt distant privé (origine) via SSH sur mon propre hôte Web, et faire la base pull et push de maître à l'origine. (Je teste même un clone!)

Je pense que j'ai le flux de travail git à sens unique sous contrôle. Maintenant, cependant, je commence à réfléchir à la façon dont je gère les choses en mouvement entre le développement, la version bêta et la production. La plupart des tutoriels que j'ai trouvé parlent de différents utilisateurs fusionnant et clonant et tirant et poussant, mais dans mon cas, c'est juste moi, manipulant des choses de différentes sources. J'espère qu'un utilisateur git expérimenté pourrait donner un aperçu de mon flux de travail et fournir quelques suggestions sur la façon dont ils géreraient la fusion, les branches, etc (choses que je ne suis pas trop familier/confortable avec, pour le moment).

Voici les différentes machines/endroits que je devrai:

1. magasin git principale à distance: ssh: //git@example.com/git/myproject.git
2. Serveur web, le développement principal boîte (où je suis assis, en privé, et faire la plupart des travaux)
3. serveur web à distance, les tests bêta (public face): http://beta.example.com (test mon travail dev avant la production)
4. serveur Web distant, site de production: http://example.com (où de vraies personnes, espérons-le, utilisent le site)
5. (occasionnellement) se déplacer sur un ordinateur portable (exécutant son propre serveur Web local).

Comment gérez-vous cela? Merci d'avance.

Answer 1

Je ne vois pas l'intérêt de créer un flux de travail trop compliqué ici, une configuration "centrale" fera très bien à mon humble avis. Donc vous avez une télécommande principale qui devrait être votre point central qui détient tout le développement, nom à distance "origine". vous travaillez sur votre boîte de développement, faites vos engagements et de temps en temps vous poussez vos trucs à "origine". Une fois que vous pensez qu'il est temps pour une version de marquer votre matériel (probablement en version bêta), de le pousser à l'origine, d'aller à votre serveur bêta et de tirer cette étiquette à partir de là pour les tests publics. répétez jusqu'à ce que vous ayez une version que vous pouvez tirer sur votre machine de production ...

en ce qui concerne votre question A/B (probablement votre machine de Devel et votre ordinateur portable): bien sûr, cela peut être fait, mais pas en poussant simplement vos changements de A ou B dans l'origine. Supposons que vous venez de pousser votre travail sur la machine A vers "origine", appelons cet état "17". Maintenant, votre travail plus loin, créant des états locaux "18" à "20". Si "origine" est toujours à "17" vous pouvez pousser vos changements 18-20 à l'origine sans problèmes car chaque étape est un descendant direct de l'état précédent. C'est ce qu'on appelle un "avance rapide" dans git.

Cependant, si un appui de B intervient entre les deux, alors la ligne des "descendants directs" est cassée, et une poussée de A échouerait.La solution est simple, si: A doit tirer d'origine, la fusion de toutes les modifications introduites par B en A, puis il peut pousser ...

espoir qui clarifie les choses ..

Answer 2

Si vous travaillez par vous-même, vous n'avez pas vraiment besoin de fusionner ou de fusionner si vous ne le souhaitez pas. Git rend simplement cela un peu plus facile que d'autres systèmes de contrôle de version, donc vous pouvez utiliser des branches de la même façon que vous pourriez utiliser des tags ailleurs. Je recommande fortement le livre d'O'Reilly sur le sujet - c'est plutôt bien écrit.

Answer 3

Oui, il peut gérer un changement de A, un autre de B, ayant tous deux poussé. Cependant, l'un des deux devra tirer d'origine avant de pouvoir pousser. Parce que l'un des deux serait "périmé" avec l'origine, parce que l'autre avait poussé à l'origine.