Questionário de Revisão (Respostas Curtas)

Abaixo estão dez questões baseadas no conteúdo técnico dos

materiais de estudo. As respostas devem ter entre duas e três frases.

Perguntas

1. O que define o conceito de versionamento e por que ele

é superior ao método de cópias manuais de arquivos?

2. Qual é a diferença fundamental entre o Git e o GitHub?

3. Explique a função do comando git init e o que ocorre no

diretório do projeto após sua execução.

4. O que são os "objetos" do Git conhecidos como Blob,

Tree e Commit?

5. Como funciona o sistema de estágios (Working Tree,

Stage e Commit) no fluxo de trabalho do Git?

6. Para que servem as ramificações (branches) em um

projeto e qual a vantagem de utilizá-las?

7. O que é o algoritmo "Three-way merge" e como ele

auxilia na resolução de conflitos?

8. Em que situações um desenvolvedor deve utilizar o

comando git commit --amend?

9. Qual é a utilidade do arquivo .gitignore em um

repositório?

10. Como o comando git add -p permite um controle

mais granular sobre as modificações que serão enviadas
para o repositório?

--------------------------------------------------------------------------------

Chave de Respostas

1. O versionamento é o controle das diversas versões de um

código ou documento, permitindo registrar todas as alterações
feitas sem a necessidade de manter múltiplos arquivos físicos.
Ele supera as cópias manuais por ser mais prático, economizar
armazenamento e facilitar o trabalho em equipe através de um
histórico organizado.

2. O Git é a ferramenta de controle de versão instalada localmente

no computador para gerenciar o histórico de arquivos. O GitHub
é um serviço de hospedagem remota que utiliza o Git,
 funcionando como backup, plataforma social e portfólio para
desenvolvedores.

3. O comando git init inicializa um repositório Git em uma pasta

específica, permitindo que o rastreamento de versões comece
naquele diretório. Após a execução, é criada uma pasta oculta
chamada .git/, que atua como o banco de dados onde todas as
modificações e objetos do projeto serão armazenados.

4. O Blob armazena o conteúdo de texto puro de um arquivo

individual; a Tree representa um diretório e guarda referências
para Blobs ou outras Trees; e o Commit aponta para uma Tree
específica, incluindo metadados como autor, data e a
mensagem da alteração.

5. O Working Tree é o diretório local onde os arquivos são editados

livremente; o Stage (ou Index) é a área de preparação onde as
mudanças selecionadas aguardam para ser confirmadas. O
Commit é o estágio final, onde as modificações no Stage são
empacotadas permanentemente no histórico com um
identificador único.

6. As branches são ramificações da linha do tempo principal

(Main/Master) que permitem desenvolver novas funcionalidades
ou corrigir erros em isolamento. Isso garante que o código
estável não seja afetado por experimentos e permite que
múltiplos ciclos de desenvolvimento ocorram simultaneamente.

7. O Three-way merge compara a versão atual da branch principal,

a versão da branch de funcionalidade e o último commit comum
antes da separação (base original). Com essa base, o Git
consegue identificar automaticamente qual modificação é a
mais recente e deve prevalecer, minimizando conflitos manuais.

8. O comando git commit --amend é usado para corrigir a

mensagem do último commit realizado ou para adicionar
pequenas mudanças que foram esquecidas antes da
confirmação. Ele substitui o último commit por um novo, sendo
uma prática recomendada para manter o histórico limpo.

9. O arquivo .gitignore lista pastas e arquivos que o Git deve

ignorar propositalmente, como bibliotecas pesadas
(ex: node_modules), arquivos de configuração local ou caches.
Isso evita que dados irrelevantes ou sensíveis sejam enviados
ao repositório remoto, respeitando limites de armazenamento e
segurança.
 10. O comando git add -p (patch) permite que o
desenvolvedor escolha "hunks" ou pedaços específicos de
código dentro de um mesmo arquivo para adicionar ao Stage.
Dessa forma, é possível separar modificações de diferentes
contextos em commits distintos, mesmo que as alterações
estejam no mesmo arquivo físico.

[Link]ário Abrangente de Termos-Chave

