Como desenvolvedor exclusivo (por enquanto), como devo usar o Git? [fechadas]


60

Eu tenho vários projetos no Git nos quais, eventualmente, quero atrair outras pessoas. No entanto, no momento, sou apenas eu e eu uso o Git e o GitHub de maneira muito simplista: sem ramificações e basicamente usando as confirmações como um backup dos meus arquivos locais. Às vezes, voltarei a olhar as versões anteriores dos meus arquivos para referência, mas não precisei fazer reversões a esse ponto, embora aprecie a opção que preciso no futuro.

Como desenvolvedor exclusivo, quais recursos do Git ou GitHub eu poderia aproveitar que me beneficiariam agora? Como deve ser meu fluxo de trabalho?

Além disso, existem práticas específicas que eu preciso começar a adotar antes de adicionar outras pessoas aos meus projetos no futuro?


3
Como outros explicaram, o Git oferece muito poder. Porém, como desenvolvedor exclusivo, o mais importante que você apreciará mais tarde é que, se você fornecer um registro de quais alterações você fez (agrupando alterações em vários arquivos em um conjunto), quando você as fez e por quê! Também é uma boa prática para quando você se torna parte de uma equipe.
Liderando Geek

11
Fechado porque interessante. :)

@ user93458 como sempre! Os tópicos fechados geralmente são exatamente o que estou procurando.
Miroslav Popov

excelente pergunta que nunca deveria ter sido encerrada.
volume um

Respostas:


64

Além disso, existem práticas específicas que eu preciso começar a adotar antes de adicionar outras pessoas aos meus projetos no futuro?

Claro. Há uma boa prática simples que você pode usar, mesmo que não tenha uma equipe no momento: crie uma ramificação separada para o desenvolvimento. A idéia é que a ramificação mestre contenha apenas versões de código liberadas ou alterações importantes. Isso pode ser adotado facilmente por novos desenvolvedores que ingressam no seu projeto.

Além disso, a ramificação é útil mesmo se você estiver trabalhando sozinho. Por exemplo, você encontra um erro no processo de codificação de um novo recurso. Se você não usar ramificações, precisará fazer as duas coisas: adicionar novos recursos e corrigir o bug na mesma ramificação. Isso não é bom: P Por outro lado, se você criou um novo ramo para criar seu novo recurso, basta fazer o checkout do ramo de desenvolvimento, corrigir o erro e devolver o novo ramo de recursos.

Este é apenas um breve exemplo do que você pode fazer sendo um único programador. Estou certo de que deve haver mais boas práticas.

Eu recomendo este artigo: Um modelo de ramificação Git bem-sucedido


+1 - Isso faz sentido. Também examinarei mais de perto esse artigo, que parece muito útil.
VirtuosiMedia 13/10

Não sou especialista em git, principalmente um usuário do Mercurial. Esse conselho do ramo de desenvolvimento ainda é válido no caso do Mercurial? Parece que sim, mas talvez algumas diferenças não tornem uma boa ideia neste caso?
Klaim

2
Sim, é válido para todo o controle de origem. Na verdade, eu faço isso de trás para frente com o SVN; o tronco "principal" é para o desenvolvimento mais recente, que ocorre diariamente ou com mais frequência. Quando uma liberação é solicitada, o código é congelado e um ramo é cortado. Essa ramificação recebe apenas pequenas atualizações para corrigir os principais problemas de versão e, em seguida, o distribuível é criado a partir disso. Dessa forma, tenho uma ramificação do código-fonte por trás de cada versão lançada. Isso é melhor do que simplesmente marcar ou rotular b / c se as confirmações aparecerem após a etiqueta, mas antes do lançamento, você não sabe se elas foram realmente excluídas.
Keiths

+1 para o artigo; @Klaim - sim, funciona muito bem para hg também. realmente deve ser chamado de "bem-sucedido modelo de ramificação DCV são"
Wyatt Barnett

+1 obrigado pelo link, mudou a maneira como vou trabalhar com o git, não muito para você, mas como se costuma dizer, tudo ajuda!
Newtopian

14

Estou exatamente nessa situação, mas optei por um fluxo de trabalho um pouco mais complexo, embora não necessariamente mais complicado, com o Git.

O objetivo, a princípio, era aprender o caminho do git, então eu explorei bastante. depois, revertida para praticamente o fluxo de trabalho que você descreveu.

Depois de um tempo, tornou-se difícil trabalhar com isso, pois algumas situações surgiram e me deram maus hábitos que seriam difíceis de romper quando eu ingressasse em uma equipe.

