By the time I'm ready to merge my branch back into develop (emphasis mine)
O gerenciamento de conflitos em git merge costuma ser mais simples do que em git rebase . No Git merge você pode ver toda a lista de arquivos que foram modificados de uma só vez. Não importa quantos commits tenham sido feitos por outros colegas de trabalho, você precisará mesclar uma vez . Com o fluxo de trabalho de rebase, você pode acabar recebendo os mesmos conflitos várias vezes e ter que revisá-los manualmente. Você pode acabar consertando o 13º commit e sentir que você não consegue ver a luz do túnel .
Pela minha experiência, quando tentei ingenuamente resolver conflitos repetidos de rebase, acabei perdendo as modificações de alguém ou com uma aplicação que nem sequer compilaria. Muitas vezes eu e meus colegas de trabalho trabalhavam muito, mas ficávamos tão impressionados com a complexidade de repetir conflitos que tivemos que abortar e perder nosso trabalho anterior depois de alguns commits de rebase.
Vou sugerir algumas técnicas, mas elas só podem ajudar a união a se tornar mais fácil do que automatizar a tarefa.
-
Arquivos de recursos / idiomas . Se você tiver alterações aditivas em um arquivo de recursos, lembre-se de movê-las sempre para o final do arquivo para poder lembrar facilmente suas alterações em relação a outras
-
faça. Não. ABSOLUTAMENTE. RE-format . Nem você nem seus colegas desenvolvedores devem executar uma "reformatação maciça de código" durante o trabalho diário. Reformatação de código adiciona um número excessivo de falsos positivos no gerenciamento de conflitos. Reformatação de código pode ser feita
- Incrementalmente, por exemplo por cada desenvolvedor em cada commit, assim que eles usam uma ferramenta automatizada (por exemplo, o Eclipse tem uma opção para reformatar quando salvo, o Visual Studio não tem nenhum). Absolutamente todo desenvolvedor deve usar os mesmos padrões de formatação de código, codificados em um arquivo de formato que é comido pelo seu IDE. Para se ter uma ideia, se são 4 espaços ou 2 guias, isso não importa, mas realmente importa se todos usam o mesmo.
- Pouco antes do lançamento, por um líder de equipe. Se um commit de "reformatar código" ocorrer quando as pessoas não estiverem trabalhando em filiais, ou seja, antes de se ramificarem, as coisas tornarão mais fácil
-
Revise o trabalho dividido entre colegas de trabalho. Essa é a parte em que a maior parte da engenharia vem. Como apontado por outras respostas, é o cheiro do design se vários desenvolvedores que executam tarefas diferentes precisarem tocar nos mesmos recursos. Você pode ter que discutir com o líder de sua equipe sobre qual parte deve ser modificada por cada desenvolvedor concorrente.
Eu também tenho visto alguns maus hábitos nos fluxos de trabalho do Git nas minhas equipes. Muitas vezes as pessoas supercomprometem seus galhos. Eu pessoalmente testemunhei um desenvolvedor adicionando de 10 a 20 commits com o rótulo "fix", cada um comprometendo uma ou duas linhas. Nossa política é que os commits são rotulados com tickets do JIRA para que você tenha uma ideia.
@JacobRobbins sugere tornar git rebase uma tarefa diária. Eu gostaria de empurrar sua abordagem para frente.
Primeiro, use rebase apenas para reduzir o número de commits para um punhado. E rebase apenas para o ramo de desenvolvimento original , que é o commit do qual você se ramificou. Quando eu digo punhado, eu poderia significar 3 ou 4 (por exemplo, todos os front-end, todos os back-end, todos os patches do banco de dados) ou qualquer valor humanamente razoável. Depois de consolidá-los, use fetch e trabalhe seu rebase na ramificação upstream. Isso não irá salvá-lo do conflito, a menos que sua equipe revise sua própria abordagem, mas tornará sua vida menos dolorosa.
Se você tiver perguntas adicionais sobre as tarefas específicas, sinta-se à vontade para pesquisar e perguntar no Stackoverflow.
[Editar] sobre a regra de não-reformatação e escoteiro. Reformulei um pouco o RE-format para destacar que o que estou querendo dizer é a tarefa de formatar do zero todo o arquivo de origem, incluindo o código que não foi tocado por você. Ao contrário de sempre formatar seu próprio código, o que é perfeitamente boy-scouty, vários desenvolvedores, inclusive eu, são usados para reformatar o arquivo inteiro com os recursos do IDE. Quando o arquivo é tocado por outros, mesmo que as linhas afetadas não sejam alteradas em seus conteúdos e semânticas, o Git o verá como um conflito. Apenas um editor de linguagem sensível muito poderoso pode sugerir que o conflito está relacionado apenas à formatação e à mesclagem automática do fragmento formatado melhor. Mas eu não tenho provas de tal ferramenta.
Afinal, a regra do escoteiro não obriga você a limpar a bagunça de outras pessoas. Apenas o seu.