Termo Definição
Objeto que armazena o conteúdo de um arquivo em formato binário ou
Blob
texto puro dentro do Git.
Uma ramificação ou linha do tempo independente no desenvolvimento
Branch
de um projeto.
Ação de mudar de uma branch para outra ou restaurar arquivos do
Checkout
histórico para o diretório de trabalho.
Um registro permanente de um conjunto de alterações, funcionando
Commit
como um "ponto de salvamento" na história do projeto.
Nome dado aos patches (diferenças entre arquivos) quando são
Delta
compactados para transferência ou armazenamento.
Uma cópia completa de um repositório remoto para a conta de outro
Fork
usuário, permitindo modificações sem afetar o projeto original.
Um ponteiro que indica o commit atual ou a ponta da branch na qual
HEAD
você está trabalhando no momento.
Hunk (ou Uma seção específica de modificações dentro de um arquivo que o Git
Chunk) identifica durante uma comparação.
O processo de unir o histórico de duas branches diferentes, integrando
Merge
suas modificações.
O nome padrão dado ao repositório remoto principal do qual um
Origin
repositório local foi clonado.
Um arquivo ou fragmento que descreve as diferenças exatas de linhas
Patch
entre duas versões de um código.
Comando que busca as atualizações de um repositório remoto e as
Pull
mescla automaticamente no repositório local.
Comando que envia os commits realizados localmente para um
Push
repositório remoto.
Arquivo em formato Markdown (.md) que serve como a página de
README
apresentação e manual de instruções de um repositório.
Uma versão do seu projeto hospedada na internet ou em outra rede
Remote
(como no GitHub ou GitLab).
O diretório onde o Git armazena todo o histórico e os metadados do
Repository
projeto.
Um identificador alfanumérico único gerado pelo Git para cada commit,
SHA1 / Hash
garantindo a integridade dos dados.
Stage (ou A área intermediária onde as modificações são preparadas antes de
Index) serem confirmadas em um commit.
Um arquivo compactado que une diversos arquivos do repositório para
Tarball
facilitar a cópia inicial (clone).
 O conjunto de arquivos reais no disco que você está editando no
Working Tree
momento, fora do banco de dados do Git.

Git vs. GitHub

Embora frequentemente usados juntos, eles possuem papéis

distintos:

 Git: É o software que você instala e utiliza localmente para

rastrear mudanças e gerenciar versões no seu computador.

 GitHub: É um serviço de hospedagem na nuvem que armazena

repositórios Git, servindo como backup remoto, plataforma de
colaboração em equipe e portfólio profissional.

O Fluxo de Trabalho Básico

De acordo com as fontes, o processo padrão de versionamento segue

estas etapas essenciais:

1. Inicialização: O comando git init cria a pasta oculta .git/, que

funciona como o banco de dados de todas as modificações do
projeto.

2. Preparação (Staging): Antes de salvar permanentemente,

utiliza-se o git add para selecionar quais arquivos ou mudanças
específicas farão parte do próximo registro.

3. Registro (Commit): O comando git commit empacota as

mudanças preparadas, adicionando metadados como autor,
data e uma mensagem explicativa do que foi feito.

4. Sincronização: O comando git push envia seus commits locais

para o servidor remoto (GitHub), enquanto o git pull traz as
atualizações do servidor para sua máquina.

Ramificações (Branches) e Colaboração

As Branches permitem criar ramificações na linha do tempo do

projeto. Isso possibilita desenvolver novas funcionalidades ou corrigir
erros em um ambiente isolado, sem afetar o código principal que está
funcionando. Uma vez que a alteração é testada e aprovada, utiliza-
se o Merge (ou mesclagem) para unir essa ramificação de volta à
branch principal.

Boas Práticas Recomendadas

 Mensagens de Commit: Devem ser específicas e claras. Evite

termos genéricos como "ajustes" ou "correções"; descreva
 exatamente o que mudou para facilitar a navegação no
histórico futuramente.

 Commits Atômicos: Procure realizar commits pequenos e

frequentes, focados em um único contexto, em vez de um
grande commit que mistura várias alterações diferentes.

 Uso do .gitignore: É um arquivo que lista quais arquivos ou

