💡 Git-Flow가 필요한가요?

Ao trabalhar em equipment, é necessário definir convenções ou boas práticas para que todos saibam trabalhar juntos. O Git-Flow는 워크플로를 많이 사용하고 있으며, 가장 인기 있는 방법은 실용성과 관련성이 높은 속도입니다. É uma forma de organizar as branches do seu repositório. 그래서 Git-Flow 애플리케이션은 품질 보증(QA) 워크플로우에 대한 소유권을 설정하기 위해 필요한 장비를 갖추기 위해 필요한 사항입니다.

OBS.: Não irei me atentar em ficar citando os comandos do Git-Flow, o foco neste artigo é outro e você pode consultar esses comandos acessando a Documentação.

⭐ 동기

Usando essa estratégia, o objetivo é:

Redução de conflitos, pois o git flow irá ficar responsável por criar e fechar a branch de desenvolvimento no local correto(de forma automática)

Padronização do nome de branches, Já que o git flow coloca prefixos automáticos como "feature/nome-da-branch"또는 "hotfix/nome-da-branch"

Segurança no processo de desenvolvimento

Sobe o que está OK pelo QA

Possibilidade de voltar a produção com base na versão desejada

Versionamento do sistema através das tags

Todos desenvolvedores alinhados com o processo

조직

"Git Flow"에 대한 자세한 내용은 essa에서 다음과 같이 다음과 같이 설명합니다.


기본적으로 Git-Flow는 Code Review 및 QA 흐름에 대한 QA 프로세스에 적응하고 프로세스를 변경하기 위해 필요한 플럭스를 수행합니다.

적응

Então는 Code Review와 QA(Ambientes de Teste) 테스트에서 영국 모델에 대한 적절한 모델을 제공해야 합니다. Fluxofica Assim이 아닌 수정 사항:

Veja que entrou uma nova camada entre as feature e development. 기능을 "마무리"하는 것이 중요한 이유는 Code Review에서 분기를 통과할 때 QA 유효성 검사를 통과하기 때문입니다. 실행 프로그램을 개발할 때 다음과 같은 결과가 나올 수 있습니다.

$ git flow feature finish nome_da_branch

개발하다

Outro ponto que podemos observar é que a development além de ser um "espelho"da "master"em alguns momentos, ela semper irá conter as features finalizadas(foram testadas pelo QA e validadas).

세구란사

Git-Flow를 지원하는 Essas는 새로운 기능을 수행할 수 있는 소프트웨어를 제공하기 위해 제품(브랜치 마스터)에서 QA(정확한 QA)를 생산하고 개발할 수 있도록 지원합니다. Partir desse ponto é que o desenvolvimento pode ser disponibilizado caso seja criada uma 릴리스.

Como aplicar a metodologia a minha equipment ?

O processo pode ser que não se adeque totalmente a realidade do seu time, porém, pode adapta-lo para que chegue em um modelo que atende a necessidade do projeto.

Como dica eu sugiro começar por um repositório e em seguida ir aplicando nos demais(se na sua equipe trabalha em mais de um projeto).

OBS: Processo bom é aquele que resolve o problema do seu trabalho, se a sua equipe já funciona bem com uma metodologia diferente eu não vejo motivos para mudar.

É isso galera, espero ter ajudado vocês falando em uma perspectiva diferente sobre o Git-Flow, pois a maioria dos artigos que vejo são focados no uso da ferramenta(como executar os comandos) e não se atentando a estrutura e organização.