Qual é o fluxo de trabalho com 2 pessoas em um projeto


18

Venho a você como um programador iniciante que está trabalhando em seu próprio projeto (que está progredindo bem). Meu co-fundador também aprendeu a programar e chegou a um ponto em que provavelmente poderia começar a consertar algumas coisas e fazer acontecer.

Ele fez uma pergunta muito boa, que era "como isso funcionará". Algo sobre o qual eu só pude teorizar como nunca havia programado com outra pessoa. Você poderia me aconselhar sobre o melhor fluxo de trabalho. Nós usamos git.

Devemos possuir partes específicas do sistema? Verificando código? Revisão de código?

Como você trabalha com> 1 desenvolvedor?


1
Minha melhor dica é dar uma olhada nisso: nvie.com/posts/a-successful-git-branching-model É uma (boa) maneira de organizar o código em equipe, e nós o usamos também

você escreve testes?
NARKOZ

... @ NARKOZ - ainda não. Nós meio que pulamos direto. É algo que eu gostaria de fazer, acabei de comprar um livro.

2
@Geoff Wright: Entre no seu perfil e aceite (clique no botão de seleção ao lado de) algumas das respostas que as pessoas forneceram tão graciosamente às suas perguntas: stackoverflow.com/users/661241/geoff-wright
iwasrobbed

1
Use bitbucket.com para repositórios privados
Klevis Miho 6/15

Respostas:


23

Eu trabalho em uma equipe que usa git, onde mais de 40 desenvolvedores estão trabalhando em vários repositórios de código (mais de 100) em qualquer ponto do tempo. Também começamos com muito poucos desenvolvedores, aumentando o tamanho da equipe em alguns anos. No começo, porém, com poucas pessoas, você pode se dar ao luxo de conhecer apenas um mínimo de git. Com o tempo, você aprimorará seu git fu, descobrindo recursos poderosos.

  1. Você precisará de um local para hospedar seu código. Considere usar github ou gitorious . Ambos são gratuitos, mas seus repositórios serão públicos e visíveis para outros. Se você deseja repositórios particulares, você pode hospedá-los gratuitamente no github ou instalar e hospedar seu próprio servidor monitorado .
  2. No começo, é melhor não se preocupar com fluxos de trabalho avançados que envolvem solicitações de bifurcação e recebimento. Você pode começar usando o git de maneira centralizada (estremecer!). Trate sua cópia hospedada como a cópia autorizada do seu código-fonte. Vamos chamar esse repositórioupstream .
  3. Um de vocês compromete todo o código em um repositório git local e o envia para este upstream repositório.
  4. O outro membro da equipe pode clonar este repositório.
  5. Um conjunto de comandos mínimos que você precisa aprender são clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Saiba mais sobre eles no gittutorial .
  6. Agora você pode trabalhar em qualquer parte do código. Não se preocupe com o que acontece quando os dois editam o mesmo arquivo. O Git é realmente bom em lidar com fusões e corrigir conflitos.
  7. Faça pequenas confirmações atômicas e escreva boas mensagens de log . Use o tempo presente para logs de confirmação. Você pode fazer qualquer número de confirmações conforme desejar na sua cópia local, pois isso não afeta o trabalho da outra pessoa.
  8. Quando você achar que seu código está pronto para ser compartilhado com outras pessoas, publique-o no upstreamrepositório. Uma boa prática é sempre puxar antes de empurrar . Dessa forma, você mantém seu repositório sincronizado com outras alterações.
  9. Repita as etapas 7e 8.

Quando estiver confortável com esse fluxo de trabalho, você poderá progredir para itens mais avançados, como - ramificações tópicas, bifurcação, solicitações de recebimento, mesclagem, reestruturação interativa de confirmações etc.

Se você realmente deseja revisões de código, é possível apenas com git e email. Quando o tamanho da sua equipe cresce acima de 10 ou mais, isso é idealmente melhor com algum tipo de ferramenta on-line. Portanto, na prática, existem muitas maneiras de fazer isso, e esta é apenas uma maneira simples:

  1. Crie um conjunto de confirmações a serem revisadas com git format-patch . Isso irá gerar um conjunto de arquivos de patch. Envie esses patches por e-mail para o revisor.
  2. O revisor pode aplicar os patches com git apply . Isso aplica o patch, mas não cria uma confirmação.
  3. Revise o código e envie um e-mail com sugestões.
  4. Repita 1-2-3 até satisfatório.
  5. O revisor confirma que os patches podem ser enviados upstream.

Eu também gostaria de adicionar o git rebase a esta lista.
alock27

1
Discordo que stash, apply, format-patchfazem parte do conhecimento mínimo. Normalmente, espero alguns meses antes de ensinar essas coisas. Eu acho que> 50% dos desenvolvedores não escondem.
precisa saber é o seguinte

1
Ligue upstream origine ajudará a tornar originmais fácil seguir outros exemplos (que normalmente são usados ).
precisa

2

Eu uso o github e toda a sua funcionalidade para isso. confira em http://www.github.com/ Para que você possa usar ramificações, garfos, problemas, receber solicitações para trabalhar com seu parceiro.


0

A primeira coisa que eu faria é procurar em um repositório de código central para que as alterações possam ser mescladas e mantidas em sincronia entre seus dois projetos. O SVN é um fácil fácil que eu usei no passado e já existe há tempo suficiente para ser um SVN bastante maduro .

Depois disso, eu identifico entre vocês os papéis que vocês dois vão desempenhar, isto é,

  1. Você irá escrever a funcionalidade do código no tandom ou uma pessoa fará correções de erros enquanto a outra continua com os recursos.
  2. Deseja criar um conjunto de padrões básicos de codificação, como posição de chave, nomeação de variável de membro privado, convenção de nomeação de variável e método (CamelCase etc.)
  3. Quantas vezes você precisa fazer o check-in. Sugiro pelo menos uma vez por dia para garantir que vocês estejam vendo o que o outro está fazendo, especialmente desde o início. Embora sempre garanta antes de um check-in, o código é compilável.
  4. Ele é o chefe, mas você será o líder de programação?

Boa sorte!


1
O SVN é uma opção decente (e atualmente estou usando no trabalho) ... mas Git e Hg são um pouco melhores, pois posso me comprometer localmente (e reverter quando fiz algo estúpido) sem forçar os outros a lidar (se eles svn atualizar) com o meu código que pode não funcionar. Honestamente eu comecei a usar Git no escritório por esta razão, mas eu ainda posso publicar minhas alterações de volta para SVN usando git-svn
Ken Henderson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.