pastas o Git deve ignorar (como arquivos temporários ou
dependências pesadas), mantendo o repositório organizado e
leve.

Flags
Comando O que faz
interessantes

Configura um
init
repositório git do zero

Baixa o código-fonte
clone existente de um
repositório remoto

-b Cria uma nova

Muda de branch / Pode
branch com base na
checkout ser usada para
atual -d Deleta a
recuperar mudanças
branch especificada

Mostra o status atual

status
do repositório

-p Disponibiliza uma
seleção interativa
hunk a hunk -i
Adiciona as mudanças Selecionar, remover
add
ao stage e parar de
monitorar arquivos
em massa e de
forma interativa

commit Salva as mudanças em -m Libera o uso de

stage para um patch uma mensagem de
commit e deixa o
fluxo mais rápido --
 Flags
Comando O que faz
interessantes

amend Corrige a
mensagem de seu
último commit

-u Realiza o upload
Envia os commits para da sua branch caso
push o repositório remoto na ela seja nova e não
branch específica está disponível no
repositório remoto

Traz as atualizações do
repositório remoto,
pull
caso tenha, realiza o
merge

Desfaz o commit com o

revert
hash/id

Mostra os últimos
log
commits

Faz a união entre a

merge branch atual e a branch
especificada

Adiciona um repositório
remote add
remoto

--soft Remove os
commits mas não
reset
É capaz de remover os remove as
HEAD~<númer
commits selecionados alterações --hard
o>
Remove commits e
alterações

rebase Remove todos os -i Modo interativo

commits e volta ao
estado da branch
especificada. Também
 Flags
Comando O que faz
interessantes

pode ser usado como

um processo avançado
de remoção/squash de
commits

--staged Mostra as
Mostra as mudanças mudanças que
diff
realizadas no detalhe estão sendo levadas
para o commit

Salva as mudanças na
pop Recupera as
stash branch atual sem
alterações
realizar um commit

O fluxo de trabalho com Git segue um padrão:

1. Modificar arquivos no diretório de trabalho

2. Adicionar mudanças à área de preparação (staging area)

3. Commitar as mudanças para criar um ponto no histórico

Antes de tudo, vamos entender o que são esses termos “staging” e

“remote” que tem relação direta a Git Lifecycle. (link)

O Git Lifecycle define diferentes estágios para os arquivos dentro do

gerenciamento de projetos do git. Essas definições de estágios
representa as ações e mudanças realizadas como tracking, staging,
commiting e pushing. São definidas 4 estágios, sendo eles:

 Working Directory — Onde os arquivos são criados e

modificados, mas ainda não foram monitorados ou reconhecido
pelo Git;

 Staging Area — É um espaço temporário onde as mudanças

são adicionadas antes das commits;

 Local Repository — É o repositório local onde é armazenado

todas as mudanças e commits;

 Remote Repository — repositório compartilhado que está

numa hospedado numa plataforma (por exemplo, Github,
 GitLab e BitBucket) onde são realizados os comandos push e
pull entre os colaboradores do repositório.

Press enter or click to view image in full size

fonte: GeeksforGeeks — link

Cada estágio tem papéis importantes no decorrer do

desenvolvimento do projeto:

 Working Directory (Untracked/Modified State)

É o estágio que contém todos os arquivos do projeto. Tem
importante papel de saber como estão todos os arquivos do
projeto:
- ou se foram modificados;
- ou se não foram rastreados.
Os comandos utilizados nesse estágio são:

git status # Lista quais arquivos foram modificados e quais foram

rastreados
git diff # Verifica mudanças realizadas no diretório do projeto

Por que é importante saber se foi rastreado ou não?

Nesse caso, pode ocorrer que no seu projeto tenha o arquivo
“.gitignore” onde você lista quais arquivos, diretórios e formatos de
arquivos que devem ser ignorados pelo git. Por exemplo:

# Ignorar ambientes virtuais

venv/
env/
venv_teste/

# Logs na raiz do projeto

*.logs

# Por questão de segurança, não enviar os dados e variáveis de

