Talk is cheap. Show me the code. - Linus Torvalds em uma mensagem para a linux-kernel mailing list em 25/08/2000
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.
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.
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.
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.
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.
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.
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.