Closed filipedeschamps closed 2 years ago
Acho que não é prudente desabilitar o force push
na main
.
Mesmo sendo a solução mais dolorosa, acho que a 4 seria a melhor para manter a boa organização do projeto.
Também é possível salvar o git diff
desses commits em um arquivo .diff
, "remover" os commits fora de padrão e dar um git apply
nos diffs commitando eles com uma mensagem, dessa vez dentro do padrão do projeto. Porém a história do git ficará um pouco suja também
Fala meu caro, acho que não fui claro na minha mensagem inicial e refatorei ela, veja se agora ficou claro que era uma sugestão de passos a seguir 🤝
Minha dúvida é se a única forma de consertar a main
é com essa estratégia.
Opa Filipe, acabei me confundindo mesmo, falhei no meu lado da interpretação também. Agora está bem claro e acredito que seja uma boa solução para o problema encontrado. Será trabalhoso, mas acho que valerá a pena. Já fiz o backup da main no meu computador
Show meu caro! Possivelmente vou fazer essa movimentação no domingo 🤝
Vale a pena esse trabalho?
Se entendi direito, o problema só está ocorrendo porque o PR teve como base uma branch antiga. Um rebase nos commits do #431 usando a main atual não resolve de maneira mais simples?
Se tiver algum outro PR com base em branch antiga, é só fazer um rebase também. E nos futuros PRs esses commits antigos não devem causar problemas.
Se entendi direito, o problema só está ocorrendo porque o PR teve como base uma branch antiga.
No caso não é nem uma branch antiga, mas apenas 1 commit antigo que fez o commitlint
reavaliar todos os commits dali para frente.
Um rebase nos commits do #431 usando a main atual não resolve de maneira mais simples?
Então, isso não seria "resolver", no sentido de consertar o problema que está na main
. Mas sim, um rebase "resolveria" o problema escondendo da visão do commitlint os commits inválidos.
Vale a pena esse trabalho?
Essa pergunta me deixou pensando... e talvez não valha não (pelo menos não no timing de estar no meio da Milestone) 👍
Vamos então combinar duas coisas:
main
.O que acha?
1) Na próxima Milestone que isso se apresentar um problema, ao final dela a gente mandatoriamente reescreve a
main
. 2) Vamos nessa Milestone (e em qualquer momento dela), implementar o Husky...
Acho que é o melhor a se fazer no momento 🚀
Fechadíssimo 🤝 E sua nova foto de perfil ficou ótima 😂 👍
Fechadíssimo 🤝 E sua nova foto de perfil ficou ótima 😂 👍
Esse simpático do meu lado é muito fotogênico... hahahahaha
No passado eu fiz um
squash
aqui pela interface do GitHub assumindo que ele iria criar uma mensagem de commit válida e o meu erro foi não fazer essesquash
contra uma branch intermediária na qual passasse pelocommitlint
, então isso foi para amain
e o problema ressurgiu no PR #431 que trouxe um commit do passado e fez ocommitlint
reclamar de commits passados.Gostaria da avaliação de vocês sobre os passos do que fazer
main
.force push
contra amain
.commitlint
local e reavaliar e reescrever todo histórico que estiver quebrado (usando orebase
comreword
para alterar apenas a mensagem)force push
para amain
.main
Bônus
Já sugeriram isso no passado (e a última vez que isso foi sugerido foi pelo @andrefd17 se eu não me engano) que é antes do push rodar o lint dos commits na máquina local da pessoa.
Conclusão
Esse é o caminho certo? Alguém já passou por isso no passado e tem alguma sugestão?