Como contribuo para o código de outras pessoas no GitHub? [fechadas]


231

Eu gostaria de contribuir para um determinado projeto no GitHub . Devo bifurcar ? Ramificá- lo? O que é recomendado e como fazê-lo?


61
Outra perto ridículo
Stephen

4
Eu escrevi um guia passo a passo mais detalhado sobre como contribuir para o Concrete5 no Github, mas o processo pode se aplicar a qualquer projeto. Confira .
21814 Joe Meyer

7
Realmente não vejo como isso 'não é construtivo'. Somente os votos e opiniões fornecem prova de que é uma pergunta popular que as pessoas desejam ter respondido.
19414 Ian


1
talvez com votação por maioria suficiente, permita que as perguntas previamente fechadas sejam ressuscitadas novamente e permita que as pessoas contribuam para o tópico novamente.
Peter Teoh

Respostas:


180

Idealmente você:

  1. Bifurcar o projeto
  2. Faça uma ou mais confirmações bem comentadas e limpas no repositório. Você pode criar uma nova ramificação aqui se estiver modificando mais de uma parte ou recurso.
  3. Execute uma solicitação pull na interface da web do github.

se for uma nova solicitação de recurso, não inicie a codificação primeiro. Lembre-se de postar um problema para discutir o novo recurso.

Se o recurso for bem discutido e houver +1 ou o proprietário do projeto o aprovou, atribua o problema a si mesmo e siga as etapas acima.

Alguns projetos não usam o sistema de solicitação de recebimento. Verifique com o autor ou a lista de discussão a melhor maneira de recuperar seu código no projeto.


4
Detalhes sobre a bifurcação do GitHub e solicitações de
recebimento

1
Sim, solicite pull. A solicitação de mesclagem é uma terminologia vitoriosa.
Yann Ramin

2
@MariusKavansky é o contrário! Depois de saber o que trabalhar, então você só contribuem :)
hashbrown

depois que eu contribuí para algum projeto de código aberto. Eu acho que é uma idéia melhor abrir um problema para discutir o novo recurso, se for um novo recurso. Se um recurso ou problema é bem discutido, você deve atribuir o problema a si mesmo e siga as etapas acima. Este é o meu 2 centavos.
Wizztjh 14/01/2015

@hashbrown, ele está perguntando onde está a "lista" de recursos solicitados até o momento. Os recursos que já estão sendo solicitados e marcados com +1.
Pacerier

31

Para adicionar à resposta de Yann , depois de criar um projeto, você pode desenvolver em qualquer ramo que desejar (um novo ou um do projeto original)

Lembrar de:


1
você pode adicionar detalhes ou links no seu segundo ponto (ramificação rebasing) ?
JorgeArtware

1
@JorgeArtware Atualizei a resposta com alguns links que ilustram a recuperação.
VonC

@VonC Faço uma pergunta aqui, mas se você acha que é necessário, farei uma pergunta totalmente nova. Por que eu iria me refazer em vez de mesclar, além de ter a 'história direta'? Em outras palavras, eis o que faço quando contribuo para alguns projetos (depois que o PR do meu ramo de recursos foi mesclado para desenvolver e dominar ramos): o git checkout master; git pull;mesmo para o desenvolvimento (onde meu ramo de recursos foi mesclado primeiro) A diferença que posso pensar depois de ler "pull vs pull --rebase" e "merge vs rebase" é apenas o histórico plano. Mais alguma coisa mais profunda?
Linuxbandit 24/03

@grasshopper em termos de "contribuição" (o contexto desta página), você sempre deseja refazer suas confirmações locais sobre as ramificações atualizadas antes de pressionar: isso tornará essa contribuição trivial para integrar pelo mantenedor à ramificação do projeto original. No contexto da sua pergunta, em que seu PR foi aceito, com certeza, você pode mesclar em vez de rebase para atualizar as ramificações existentes.
VonC 24/03

(Desculpe, alterei o nome de usuário agora para refletir meu github) - @VonC obrigado, portanto todas as sugestões que eu estava lendo sobre o rebase se aplicam antes do PR fazem sentido. Para refletir o PR aceito e mesclado em meu repositório local, existe alguma prática comum (rebase em vez de mesclagem) ou posso fazer o que for? E se eu enviar outro PR embora?
Linuxbandit 24/03


10

Há um ótimo vídeo do Railscast aqui que mostra o processo. Ele também possui várias dicas boas, como mostrar como determinar em qual filial você deseja trabalhar ao contribuir, usar testes, submódulos etc.

Embora esse screencast seja focado principalmente nos desenvolvedores do Rails, a maioria das informações é válida para contribuir com qualquer projeto de código aberto.


4

O Github tem muitas maneiras de colaborar com um projeto. O modelo que a maioria dos projetos usa é um modelo de solicitação de recebimento. Comecei um projeto para ajudar as pessoas a fazer sua primeira solicitação de recebimento do GitHub. Você pode fazer o tutorial prático para fazer seu primeiro PR aqui

O fluxo de trabalho é simples como

  • Bifurque o repositório no github
  • Clone o repositório em sua máquina
  • Faça uma filial e faça as alterações necessárias
  • Envie suas alterações para o seu fork no GitHub git push origin branch-name
  • Vá para o seu fork no GitHub para ver um Compare and pull requestbotão
  • Clique nele e forneça os detalhes necessários


2

Fluxo de trabalho técnico

Eu sugeriria o seguinte fluxo de trabalho:

  1. Bifurcar o repositório (via interface da web do GitHub: botão "Bifurcar")
  2. No seu repositório bifurcado, copie o URL
  3. Clone (na linha de comando)

    git clone <url-from-your-workspace>

  4. Digite o diretório que acabou de ser criado e crie uma ramificação

    cd <directory> git checkout -b <branchname>

  5. Agora faça suas alterações

  6. Você pode criar uma ou mais confirmações após cada alteração:

    commit -a

  7. Quando terminar, faça suas alterações

    git push origin <branch>

  8. Na sua linha de comando, você deve ver um URL para criar o PR . Visite o URL e clique no botão para criar um PR.

  9. Caso contrário, visite o repositório no navegador e ele oferecerá um botão para criar a solicitação pull

É isso aí.

Então, basicamente, você bifurcou o repositório no seu espaço de trabalho, criou um novo ramo e empurrou esse novo ramo.

Se você posteriormente criar mais PR a partir do mesmo repositório clonado, deverá sincronizar (obter as alterações mais recentes do repositório original) antes de criar outra ramificação para outro PR:

git checkout master
git remote add upstream <url-of-original-repo>
git pull upstream master

Outras considerações:

  • o projeto pode ter diretrizes de contribuição: procure um arquivo CONTRIBUTING.rst ou .md
  • convém seguir as diretrizes de codificação do projeto
  • convém delinear sua ideia como problema primeiro
  • convém consultar a guia Pull Requests do projeto e verificar se há PR aberto, PR mesclado

Essas sugestões estão aqui para poupar o trabalho de colocar o trabalho em um PR que não será mesclado. Se houver atividade no projeto e o PR for mesclado, este é um bom sinal. Se houver diretrizes de contribuição, siga-as.

Seja sempre cortês. Lembre-se, os mantenedores do projeto não são de forma alguma obrigados a mesclar seu PR. Você tem algo valioso para adicionar ao projeto?


1
Processo bem detalhado (mais preciso do que minha resposta de 9 anos). Votado.
VonC 01/06/19
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.