ambiente
.[Link]
.[Link]
.env

No exemplo acima, o arquivo “.gitignore” vai literalmente ignorar

esses tipos de arquivos, diretórios e formatos de arquivo de serem
rastreados pelo git.

Press enter or click to view image in full size

fonte: Visual Studio Marketplace — link

 Staging Area (Staged State)

Nesse estágio, ele lida com quais arquivos vão entrar no
commit, quais não vão entrar no commit e quais precisam ser
removidas no commit caso você tenha adicionado
acidentalmente.

git add nome_do_arquivo.py # adiciona especificamente esse arquivo

git add . # adiciona todos os arquivos para o commit
git reset remove_esse_arquivo_mesmo.py # caso tenha adicionado
um arquivo indesejado, remove ele da lista para não estar no commit

 Local Repository (Committed State)

Depois que é realizado as adições de arquivos no Staging Area,
você precisará realizar o commit que representa um “snapshot”
(captura de um momento específico) do projeto

git commit -m "<tipo>[escopo específico]: <descrição>"

# por exemplo
git commit -m "feat(balanceador): adicionado nova função de cálculo
de dados de sensores"
git log # Visualiza o histórico de commit

Por questão de boas práticas, quando se trabalha numa equipe,

sempre siga um padronização de commits, facilitando comunicação
entre os desenvolvedores e mantenedores do projeto. Por exemplo,
geralmente sigo por meio desse site de padronização: Conventional
Commits.

 Remote Repository (Pushed State)

Repositório remoto é a localização central (por exemplo, Github,
GitLab e BitBucket) onde a equipe, o usuário, a comunidade ou
a empresa possam colaborar referente ao projeto. Depois que o
projeto passa pelo(s) commit(s) e, em seguida, é realizado o “
git push”, o repositorio remoto mais atualizado é acessado
pelos membros que tenham acesso ao repositório na plataforma
(como Github, GitLab e BitBucket).
Nessa etapa, principais comandos são:

git push origin nome-da-branch # Realiza o upload das commits

realizadas localmente para o repositório remoto
git pull origin nome-da-branch # Realiza o fetch e merge do
repositório remoto
git clone url-do-repositório # Copia o repositório remoto para o
diretório local

Segue abaixo o resumo dos comandos de acordo com o estágio do Git

Lifecycle:

Press enter or click to view image in full size

fonte: w3school — link

3.1 Verificando o estado atual

Voltando ao projeto, de forma direta, vamos a passo a passo.

Primeiro, veja o estado dos seus arquivos:

git status

Esse comando mostra quais arquivos foram modificados, quais estão

prontos para commit e quais não estão sendo rastreados.

3.2 git add

Adiciona arquivos à área de staging, preparando-os para commit:

git add nome_do_arquivo.txt

Ou se quiser adicionar todos os arquivos modificados de uma vez:

git add .

A área de staging funciona como um “pré-commit”, você escolhe o

que será incluído no próximo snapshot.

3.3 git commit

Uma vez que os arquivos estejam no staging, crie um commit:

git commit -m "<tipo>(escopo específico): <descrição>"

# Por exemplo
git commit -m "doc(sql): documentado e esclarecido as principais
estruturas de queries de SQL utilizadas no projeto."

Cada commit salva um conjunto de alterações permanente no

histórico de versões.

Press enter or click to view image in full size

fonte: StackOverflow — link

4. Navegando e Trabalhando com Branches

Um dos maiores diferenciais do Git é o suporte robusto para

branches aos quais são “linhas” de desenvolvimento independentes.

Como recomendação, principalmente se você estiver desenvolvendo

um projeto com uma equipe, comunidade e/ou responsáveis de uma
empresa, precisa seguir padrões de nomeação das branches também,
facilitando a comunicação entre as equipes, recomendo a leitura
neste artigo: Conventional Branch

4.1 Criar e alternar entre branches

Criar um novo branch:

git branch nova-feature

# Por exemplo
git branch feat/add-login-page
git branch hotfix/change-cryptographic-hash-function

Alternar e acessar essa nova branch:

git checkout nova-feature

