[GitHub a rede social do programador]
Talk is cheap. Show me the code. - Linus Torvalds em uma mensagem para a linux-kernel mailing list em 25/08/2000
Lone Gunman
Durante a maior parte da minha carreira eu trabalhei sozinho ou em equipes muito pequenas, é fácil manter controle de versão quando se esta sozinho, qualquer sistema vai funcionar desde que ele não entre na sua frente e seja minimamente eficiente, eu programo desde os anos 90 e já passei por tudo, desde copiar todo o projeto para um outro diretório, ou zipar o projeto com a data da mudança, CVS, SVN, e agora Git. De todos esses o Git é sem duvida o melhor equilíbrio entre funcionalidade e praticidade, a curva de aprendizado é bastante suave com quatro ou cinco comandos você esta usando Git sem problemas. E hoje os tempos de pistoleiro solitário ficaram para traz, trabalho em uma equipe e não estamos juntos na mesma sala, trabalhamos de forma assíncrona e o controle de versão precisa absorver isso. A natureza descentralizada do Git ajuda muito a juntar varias partes do trabalho e montar o quebra-cabeça que é um software moderno.
GitHub
Apesar de já usar o git a algum tempo, só comecei a usar o GitHub pra valer no início de 2016, antes disso eu só tinha brincado com o sistema. Nesse ultimo ano foi muito bom, conheci vários programadores fantásticos e tive contato com muitos projetos interessantes. Aprendi a melhorar meu código da melhor forma possível ou seja vendo como outros programadores resolviam os problemas, falando com eles, discutindo os pros e os contras.
Trabalhando em equipe
Para trabalhar em grupo basta seguir algumas regrinhas simples, crie sempre um branch para suas alterações submeta seu trabalho em um pull request (PR). Isso geralmente já é suficiente para a maioria dos projetos profissionais, no sentido de que você foi contratado para fazer as alterações e recebeu instruções do que fazer.
Contribuindo para projetos de código aberto
Contribuir com código aberto é um pouco mais complicado mas não muito. O ideal é você fazer um fork do código para o seu repositório pessoal, dai para frente é a mesma coisa, cria um branch para suas alterações e faz um pull request quando acabar.
Antes de contribuir leia o README.md do projeto, procure detalhes do como contribuir, se não estiver direto no README.md pode estar em um arquivo especifico como CONTRIBUTING.md, também é importante ler as issues do projeto e discutir o que você quer fazer por lá antes de tentar mandar código.
Meu Pull Request foi rejeitado
Não se preocupe se seu pull request for rejeitado, veja os comentários dos mantenedores dos projetos, geralmente eles dizer o que esta faltando ou o que você fez de errado. As vezes é uma questão de ler o README.md ou o CONTRIBUTING.md com mais calma. Eu já dive contribuições recusadas por não ter lido direito as regras para minha contribuição ser aceita. Não desista e não abandone seu seu trabalho.
Será que meu código é bom o bastante?
As vezes por insegurança muita gente deixa de contribuir, não se preocupe com a qualidade do seu código, tente fazer o melhor que puder, dificilmente ele vai ser recusado se seguir as regras de contribuição do projeto, faça testes e garanta que seu código funciona, essa é a parte importante. Alem disso você pode contribuir com outras coisas alem de código, documentação por exemplo é algo que todo projeto precisa, escrever testes também. Mesmo reportar bugs já é uma grande ajuda.
O que vem pela frente
Cada vez mais meus projetos e de muitos amigos giram em torno do GitHub e aparentemente esse numero só tente a crescer e cada vez mais o profile no GitHub passa a ser o currículo.