GIt dev et de la production - où dois-je créer le repos?

Question

J'ai lu quelque part* une installation comme ce serait sympa:

Deux branches principales, une pour chaque serveur.

En poussant à maître envoie les modifications à vivre;

Poussant à l'dev/scène (ou ce que vous appelez) envoie les modifications apportées à la mise en scène;

Flux de travail:

• Création d'une branche de dev;

• travail à l'échelle locale jusqu'à ce que vous êtes prêt à tester;

• fusion de retour à dev;

• pousser sur le Hub, qui envoie les modifications apportées à dev/serveur intermédiaire.

Une fois que vous êtes prêt à aller vivre:

• fusion de dev pour maître,

• puis poussez le maître de Hub, qui envoie ces modifications sur le serveur live.

Deux branches principales, une pour chaque serveur.

J'ai donc une branche "production" sur "webroot/myliveapp/" et une autre branche "développement" sur "webroot/devapp/"

Où les ai sont ?

Mise à JOUR:

Je veux dire:

Nous aurons, en fonction de ce flux:

• Le premier pensions;

• Nu pensions de hub;

• Les Clones;

Le développement et la production des branches appartiennent à un référentiel, à droite ?

Si cela est correct, puis ont été devrions-nous le problème de la PREMIÈRE commande git init ?Sur notre Premier repo ?

Donc, nous aurons:

"webroot/myliveapp/" - branche de production;

"webroot/devapp/" - la direction du développement;

"webroot/.git" - le Premier dépôt;

Est-il logique ?

Ou doit faire le Premier référentiel correspondent à notre branche de la production de l'endroit ?

*Remarque:si vous avez besoin d'un contexte à propos de ce flux de travail, je suis en train de mettre en œuvre, est celui-ci:http://joemaller.com/990/a-web-focused-git-workflow/

Answer 1

Merci pour la mise à jour sur votre question, c'est plus clair maintenant.

Je crois que le problème que vous rencontrez est basé sur une incompréhension de workflow Git;Git n'est pas synonyme répertoires pour les branches, il équivaut à un vue de votre système de fichiers pour les branches.C'est puissant mais facile à tirer dans le pied.Laissez-moi vous expliquer.

Git agit plus comme une base de données de sauvegarde différentielle-versionnées, histoire de suivi du système de fichiers lui-même.Il est "au-dessus" de votre système de fichiers, pas de "partie de" il.Il n'utilisez pas votre système de fichiers pour représenter les branches, plutôt, lorsque vous découvrez une autre branche, tous les fichiers dans votre système de fichiers va changer pour être les fichiers dans cette branche.Vous vous demandez Git pour faire de votre système de fichiers représenter la réalité alternative de la direction.

Si vous êtes sur la branche master, et il a un fichier root/foo.txt commis, et vous découvrez la branche experiment, qui n' pas ont root/foo.txt engagé, vous trouverez ce fichier disparu quand vous regardez pour cela.C'est une partie de master, pas experiment, et donc, il n'est pas présent dans votre système de fichiers.C'est pourquoi Git est vraiment pointilleux à propos de votre branche commis avant qu'il vous permet de passer les branches - si vous avez unstaged modifications sur votre système de fichiers que Git ne connaissent pas, il refuse de disparaitre en les écrasant avec une réalité différente.Vous avez à intervenir pour faire les choses d'abord.

Donc, pour répondre à la quesiton de ne pas créer des sous-répertoires pour "myliveapp" et "devapp" - créer différents les branches.Juste avoir votre une base de code en vertu de la "racine".Ensuite, bidouiller sur, disons, le "instable" de la branche, de commettre vos modifications comme d'habitude.Vous pouvez ensuite basculer tous les fichiers dans votre référentiel d'être à la version de votre serveur de dev de fichiers par le passage à la "devapp" de la branche, et vous pouvez même revenir à "instable" à tout moment.

Lorsque vous souhaitez mettre à jour une branche, par exemplefaire une mise à jour de votre serveur de dev, vous pouvez merge "instable" dans "devapp".Cela rendra tous les fichiers de "devapp" ressemblent à celles de "instable", de le mettre à jour.

Une autre chose à noter:la différence entre un premier dépôt, un nu pensions, et des clones est presque nulle.Il n'y a pratiquement pas de différence dans le logiciel;c'est plutôt un homme de la convention-à-dire "Linus noyau qui est la forme canonique du noyau Linux".Avec cette compréhension:

• Un premier repo est juste un référentiel que tout le monde est d'accord détient le "canonique" de la version du logiciel.C'est, à chaque fois qu'un développeur a apporté un changement, ils veulent tout le monde à voir, plutôt que de dire, "Tirer ma version de devapp", on peut dire, "je n'ai pas publié mes modifications à notre premier repo." C'est tout simplement une simple convention pour les gens à se rallier autour d'.
• Un clone est une copie de quelques autres pensions.J'ai pu cloner le premier pensions, de faire des changements, et puis vous pouvez cloner mon repo.Si vous apportez des modifications, vous pouvez appuyer soit sur le premier repo ou sur le mien, tant que la fusion est valide et que vous disposez des autorisations sur l'ordinateur.
• Un nu-pensions n'a tout simplement pas de "copie de travail" - il n'y a pas de "racine" répertoire sur l'ordinateur.Elle est vide avec seulement l' .git l'annuaire, ce qui est bien pour les serveurs où personne n'a besoin de modifier les fichiers.

Enfin, l' .git dir ne pas mettre les fichiers de votre pension, il détient le git de configuration et la base de données.C'est l'ensemble de votre référentiel de l'histoire dans la base de données de la forme, qui est utilisé pour remplir le reste de l'opération avec une version spécifique de votre logiciel.C'est pourquoi j'ai fait le commentaire:vous pouvez localement découvrez une version de toute autre réalité du référentiel, avec aucun réseau de communication, à tout moment, parce que c'est tous là dans le .git dir.Le seul réseau de communication est nécessaire pour quand vous voulez synchronisation votre dépôt local à un autre référentiel, à l'aide de push ou pull.