# Por exemplo
git checkout feat/add-login-page # Nesse momento você acessa a
branch chamada "feat/add-login-page"
git checkout fix/header-ui # Nesse momento você acessa a branch
chamada "fix/header-ui"

Ou em um único comando criar e trocar no mesmo comando:

git checkout -b nova-feature

# Nesse caso, ele primeiro cria a branch "nova-feature" e, em
seguida, acessa essa branch recém criada.

# Por exemplo
git checkout -b feat/login-page-new-ui
git checkout -b chore/update-dependencies

Branches permitem desenvolver funcionalidades de forma isolada

sem impactar o ramo principal (main ou master).

Por esses motivos, é importante trabalhar com o projeto, entender

como separar cada etapa de atualização (podendo ser adição de nova
funcionalidade, correção de bug, …) e, por fim, separar e identificar
cada branch com suas respectivas responsabilidades e
funcionalidades.

4.2 Juntar branches com merge

Depois de trabalhar no branch declarado e estar tudo pronto, você

pode mesclar mudanças de volta ao branch principal:

# Primeiro você volta na branch principal

git checkout main
# Depois você declara qual a branch alvo para ser mesclado com a
principal
# Obs: Branch alvo são as branch onde você realizou:
# Atualização, Correção, Documentação e entre outros.
git merge nova-feature

Recapitulando, os comandos acima mostra os passos que incorpora

as alterações realizadas na branchnova-feature a branchmain.

5. Trabalhando com Repositórios Remotos

Em projetos colaborativos, normalmente você sincroniza seu trabalho

com um repositório remoto.

5.1 git push

Esse comando envia seus commits locais para o repositório remoto,

principalmente na branch main:
git push origin main

# Caso você queira enviar os commits para outra branch,

# saiba que você precisa estar nela primeiro.
git push origin feat/login-system
git push origin hotfix/cript-hash

Há parâmetro com o nome “origin”, ele identifica que você está

realizando modificações a partir do nome padrão do repositório.

git push origin main

5.2 git pull

Para integrar mudanças remotas no seu branch atual:

git pull origin main

Esse comando combina dois passos: fetch (baixa dados remotos)

e merge (integra as alterações).

O que é um branch do Git?

No Git, um diretório branché como um espaço de trabalho separado

onde você pode fazer alterações e testar novas ideias sem afetar o
projeto principal. Pense nele como um "universo paralelo" para o seu
código.

Por que usar ramificações?

Os branches permitem que você trabalhe em diferentes partes de um

projeto, como novos recursos ou correções de bugs, sem interferir no
branch principal.

Motivos comuns para criar uma ramificação

 Desenvolvendo uma nova funcionalidade

 Corrigindo um bug

 Experimentando com ideias

Exemplo: Com e sem Git

Digamos que você tenha um projeto grande e precise atualizar o

design dele.

Como isso funcionaria sem e com Git:

Sem Git:

 Faça cópias de todos os arquivos relevantes para evitar afetar a

versão em produção.

 Comece a trabalhar no projeto e descubra que o código

depende de código em outros arquivos, que também precisam
ser alterados!

 Faça também cópias dos arquivos dependentes. Certifique-se

de que cada dependência de arquivo faça referência ao nome
de arquivo correto.

 URGENTE! Há um erro não relacionado em outra parte do

projeto que precisa ser corrigido o mais rápido possível!

 Salve todos os seus arquivos, anotando os nomes das cópias

em que você estava trabalhando.

 Trabalhe no erro não relacionado e atualize o código para

corrigi-lo.

 Volte ao projeto e termine o trabalho lá.

 Copie o código ou renomeie os arquivos para que o design

atualizado esteja presente na versão publicada.

 (Duas semanas depois, você percebe que o erro não

relacionado não foi corrigido na nova versão do projeto porque
você copiou os arquivos antes da correção)

Com Git:

 Com uma nova ramificação chamada new-design, edite o

código diretamente sem afetar a ramificação principal.

 URGENTE! Há um erro não relacionado em outra parte do

projeto que precisa ser corrigido o mais rápido possível!

 Crie uma nova ramificação a partir do projeto principal

