Quel est le flux de travail avec 2 personnes sur un projet

18

Je viens à vous en tant que programmeur débutant qui travaille sur son propre projet (qui progresse bien). Mon co-fondateur a également appris à programmer et a atteint un point où il pourrait probablement commencer à réparer certaines choses et à faire bouger les choses.

Il a posé une très bonne question, à savoir "comment cela fonctionnera-t-il". Quelque chose que je ne pouvais que théoriser car je n'avais jamais programmé avec quelqu'un d'autre. Pourriez-vous me conseiller sur le meilleur flux de travail. Nous utilisons git.

Devrions-nous posséder des parties spécifiques du système? Enregistrement du code? Examen du code?

Comment travaillez-vous avec> 1 dev?

Geoff Wright
la source
1
Mon meilleur indice est d'y jeter un œil: nvie.com/posts/a-successful-git-branching-model C'est une (bonne) façon d'organiser le code en équipe, et nous l'utilisons aussi
écrivez-vous des tests?
NARKOZ
... @ NARKOZ - pas encore. Nous avons un peu sauté le pas. C'est quelque chose que j'aimerais faire, j'ai juste acheté un livre en fait.
2
@Geoff Wright: veuillez entrer dans votre profil et accepter (appuyez sur le bouton coche à côté de) certaines des réponses que les gens ont si gracieusement fournies à vos questions: stackoverflow.com/users/661241/geoff-wright
iwasrobbed
1
Utilisez bitbucket.com pour les référentiels privés
Klevis Miho

Réponses:

23

Je travaille dans une équipe qui utilise git, où plus de 40 développeurs travaillent sur plusieurs référentiels de code (100+) à tout moment. Nous avons également commencé avec très peu de développeurs, augmentant la taille de l'équipe en quelques années. Au début, cependant, avec peu de gens, vous pouvez vous en tirer avec un minimum de conneries. Au fil du temps, vous améliorerez votre git fu et découvrirez de puissantes fonctionnalités.

  1. Vous aurez besoin d'un endroit pour héberger votre code. Pensez à utiliser github ou gitorious . Les deux sont gratuits, mais vos référentiels seront publics et visibles par les autres. Si vous souhaitez des référentiels privés, vous pouvez les héberger gratuitement sur github ou installer et héberger votre propre serveur gitorious .
  2. Au début, il est préférable de ne pas se soucier des workflows avancés qui impliquent des demandes de forking et pull. Vous pouvez commencer par utiliser git de manière centralisée (frémissement!). Traitez votre copie hébergée comme la copie faisant autorité de votre code source. Appelons ce référentiel upstream.
  3. L'un de vous valide tout le code dans un référentiel git local et le pousse vers ce upstreamréférentiel.
  4. L'autre membre de l'équipe peut cloner ce référentiel.
  5. Un ensemble de commandes minimum , vous aurez besoin d'apprendre sont clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Apprenez-en plus à leur sujet sur gittutorial .
  6. Chacun de vous peut désormais travailler sur n'importe quelle partie du code. Ne vous inquiétez pas de ce qui se passe lorsque vous modifiez tous les deux le même fichier. Git est vraiment bon pour gérer les fusions et résoudre les conflits.
  7. Faites de petits commits atomiques et écrivez de bons messages de journal . Utilisez le temps présent pour les journaux de validation. Vous pouvez effectuer autant de validations que vous le souhaitez sur votre copie locale car cela n'affecte pas le travail de l'autre personne.
  8. Lorsque vous pensez que votre code est prêt à être partagé avec d'autres personnes, publiez-le dans le upstreamréférentiel. Une bonne pratique consiste à toujours tirer avant de pousser . De cette façon, vous gardez votre référentiel synchronisé avec les autres modifications.
  9. Répétez les étapes 7et 8.

Une fois que vous êtes à l'aise avec ce flux de travail, vous pouvez passer à des choses plus avancées telles que - les branches d'actualité, les fourches, les demandes d'extraction, la fusion, le rebasage interactif des commits, etc.

Si vous voulez vraiment des revues de code, c'est faisable avec git et e-mail uniquement. Lorsque la taille de votre équipe dépasse 10+, cela se fait idéalement mieux avec une sorte d'outil en ligne. Donc, dans la pratique, il existe de nombreuses façons de le faire, et ce n'est qu'une façon simple:

  1. Créez un ensemble de validations à réviser git format-patch. Cela générera un ensemble de fichiers de correctifs. Envoyez ces correctifs par e-mail au réviseur.
  2. L'évaluateur peut appliquer les correctifs avec git apply. Cela applique le correctif mais ne crée pas de commit.
  3. Passez en revue le code et renvoyez-le avec des suggestions.
  4. Répétez 1-2-3 jusqu'à ce qu'il soit satisfaisant.
  5. L'évaluateur confirme que les correctifs peuvent être poussés upstream.
Ocaj Nires
la source
Je voudrais également ajouter git rebase à cette liste.
alock27
1
Je suis en désaccord qui stash, apply, format-patchfait partie du minimum de connaissances. J'attends habituellement quelques mois avant d'enseigner ces choses. Je suppose que> 50% des développeurs ne se cachent pas.
Michael Durrant
1
Appelez upstream originet cela vous aidera originà suivre d' autres exemples (qui utilisent normalement ).
Michael Durrant
2

J'utilise github et toutes ses fonctionnalités pour cela. consultez-le à http://www.github.com/ Ainsi, vous pouvez utiliser des branches, des fourchettes, des problèmes, des pull pulls pour travailler avec votre partenaire.

ben
la source
0

La première chose que je ferais serait d'examiner un référentiel de code central afin que les modifications puissent être fusionnées et synchronisées entre vos deux projets. SVN est un bon facile que je l' ai utilisé dans le passé et il a été assez longtemps qu'il est assez mûr SVN .

Après cela, je voudrais identifier entre vous deux les rôles que vous allez jouer, c'est-à-dire

  1. Allez-vous écrire la fonctionnalité du code en tandom ou une personne va-t-elle faire des corrections de bugs tandis que l'autre continue avec des fonctionnalités.
  2. Voulez-vous créer un ensemble de normes de codage de base, c'est-à-dire la position de l'accolade, la dénomination des variables de membre privé, la convention de dénomination des variables et des méthodes (CamelCase, etc.)
  3. À quelle fréquence devez-vous vous enregistrer. Je suggérerais au moins une fois par jour pour vous assurer que vous voyez tous les deux ce que fait l'autre, surtout au début. Bien que assurez-vous toujours avant un archivage, le code est à construire.
  4. Il est le patron, mais allez-vous être le responsable de la programmation?

Bonne chance!

dreza
la source
1
SVN est une option décente (et je l'utilise actuellement au travail) ... mais Git et Hg m'ont semblé être un peu mieux car je peux m'engager localement (et revenir quand j'ai fait quelque chose de stupide) sans forcer les autres à traiter (s'ils mettent à jour svn) avec mon code qui peut ne pas fonctionner. Honnêtement, j'ai commencé à utiliser Git au bureau pour cette raison, mais je peux toujours publier mes modifications dans SVN en utilisant git-svn
Ken Henderson