Flux de travail Git pour une petite équipe de développeurs et de concepteurs

Question

Je me perds avec le modèle de branchement Git et le flux de travail que je veux créer pour mon équipe (développeurs + concepteurs).

Supposons que le projet est basé sur un modèle MVC, nous avons donc une structure similaire à:

Modèles/
Contrôleurs/
Vues/

développeurs travaille sur les pièces M & C avec quelques vues basiques/générées (application Rails, Django ou CakePHP par exemple) et Designers travaux sur la partie V

Comment puis-je gérer que les développeurs travaille sur M & C et de garder des points de vue merdiques de base, et dans le même temps, les designers faire des vues sexy sur la base des actions contrôleurs codés et ajoutés par les développeurs progressivement?

J'ai essayé de faire cela fonctionne avec 3 branches:

maître (production-ready)
dev
ui

mais aucune idée comment un designer travaillant sur ui branche peut garder le code ailleurs que/views mis à jour une application de travail ...

Merci aux gens de l'aide!

Answer 1

Avec git, il n'y a aucune raison pour que les développeurs travaillent sur une branche séparée ou pour avoir des vues mockées. Les concepteurs et les développeurs travaillent-ils dans la même branche, sur la même base de code? Lorsqu'une vue est terminée (ou au moins améliorée et ne plante pas), demandez au concepteur de valider et de les transférer dans un référentiel maître. Il en va de même pour les développeurs: lorsqu'un changement local est «terminé», demandez-leur de le valider et de le pousser.

Avant de pousser, chaque côté doit tirer (pour s'assurer qu'il n'y a pas de conflits). Si les deux groupes travaillent dans des morceaux de code mutuellement exclusifs (des fichiers séparés ou même des parties séparées des mêmes fichiers), l'extraction mettra simplement à jour la copie locale et tout ira bien. Avec ceci, les deux côtés voient toujours la base de code la plus à jour, et contribuent directement à l'objectif final exact, en le regardant évoluer.

Answer 2

Git n'est pas magique. Il ne laisse pas vos concepteurs utiliser le code que les développeurs sont écrit activement. Les développeurs doivent encore écrire, tester et valider leur code, et le pousser à un endroit où les développeurs peuvent le tirer.

Généralement, vous disposez d'un référentiel «nu» dans lequel toutes les parties poussent leur travail lorsqu'elles sont prêtes à être partagées. Tout le monde tire ce travail vers le bas. Il est peut-être le travail des concepteurs de tirer le travail du développeur et de fusionner la branche dev dans la branche ui, par exemple:

git checkout ui 
git fetch 
git merge dev 

Answer 3

Git est si simple à utiliser, theres pas raison tout le monde ne devrait pas avoir leur propre branche au travail hors de.Enfer, c'est l'une des principales raisons d'utiliser un système de contrôle de version. Dans Git, les commits sont bon marché.

Généralement, nous avons un maître, et toute personne qui travaille sur les mises à jour ou les fonctionnalités se branche à partir du maître et branchez une branche si nécessaire, puis un maître de version (quelqu'un comme moi) se chargera de les fusionner vers le bas, en vérifiant les conflits, en testant la version et en revenant à master. Au fur et à mesure que vous y travaillez, d'autres personnes peuvent recevoir vos modifications en effectuant un va-et-vient contre votre branche pour intégrer les modifications.

Answer 4

Si vous voulez vraiment faire respecter des choses comme la branche et les droits de chemin, je vous extrayez gitolite

Cela vous permettra de gérer l'accès à toutes sortes de niveaux.