Git Branch Basics

Git Branch Basics

Noções básicas de ramificação git

A capacidade de ramificar facilmente é uma das melhores características do git. Criar ramificações em outros sistemas de controle de versão pode ser caro em termos de espaço e requisitos de processamento. Ramificação git é eficiente. Portanto, os usuários são mais propensos a usar ramificações no Git.

Um fluxo de trabalho ramificado

Suponhamos que você tenha iniciado um novo projeto chamado MyVideogame. Tem um único ramo. O nome padrão da filial inicial no Git é chamado de mestre. É criado automaticamente. Vamos criar o MyVideogame Git Repository.

$ mkdir myvideogame
$ CD MyVideogame
$ git init

Você criou um repositório Git vazio. Vamos adicionar nosso design.arquivo txt com algum texto nele.

$ echo "Decisão de design 1: Adicionar imagens" >> Design.TXT
$ echo "Design Decision 2: Write Code" >> Design.TXT
$ git add -a
$ git Commit -M "C0: Arquivo de design adicionado"

Vamos adicionar mais algumas mudanças:

$ echo "Decisão de design 3: jogo de teste" >> Design.TXT
$ git add -a
$ git Commit -M "C1: arquivo de design modificado"

Se você verificar o histórico, você encontrará:

$ git log --oneeline
6A09BD6 C1: arquivo de design modificado
5F18D89 C0: Arquivo de design adicionado

Se você verificar o status Git e todas as filiais criadas (usando o comando: git ramo -a), você vê:

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo
$ git ramo -a
* mestre

Atualmente, você tem a seguinte situação:

Você fez duas comissões no ramo mestre.

Suponhamos que você encontrou bugs em seus testes de jogo, mas você não deseja abordar o problema no ramo mestre porque não quer mexer com o design original ainda. Então você pode criar uma nova filial chamada Bugfix:

$ git ramil bugfix

Agora, se você verificar todas as filiais:

$ git ramo -a
Bugfix
* mestre

Agora você criou uma nova filial chamada Bugfix. A situação pode ser visualizada assim:

No entanto, a estrela (*) ao lado do ramo principal significa que você ainda está no mestre. Se você fizer alterações, ele ainda entrará no ramo mestre. Você pode usar o comando de checkout para alterar as filiais:

$ git checkout bugfix
Mudou para o ramo 'bugfix'

Você pode verificar qual ramificação você está usando com o comando status ou “ramo -a”:

$ git status
Na bug de ramificação
nada para se comprometer, diretório de trabalho limpo
$ git ramo -a
* bugfix
mestre

Agora, vamos consertar o bug:

$ eco "correção de bug 1" >> design.TXT
$ git add -a
$ git Commit -M "C2: Bug corrigido 1"

Você criou uma situação como esta:

O ramo principal não tem a mudança C2. Você pode verificar facilmente isso verificando a história dos dois ramos.

Primeiro, a história da filial da correr:

$ git status
Na bug de ramificação
nada para se comprometer, diretório de trabalho limpo
$ git log --oneeline
E8F615B C2: Bug corrigido 1
6A09BD6 C1: arquivo de design modificado
5F18D89 C0: Arquivo de design adicionado

Então você pode mudar para o Master Branch e verificar seu histórico:

$ git checkout mestre
Mudou para a filial 'Mestre'
$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo
$ git log --oneeline
6A09BD6 C1: arquivo de design modificado
5F18D89 C0: Arquivo de design adicionado

Você pode ver que o ramo principal não tem as alterações do ramo da bugfix.

Você sempre pode criar uma nova filial a partir do ramo atual em que está localizado. Suponha que você queira criar outro ramo que contenha recursos experimentais. Você pode criar o ramo a partir do mestre e adicionar recursos experimentais:

$ git status
No mestre da filial
nada para se comprometer, diretório de trabalho limpo
$ git ramo experimental
$ git checkout experimental
Mudou para a filial 'experimental'
$ git status
Na filial experimental
nada para se comprometer, diretório de trabalho limpo
$ echo "Adicionando recursos do experimento" >> Design.TXT
$ git add -a
$ git Commit -M "C3: Recursos experimentais adicionados"
[Experimental 637BC20] C3: Adicionado recursos experimentais
1 arquivo alterado, 1 inserção (+)

Se você verificar o histórico do seu ramo experimental, verá:

$ git status
Na filial experimental
nada para se comprometer, diretório de trabalho limpo
$ git log --oneeline
637BC20 C3: Recursos experimentais adicionados
6A09BD6 C1: arquivo de design modificado
5F18D89 C0: Arquivo de design adicionado

Você notará que você não tem o commit C2 que foi criado na filial de bugfix. Como o ramo experimental é criado a partir do Master Branch, ele não vê as mudanças de bugs. Você tem a seguinte situação:

Conclusão

Parabéns! Você aprendeu a se ramificar.

Galhos git são fáceis e rápidos de fazer. É uma das razões por trás da popularidade de Git. Se você deseja se tornar um usuário proficiente do Git, precisa se tornar proficiente na ramificação Git.

Um estudo mais aprofundado:

https: // git-scm.com/book/en/v2/git ramnching-basic rchaming and merging