chamada small-error-fix.

 Corrija o erro não relacionado e mescle a branch small-error-fix

com a branch principal.
  Você retorna à filial de novo design e termina o trabalho lá.

 Faça o merge da branch new-design com a branch main (você

receberá um alerta sobre a pequena correção de erro que
estava faltando).

Os branches permitem que você trabalhe em diferentes partes de um

projeto sem afetar o branch principal.

Quando o trabalho estiver concluído, uma ramificação pode ser

mesclada com o projeto principal.

Você pode até mesmo alternar entre ramificações e trabalhar em

projetos diferentes sem que eles interfiram uns nos outros.

O sistema de ramificação (branching) no Git é muito leve e rápido!

Criando uma nova ramificação

Digamos que você queira adicionar um novo recurso. Você pode criar
uma nova ramificação para isso.

Vamos adicionar alguns novos recursos à nossa [Link]ágina.

Estamos trabalhando em nosso repositório local e não queremos

perturbar ou possivelmente danificar o projeto principal.

Então criamos um novo branch:

Exemplo

git branch hello-world-images

Agora criamos um novo branchchamado " hello-world-images"

Lista de todas as filiais

Vamos confirmar que criamos um novo branch.

Para visualizar todas as ramificações do seu repositório, use:

Exemplo

git branch

hello-world-images

* master
Podemos ver a nova ramificação com o nome "hello-world-images",
mas o *texto ao lado masterespecifica que estamos atualmente
nela branch.

Alternando entre ramos

checkouté o comando usado para verificar um branch.

Movendo-nos do estado atual branchpara o especificado no final do

comando:

Exemplo

git checkout hello-world-images

Switched to branch 'hello-world-images'

Agora você pode trabalhar em sua nova ramificação sem afetar a

ramificação principal.

Trabalhar em uma filial

Agora migramos nosso espaço de trabalho atual da branch master

para a nova branch. branch

Abra seu editor favorito e faça algumas alterações.

Neste exemplo, adicionamos uma imagem (img_hello_world.jpg) à

pasta de trabalho e uma linha de código no [Link]:

Exemplo

<!DOCTYPE html>
<html>
<head>
<title>Hello World!</title>
<link rel="stylesheet" href="[Link]">
</head>
<body>

<h1>Hello world!</h1>
<div><img src="img_hello_world.jpg" alt="Hello World from Space"
style="width:100%;max-width:960px"></div>
<p>This is the first file in my new Git Repo.</p>
<p>A new line in our file!</p>
</body>
</html>

Fizemos alterações em um arquivo e adicionamos um novo arquivo no

diretório de trabalho (mesmo diretório do arquivo
original main branch).

Agora verifique o status da corrente branch:

Exemplo

git status

On branch hello-world-images

Changes not staged for commit:

(use "git add ..." to update what will be committed)

(use "git restore ..." to discard changes in working directory)

modified: [Link]

Untracked files:

(use "git add ..." to include in what will be committed)

img_hello_world.jpg

no changes added to commit (use "git add" and/or "git commit -a")

Então vamos analisar o que acontece aqui:

 Houve alterações no nosso arquivo [Link], mas o arquivo

ainda não está preparado para publicação. commit

 img_hello_world.jpgnão é tracked

Portanto, precisamos adicionar ambos os arquivos ao ambiente de

teste para isso branch:

Exemplo

git add --all

Usar --allnomes de arquivos individuais em vez de nomes de arquivos

individuais fará com que todos os arquivos alterados (novos,
modificados e excluídos) sejam colocados na área de
preparação .

Verifique o statusseguinte branch:

Exemplo

git status

On branch hello-world-images

Changes to be committed:

(use "git restore --staged ..." to unstage)

new file: img_hello_world.jpg

modified: [Link]

Estamos satisfeitos com as nossas alterações. Por isso, vamos

implementá-las da seguinte forma branch:

Exemplo

git commit -m "Added image to Hello World"

[hello-world-images 0312c55] Added image to Hello World

2 files changed, 1 insertion(+)

create mode 100644 img_hello_world.jpg

Agora temos um novo branch, que é diferente do mestre branch.