então decidi pelo seguinte:

  • Repositório local para trabalhar.
  • Ramo mestre como tronco estável para a aplicação
  • Uma ramificação para cada recurso / refator, basicamente uma ramificação para cada alteração considerável que será feita.
  • Volte ao tronco quando o ramo estiver estável e todos os testes forem aprovados.

Também configuro uma conta do git hub na qual sincronizo o tronco. Isso me permitiu começar a trabalhar facilmente em computadores diferentes. Foi por necessidade, mas me permitiu encontrar bugs vinculados ao ambiente em que eu estava e que não estava disponível nos outros computadores. Então agora eu tenho o hábito de tentar um projeto em um sistema "virgem" diferente pelo menos uma vez. Economiza muitas dores de cabeça quando chega a hora de implantar no cliente.

  • Eu codifico todas as versões que o fazem no github como uma versão liberável.
  • Se liberado para o cliente, vou ramificar a partir desta versão para criar um segundo tronco estável para correções de erros declaradas pelo cliente.

Os vários ramos a princípio pareciam um exagero, mas REALMENTE ajudou muito. Eu poderia começar uma idéia em um ramo, trabalhar nele por um tempo e, quando começo a correr círculos, desisti e comecei outro ramo para trabalhar em outra coisa. Mais tarde, surgiu uma idéia em que eu voltava ao ramo meio cozido e explorava essa idéia. isso me deixou muito mais produtivo, pois pude agir rapidamente com flashes e idéias e ver se funcionava. O custo da troca de ramificações com o GIT é extremamente baixo, tornando-me muito ágil com minha base de código. Dito isto, ainda tenho que dominar o conceito de rebase para limpar minha história, mas como estou sozinho, duvido que realmente precise. Empurrou como "bom aprender".

Quando toda a ramificação se tornou complicada, explorei a opção de log para desenhar uma árvore de alterações e ver qual ramificação estava onde.

Para encurtar a história, o git não é como SVN, CVS ou (brrr) TFS. Ramificar é muito barato e cometer erros que acabam com o trabalho é realmente muito difícil. Apenas uma vez eu perdi algum trabalho e foi porque fiz meus compromissos muito grandes (veja maus hábitos acima). Se você se comprometer com frequência, em pequenos pedaços, o git será definitivamente o seu melhor aliado.

Para mim, o git abriu minha mente para o que realmente é o controle de origem. Qualquer outra coisa antes era apenas uma tentativa de obtê-lo, o git é o primeiro, que em minha mente, o entendi. Dito isto, eu não tentei outros DVCS, muito possivelmente essa declaração poderia ser ampliada para toda a família.

Um último conselho, a linha de comando é seu amigo. Para não dizer que as ferramentas gráficas não são boas, muito pelo contrário, mas eu realmente gostei do git quando desci para a linha de comando e tentei fazer isso sozinho. Na verdade, é muito bem feito, fácil de seguir com um sistema de ajuda muito abrangente. Meu maior problema foi estar vinculado ao console feio do Windows até encontrar alternativas.

Agora eu uso os dois, a integração do Eclipse com o Git para ver o que está acontecendo em tempo real e fazer algumas operações como diffs, explorar o histórico de um arquivo etc. . alguns scripts básicos e nunca fui tão produtivo com relação ao controle de origem e nunca tive tanto controle sobre minha fonte.

Boa sorte, esperava que isso ajudasse.


4

Sou versado em vários modelos sofisticados de ramificação e uso alguns no trabalho. No entanto, quando trabalho sozinho em projetos, faço exatamente o que você está fazendo agora. Sempre posso criar um ramo depois do fato, se precisar de um, mas quase nunca preciso. Trabalhando sozinho, raramente tenho correções de erros que não podem esperar até que minha tarefa atual seja concluída. Meu conselho é estar familiarizado com alguns modelos de ramificação, mas não há sentido em complicar as coisas até que você precise.


4

Para um modelo mais simples, você pode ver o que o GitHub faz. O "fluxo do GitHub" é muito simples e há um excelente guia aqui: https://guides.github.com/introduction/flow/index.html

Resumo (do blog de Scott Chacon ):

Então, o que é o GitHub Flow?

  • Qualquer coisa na ramificação principal é implantável
  • Para trabalhar em algo novo, crie uma ramificação descritivamente nomeada fora do master (por exemplo: new-oauth2-scopes)
  • Confirme essa ramificação localmente e envie regularmente seu trabalho para a mesma ramificação nomeada no servidor
  • Quando você precisar de feedback ou ajuda, ou achar que a filial está pronta para a fusão, abra uma solicitação de recebimento
  • Depois que outra pessoa revisar e assinar o recurso, você poderá mesclá-lo ao mestre
  • Depois de mesclado e enviado para 'mestre', você pode e deve implantar imediatamente
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.