Dependendo do seu hist\u00f3rico com o controle do c\u00f3digo-fonte em funcionamento, a maneira como voc\u00ea trabalha com uma base de c\u00f3digo, fazendo commits, etc., varia.<\/p>\n
Al\u00e9m disso, dependendo se voc\u00ea estiver usando Git<\/a>, Subversion<\/a>, Mercurial<\/a> e assim por diante, tamb\u00e9m ditam como voc\u00ea gerencia seu c\u00f3digo.<\/p>\n Mas se voc\u00ea \u00e9 algu\u00e9m que est\u00e1 trabalhando com Git (que eu sei que muitas pessoas no WordPress est\u00e3o come\u00e7ando a usar cada vez mais quase diariamente), existem algumas pequenas coisas que eu recomendo fazer para ajudar a gerenciar mudan\u00e7as especialmente com uma equipe mais gerenci\u00e1vel.<\/p>\n Master deve ser usado especificamente para c\u00f3digo pronto para produ\u00e7\u00e3o e pronto para implanta\u00e7\u00e3o. N\u00e3o \u00e9 o seu ramo de trabalho, n\u00e3o \u00e9 o seu ramo de trabalho.<\/p>\n De um modo geral, \u00e9 aqui que todas as solicita\u00e7\u00f5es pull s\u00e3o mescladas.<\/p>\n Sempre que voc\u00ea tiver uma cole\u00e7\u00e3o de tarefas, problemas ou marcos, crie uma ramifica\u00e7\u00e3o e verifique se o que voc\u00ea est\u00e1 trabalhando est\u00e1 relacionado. Por exemplo, voc\u00ea n\u00e3o quer trabalhar com banco de dados e JavaScript em suas pull requests.<\/p>\n Mesmo se voc\u00ea estiver trabalhando apenas no trabalho de front-end, talvez seja necess\u00e1rio dividi-lo em ramifica\u00e7\u00f5es menores. Isso facilita as revis\u00f5es de c\u00f3digo e as solicita\u00e7\u00f5es de pull<\/a> melhores .<\/p>\n Isso \u00e9 muito semelhante ao t\u00edtulo anterior, mas a ideia de criar pequenos PRs \u00e9 muito mais produtiva do que criar pull requests mais longos.<\/p>\n Mas o que constitui um bom PR?<\/p>\n No que me diz respeito, uma boa solicita\u00e7\u00e3o de pull far\u00e1 um pequeno conjunto de coisas:<\/p>\n Dito isso, provavelmente h\u00e1 mais coisas que voc\u00ea pode fazer, mas essas s\u00e3o as coisas que eu achei mais \u00fateis (e eu ficaria remido em dizer que n\u00e3o aprendi algumas dessas coisas com minha equipe<\/a> ).<\/p>\n Sempre.<\/p>\n Mas essas s\u00e3o algumas coisas que eu descobri serem cada vez mais \u00fateis, especialmente ao rastrear mudan\u00e7as, trabalhar com outras pessoas e lidar com solicita\u00e7\u00f5es de pull (tanto daqueles com quem eu trabalho quanto daqueles que contribuem para projetos de c\u00f3digo aberto).<\/p>\n Finalmente, nenhuma dessas coisas \u00e9 prescritiva. H\u00e1 uma curva de aprendizado (falando por experi\u00eancia), mas eu recomendo experimentar algumas delas, se n\u00e3o por outro motivo, a n\u00e3o ser para ver se isso n\u00e3o melhora seu fluxo de trabalho.<\/p>\n Mesmo que seja um pouco.<\/p>\nDicas para um fluxo de trabalho aprimorado do GitHub<\/h2>\n
1 N\u00e3o se comprometa com o mestre<\/strong><\/h3>\n
2 Tente sempre criar ramifica\u00e7\u00f5es<\/strong><\/h3>\n
3 Lote seu trabalho<\/strong><\/h3>\n
4 Gerar Pequenos PRs<\/strong><\/h3>\n
\n
5 D\u00ea bons detalhes em seu PR<\/strong><\/h3>\n
\n
H\u00e1 mais coisas?<\/h2>\n