Nota: Usar a -bopção `on` checkoutcriará uma nova ramificação e,

caso ela não exista, o usuário será direcionado para ela.

Alternando entre ramos

Agora vamos ver como é rápido e fácil trabalhar com diferentes

ramificações, e como isso funciona bem.

Atualmente estamos na branch hello-world-images. Adicionamos uma

imagem a esta branch, então vamos listar os arquivos no diretório
atual:

Exemplo

ls

[Link] [Link] img_hello_world.jpg [Link]

Podemos ver o novo arquivo img_hello_world.jpge, se abrirmos o

arquivo HTML, veremos que o código foi alterado. Tudo está como
deveria estar.
Agora, vamos ver o que acontece quando mudamos de branch
paramaster

Exemplo

git checkout master

Switched to branch 'master'

A nova imagem não faz parte desta ramificação. Liste novamente os

arquivos no diretório atual:

Exemplo

ls

[Link] [Link] [Link]

img_hello_world.jpgNão está mais lá! E se abrirmos o arquivo HTML,

podemos ver que o código voltou ao que era antes da alteração.

Viu como é fácil trabalhar com branches? E como isso permite que
você trabalhe em coisas diferentes?

Departamento de Emergência

Agora imagine que ainda não terminamos com as imagens hello-

world, mas precisamos corrigir um erro na branch master.

Não quero mexer diretamente no branch master, e também não

quero mexer no hello-world-images, já que ele ainda não está pronto.

Então criamos uma nova filial para lidar com a emergência:

Exemplo

git checkout -b emergency-fix

Switched to a new branch 'emergency-fix'

Agora que criamos uma nova branch a partir da master e mudamos

para ela, podemos corrigir o erro com segurança sem afetar as outras
branches.

Vamos corrigir nosso erro imaginário:

Exemplo

<!DOCTYPE html>
<html>
<head>
<title>Hello World!</title>
<link rel="stylesheet" href="[Link]">
</head>
<body>

<h1>Hello world!</h1>
<p>This is the first file in my new Git Repo.</p>
<p>This line is here to show how merging works.</p>

</body>
</html>

Fizemos alterações neste arquivo e precisamos enviar essas

alterações para a branch principal.

Verifique o status:

Exemplo

git status

On branch emergency-fix

Changes not staged for commit:

(use "git add ..." to update what will be committed)

(use "git restore ..." to discard changes in working directory)

modified: [Link]

no changes added to commit (use "git add" and/or "git commit -a")

Prepare o arquivo e confirme:

Exemplo

git add [Link]

git commit -m "updated [Link] with emergency fix"

[emergency-fix dfa79db] updated [Link] with emergency fix

1 file changed, 1 insertion(+), 1 deletion(-)

Agora temos uma correção pronta para a branch master e precisamos

mesclar as duas branches.

Excluindo um ramo

Quando terminar de usar uma ramificação, você pode excluí-la:

Exemplo

git branch -d hello-world-images

Isso exclui a ramificação com o nome especificado hello-world-

images(caso já tenha sido mesclada).

Melhores práticas para trabalhar com agências

 Use nomes de ramificação claros e descritivos

(como feature/login-pageou bugfix/header-crash).

 Mantenha cada ramificação focada em um único propósito ou

funcionalidade.

 Incorpore regularmente as alterações da ramificação principal

para manter sua ramificação atualizada.

 Exclua os branches que não são mais necessários para manter

seu repositório organizado.

Exemplos práticos

 Renomear uma ramificação: git branch -m old-name new-

name

 Liste todas as filiais: git branch

 Trocar de ramo: git checkout branch-name ougit switch

branch-name

 Excluir uma ramificação (não mesclada): git branch -D

branch-name

 Veja em qual filial você está: git status

Solução de problemas

Se você não vir suas alterações na ramificação principal, lembre-se:

as alterações em uma ramificação permanecem lá até que você as
mescle.

Ao excluir uma branch, certifique-se de que ela tenha sido mesclada

primeiro. Se você tentar excluir uma branch que não foi mesclada, o
Git impedirá a operação.
Para forçar a exclusão de um branch não mesclado, use git branch -D
branch-name.