Como faço para enviar um patch para outro desenvolvedor e mesclar evitar conflitos?

Question

Como faço para obter um patch de uma consolidação, a fim de enviá-lo para outro desenvolvedor? E como faço para melhor evitar um conflito de mesclagem com este patch ao mesclar nossas árvores em uma data posterior?

Se você sabe como explicar como fazer isso em seus VCS de escolha, como subversão, git, Mercurial, bzr ou etc.

Answer 1

Na git você pode canalizar a saída do git-diff entre dois commits como este:

git diff fa1afe1 deadbeef > patch.diff

Enviar a patch.diff para o desenvolvedor e deixá-lo git-apply -lo para o seu espaço de trabalho como este:

git apply patch.diff

Se o outro desenvolvedor já tem os commits disponíveis em seu repositório que podia sempre canalizá-lo em si mesmo, sem a fusão como esta:

git apply < git diff fa1afe1 deadbeef

Você pode então adicionar e < a href = "http://www.kernel.org/pub/software/scm/git/docs/git-commit.html" rel = "noreferrer"> cometer as mudanças no diff a maneira usual .

---

Agora, aqui vem a parte interessante quando você tem que mesclar a volta patch para o branch master (que é pública). Considere o seguinte árvore de revisão onde C* é o patch aplicado a partir C no branch master:

A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

Você pode usar git-rebase para atualizar o ramo tópico (neste exemplo chamado feature_foo) com a sua cabeça a montante. O que isto significa é quando você digitar o seguinte:

git rebase master feature_foo

Git irá reorganizar a árvore de revisão como este e também irá aplicar o patch em si:

A---B---C---D          master, public/master
             \
              E*---F*  feature_foo

A fusão ao ramo montante será agora uma fusão fácil de fast forward. Além disso, verifique que os novos commits E* e trabalho F* como o E anterior e F respectivamente.

Você pode fazer a mesma coisa contra a filial do outro desenvolvedor usando os mesmos passos, mas em vez de fazê-lo em um repositório público, você poderá buscar revisões do repositório do desenvolvedor. Desta forma, você não terá que pedir o outro desenvolvedor para um patch se ele já está disponível a partir do que ele publicou em seu repo.

Por favor nota para não rebase um ramo pública porque o comando vai reescrever a história git que é algo que você não quer fazer em ramos que as pessoas dependem e vai criar uma confusão quando se fundindo para remoto repositórios. Além disso, nunca se esqueça de integrar frequentemente para que os outros em sua equipe pode participar de suas alterações.

Answer 2

Em SVN você pode simplesmente fazer as alterações, em seguida, antes de cometer, canalizar a saída do svn diff para um arquivo como tal

svn diff > mypatch.diff

então você pode reverter as alterações e aplicar o patch em uma data posterior usando

patch -p0 -i mypatch.diff

Como sempre não cegamente aplicar patches ao seu código e sempre inspecioná-los em primeiro lugar.

Você também pode achar que o patch vai quebrar o seu código fonte, se os arquivos de origem mudaram significativamente o suficiente desde o patch foi tomada.

Você também não pode garantir que não haverá conflitos de mesclagem quando você tentar verificar no código.

Answer 3

alças Bzr envio de uma "directiva merge", o que significa que envia o patch para você, para que a outra parte pode simplesmente clicar em "OK" para merge e há menos futzing redor com patch / aplicar etc.

apenas: $ Bzr envio -o mycode.patch

Answer 4

No Subversion não há nenhuma boa maneira de fazer isso. Sim, você pode usar svn diff + patch, mas isso só vai adiar os seus problemas até que você está indo para mesclar e por chances são, então, que você tenha esquecido sobre isso.

A maneira como você faria isso no Subversion seria a criação de uma filial, que o commit no ramo e pedir o destinatário do patch para mudar para o ramo. Então você pode mesclar a parte de trás ramo ao tronco da forma habitual.