Início / coding / Perguntas / 79489496
Accepted
Slaus
Asked: 2025-03-06 21:17:31 +0800 CST

Qual é a melhor maneira de manter alterações que nunca devem ser movidas para o branch principal?

  • 772

As fontes do projeto têm várias condicionais que costumavam testar apenas muitos cenários diferentes, mas essa lógica nunca deve passar para o estado de prontidão de produção do código (é um requisito).

Portanto, quando preciso desenvolver um novo "recurso", pego "produção", aplico as alterações de "teste" sobre ele, implemento o "recurso" digitando a nova lógica e, quando os testes passam (alguns automáticos, alguns manuais), removo as alterações de "teste" e então envio o "recurso" para "produção".

Há alguma prática do Git que possa ajudar nisso?
Tudo que eu tentei: worktree, git merge --no-commit, patch.

git

1 respostas

  1. Best Answer

    Não tenho certeza se entendi sua pergunta corretamente. Mas se entendi, você deve conseguir utilizar git rebasepara isso.

    Então, se entendi corretamente, você quer rastrear algum código para teste que nunca deve ser incluído no branch que é usado para produção. Ao desenvolver um novo recurso, você precisa que esse código esteja presente, mas ao mesclar o novo recurso ao branch de produção, ele não deve incluir o código de teste (commits with).

    Para isso você precisaria de três ramos:

    • productionsegurando o código a ser implantado na produção
    • testsconsistindo no mesmo código que production+ o código de teste adicional
    • featureconsistindo em production+ tests+ novos commits para o novo recurso

    No início, esses ramos podem simplesmente ser construídos uns sobre os outros:

    o---o---o  <-- production
         \
          T1---T2---T3  <-- tests
                      \
                       F1---F2---F3  <-- feature1

    Onde os commits T1-T3 introduzem o código de teste do qual você não quer fazer parte production. Ao iniciar um novo branch de recurso, feature1ele é primeiro o mesmo que testse então você adiciona os commits F1-F3 para o novo recurso a ele.

    Quando terminar o desenvolvimento, você poderá rebasear os commits de frature1on top de testsback on production, veja git rebase --onto:

    # while on branch feature1
git rebase tests --onto production

    o que resultará em

    o---o---o  <-- production
        |\
        |  F1'---F2'---F3'  <-- feature1
         \
          T1---T2---T3  <-- tests

    Agora você pode simplesmente mesclar/avançar rapidamente productionparafeature1

    git checkout production
git merge feature1

    o que resultará em

    o---o---o---F1'---F2'---F3'  <-- production, feature1
         \
          T1---T2---T3  <-- tests

    Então agora você tem todos os novos commits de recursos feature1incluídos production, mas os commits T1-T3 ainda estão em seu próprio branch.

    Para o próximo recurso, você pode fazer o mesmo com uma nova ramificação feature2ramificando de testsnovamente. Mas primeiro você precisa incluir os novos commits de recurso nos testsquais você pode fazer com git rebase testson productionou git merge prodcution:

    # on branch tests
git rebase production

    o que resultará em

    o---o---o---F1'---F2'---F3'  <-- production
                          \
                           T1'---T2'---T3'  <-- tests
                                         \
                                          F4---F5---F6  <-- feature2

    ou

    # on branch tests
git merge production

    o que resultará em

    o---o---o---F1'---F2'---F3'  <-- production, feature1
         \                \
          T1---T2---T3-----o  <-- tests
                            \
                             F4---F5---F6  <-- feature2
    • 1

relate perguntas