Como citar este material:

PIVOTTO, Carlos. Introdução ao Git e GitHub. Rio de Janeiro: FGV, 2024.

Todos os direitos reservados. Textos, vídeos, sons, imagens, gráficos e demais componentes
deste material são protegidos por direitos autorais e outros direitos de propriedade intelectual, de
forma que é proibida a reprodução no todo ou em parte, sem a devida autorização.
INTRODUÇÃO
O trabalho colaborativo desempenha papel crucial no cotidiano de
pessoas desenvolvedoras de software, analistas de sistemas, engenheiras,
cientistas de dados e diversas outras funções na computação. Além disso, a
gestão eficiente de um trabalho de desenvolvimento em equipes demanda
uma igualmente eficiente capacidade de controlar e versionar os ativos
produzidos, como código, documentação e arquivos de configuração.
Nesse contexto, é essencial utilizar ferramentas que unam funcionalidades
que proporcionem colaboração e versionamento dos ativos.
Trabalharemos neste curso com Git, um sistema de controle de
versão distribuído que oferece um método eficiente para rastrear,
gerenciar e coordenar alterações no código-fonte ao longo do tempo,
tanto em projetos individuais quanto em colaboração; e com o GitHub,
uma plataforma de hospedagem baseada em nuvem, para controle de
versão e colaboração, que utiliza o Git como o seu sistema de controle de
versão subjacente, fornecendo uma infraestrutura poderosa para
armazenar, compartilhar e colaborar em projetos de código-fonte.
Ao estudar este curso, você aprenderá a utilizar controle de versão
com Git, compreendendo os conceitos fundamentais do controle de
versão, os comandos básicos do git, a capacidade de rastrear alterações e a
criação de um histórico completo de desenvolvimento. Além disso, terá
uma visão do uso prático do GitHub, explorando as suas funcionalidades,
os repositórios remotos e a colaboração em equipe.
SUMÁRIO
MÓDULO I – INTRODUÇÃO AO GIT ...................................................................................................... 7

CONTROLE DE VERSÃO ..................................................................................................................... 7

Colaboração ................................................................................................................................ 8
Benefícios do controle de versão e da colaboração ............................................................. 8
SURGIMENTO DO GIT ........................................................................................................................ 8
Ferramentas de controle de versão anteriores ao Git.......................................................... 9
SURGIMENTO DO GITHUB ................................................................................................................ 9
Diferenças entre Git e GitHub ................................................................................................ 10
Alternativas ao GitHub ............................................................................................................ 10
INSTALAÇÃO DO GIT ........................................................................................................................ 11
Windows .................................................................................................................................... 11
macOS ....................................................................................................................................... 11
Linux .......................................................................................................................................... 11

MÓDULO II – CONCEITOS E COMANDOS BÁSICOS DO GIT ............................................................. 13

INICIALIZAÇÃO DE UM REPOSITÓRIO GIT ..................................................................................... 13

COMANDOS BÁSICOS: ADD, COMMIT, STATUS E LOG ................................................................... 14
Comando git add ...................................................................................................................... 14
Configuração de usuário local ............................................................................................... 14
Comando git commit ................................................................................................................ 15
Comando git status................................................................................................................... 15
Comando git log........................................................................................................................ 15
VISUALIZAÇÃO E NAVEGAÇÃO NO HISTÓRICO DE COMMITS ..................................................... 16
DESFAZIMENTO DE ALTERAÇÕES COM REVERT, RESET E CHECKOUT ......................................... 17
Comando git revert ................................................................................................................... 17
Comando git checkout .............................................................................................................. 18
Comando git reset .................................................................................................................... 18
CRIAÇÃO E GERENCIAMENTO DE BRANCHES ................................................................................ 18
Comando git branch ................................................................................................................. 19
Alternância entre branches ..................................................................................................... 19

MÓDULO III – TRABALHO COM REPOSITÓRIOS REMOTOS NO GITHUB ........................................ 21

CRIAÇÃO DE UM USUÁRIO NO GITHUB ........................................................................................ 21

Passo a passo para a criação de uma conta no GitHub ..................................................... 21
Opcional: instalação do GitHub Desktop .............................................................................. 23
CONFIGURAÇÃO DE UM REPOSITÓRIO REMOTO NO GITHUB .................................................. 24
Criação de um novo repositório no GitHub diretamente no GitHub ............................... 24
 Criação de um novo repositório no GitHub por linha de comando no computador local
.................................................................................................................................................... 25
Diferenças entre repositórios privados e compartilhados ................................................ 26
CLONAGEM DE UM REPOSITÓRIO EXISTENTE NO GITHUB........................................................ 26
Clonagem de um repositório por linha de comando ......................................................... 26
Clonagem de um repositório com o GitHub Desktop ........................................................ 27
SINCRONIZAÇÃO DE ALTERAÇÕES COM PUSH E PULL NO GITHUB .......................................... 28
Push ............................................................................................................................................ 28
Pull.............................................................................................................................................. 28
Sincronizando alterações com push com a linha de comando do Git .............................. 29
Sincronização de alterações com o GitHub Desktop .......................................................... 31
Atualização do repositório local com o pull ......................................................................... 31
TÓPICO AVANÇADO: RESOLUÇÃO DE CONFLITOS DE MERGE NO GITHUB ............................. 32
Resolução de conflitos de merge com a linha de comando do Git ................................... 32
Resolução de conflitos de merge com o GitHub Desktop................................................... 33

MÓDULO IV – GITFLOW....................................................................................................................... 35

BRANCHES DE DESENVOLVIMENTO (DEVELOP) ............................................................................. 35

BRANCHES DE RECURSOS (FEATURES) ............................................................................................. 36
BRANCHES DE LANÇAMENTO (RELEASE) ......................................................................................... 36
BRANCHES DE CORREÇÕES RÁPIDAS (HOTFIX) .............................................................................. 37
FLUXO GERAL DO GITFLOW............................................................................................................ 38

APÊNDICE – RESUMO GERAL DOS COMANDOS GIT ......................................................................... 40

GIT STATUS ......................................................................................................................................... 40

GIT BRANCH ....................................................................................................................................... 40
GIT FETCH ........................................................................................................................................... 41
GIT PULL ............................................................................................................................................. 41
GIT CHECKOUT ................................................................................................................................... 41
GIT ADD .............................................................................................................................................. 41
GIT COMMIT ....................................................................................................................................... 42
GIT PUSH ............................................................................................................................................ 42
GIT LOG .............................................................................................................................................. 42
GIT REBASE ......................................................................................................................................... 43
GIT STASH ........................................................................................................................................... 43
GIT RESET ............................................................................................................................................ 43

CONCLUSÃO ......................................................................................................................................... 45

REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................................... 46

PROFESSORES-AUTORES ..................................................................................................................... 47
MÓDULO I – INTRODUÇÃO AO GIT

Neste curso, aprenderemos a utilizar o GitHub, a mais popular ferramenta para controlar
versões de código e outros artefatos que compõem um software, mas, primeiro, precisamos
entender o que é o GitHub, como ele surgiu a partir do Git, e o que significa controle de versão
em projetos de software.

Controle de versão
O controle de versão é o mecanismo pelo qual as alterações feitas em um projeto de software
são rastreadas ao longo do tempo. Ele registra cada modificação realizada em um arquivo ou
conjunto de arquivos, permitindo que você acompanhe o histórico completo de desenvolvimento.
Com o controle de versão, é possível responder a perguntas como:
 Quais alterações foram feitas em determinado momento?
 Quem fez essas alterações?
 Por que essas alterações foram feitas?
 Como posso restaurar uma versão anterior do código?

Além disso, o controle de versão permite que você reverta modificações indesejadas,
experimente diferentes abordagens ou ramificações de desenvolvimento e trabalhe de forma mais
segura, uma vez que sempre haverá um backup de todas as versões anteriores dos artefatos.
Colaboração
A colaboração eficaz é fundamental para o sucesso de um projeto de software. Ao permitir
que vários desenvolvedores trabalhem juntos em um código compartilhado, a colaboração promove
uma divisão de tarefas mais eficiente, incentiva a revisão e o aprendizado de outros membros da
equipe, bem como facilita a resolução de problemas complexos.
Com o controle de versão e as plataformas de hospedagem de código, como o GitHub,
desenvolvedores podem colaborar de maneira eficiente, mesmo que estejam geograficamente dispersos.
Além disso, podem compartilhar o seu trabalho, revisar as alterações das outras pessoas, discutir
problemas específicos por meio de issues e mesclar as suas contribuições em um código finalizado.
A colaboração também é valiosa para projetos de código aberto, nos quais desenvolvedores
de todo o mundo podem contribuir e melhorar o software. Isso cria uma comunidade engajada e
diversificada de colaboradores, resultando em um produto mais robusto e inovador.

Benefícios do controle de versão e da colaboração

Ao adotar o controle de versão e a colaboração no desenvolvimento de software, você e a sua
equipe podem desfrutar de diversos benefícios, tais como:
 histórico completo de alterações, facilitando a auditoria e a investigação de problemas;
 rastreamento de responsabilidades e atribuição de contribuições individuais;
 recuperação rápida de versões anteriores funcionais em caso de problemas;
 paralelismo de desenvolvimento, permitindo que diferentes recursos sejam trabalhados
simultaneamente em branches separadas;
 revisões de código mais eficazes, com comentários, sugestões e melhorias;
 aumento da transparência e da colaboração dentro da equipe.

� O controle de versão e a colaboração são fundamentais para manter o desenvolvimento

de software organizado, eficiente e orientado para o trabalho em equipe. Eles permitem que você
acompanhe e controle as alterações, trabalhe de forma colaborativa e obtenha um produto final de
alta qualidade.

Surgimento do Git
O Git, um sistema de controle de versão distribuído amplamente utilizado, foi criado por
Linus Torvalds em 2005. Linus é mais conhecido como o criador do kernel Linux, um dos sistemas
operacionais de código aberto mais populares do mundo. Ele criou o Git para ajudar a gerenciar o
desenvolvimento colaborativo do kernel Linux e resolver os desafios que ele e a sua equipe
enfrentavam com as ferramentas de controle de versão existentes na época.

8
Ferramentas de controle de versão anteriores ao Git
Antes do Git, outras ferramentas de controle de versão eram usadas, mas cada uma tinha as
suas limitações. Algumas das ferramentas mais notáveis incluíam:
 Concurrent Versions System (CVS) – foi uma das primeiras ferramentas populares de
controle de versão. No entanto, tinha limitações significativas, como a falta de suporte
para branches eficientes e a incapacidade de funcionar bem com projetos distribuídos;
 Subversion (SVN) – surgiu como uma alternativa ao CVS e introduziu melhorias
significativas, como a capacidade de mover diretórios e arquivos e a habilidade de rastrear
metadados de diretórios. No entanto, ainda era um sistema centralizado, o que limitava o
seu desempenho em cenários distribuídos;
 Mercurial – assim como o Git, é um sistema de controle de versão distribuído. Surgiu
aproximadamente na mesma época do Git e compartilha muitos conceitos semelhantes.
Ambos foram influenciados pela necessidade de melhorar o controle de versão em projetos
de código aberto e colaborativos.

Surgimento do GitHub
O GitHub foi fundado por Tom Preston-Werner, Chris Wanstrath e P. J. Hyett em 2008.
Eles viram a necessidade de uma plataforma que fosse fácil de usar e que permitisse aos
desenvolvedores hospedar, colaborar e compartilhar código de maneira eficaz. O GitHub usou o
Git como o seu sistema de controle de versão subjacente, o que o tornou altamente compatível com
o Git e, ao mesmo tempo, forneceu recursos adicionais de colaboração.
O GitHub se tornou rapidamente uma plataforma central para o desenvolvimento de software de
código aberto, permitindo que desenvolvedores de todo o mundo colaborassem em projetos de maneira
eficiente. Ele também ofereceu recursos como pull requests, rastreamento de issues, integração contínua
e hospedagem gratuita para projetos de código aberto, o que o tornou extremamente popular.
Hoje, o Git e o GitHub são amplamente adotados em toda a comunidade de
desenvolvimento de software, desempenhando um papel crucial no controle de versão, na
colaboração e no compartilhamento de código em projetos de todos os tamanhos e em diversas
áreas da indústria de tecnologia.
� Git é um sistema de controle de versão distribuído, projetado para lidar com projetos
de qualquer tamanho com rapidez e eficiência. Foi criado por Linus Torvalds em 2005, com o
objetivo de fornecer uma solução escalável e flexível para o gerenciamento de código-fonte.
Permite que os desenvolvedores acompanhem as alterações nos seus arquivos, revertam
modificações, criem branches independentes para desenvolvimento paralelo e realizem merge de
alterações de forma controlada.

9
 � GitHub, por sua vez, é uma plataforma de hospedagem de código-fonte baseada em
nuvem. Utiliza o Git como o sistema de controle de versão subjacente e oferece recursos adicionais
para facilitar a colaboração entre desenvolvedores. Permite que os desenvolvedores compartilhem
os seus projetos, trabalhem em equipe, realizem revisões de código, gerenciem issues e muito mais.
É amplamente utilizado tanto por projetos open source quanto por empresas privadas.

Diferenças entre Git e GitHub

É importante destacar que o Git e o GitHub são conceitos diferentes, embora frequentemente
mencionados em conjunto. O Git é o sistema de controle de versão em si, enquanto o GitHub é
uma plataforma que utiliza o Git para hospedar projetos de software.
O Git permite que você gerencie o seu código e o histórico de versões localmente na sua
máquina, enquanto o GitHub fornece um ambiente on-line para compartilhar e colaborar em
projetos Git. No GitHub, você pode hospedar os seus repositórios Git remotamente, permitindo
que outros desenvolvedores acessem, contribuam e colaborem no seu código.

Alternativas ao GitHub
O GitHub é provavelmente a plataforma mais popular para hospedagem de projetos Git.
Apesar disso, existem alternativas, tais como:
 GitLab – é uma plataforma de desenvolvimento colaborativo que oferece recursos
semelhantes aos do GitHub. Pode ser instalado em um servidor próprio ou utilizado como
serviço na nuvem;
 Bitbucket – é uma plataforma de hospedagem de projetos que suporta tanto o Git quanto
o Mercurial, outro sistema de controle de versão distribuído. É amplamente utilizado por
equipes que trabalham com a pilha de ferramentas da Atlassian;
 Azure DevOps – anteriormente conhecido como Visual Studio Team Services, é uma
plataforma de desenvolvimento colaborativo oferecida pela Microsoft. Fornece recursos
para gerenciamento de código, compilação, teste e implantação.

Independentemente da plataforma utilizada, o importante é entender os conceitos por trás

do Git, pois são amplamente utilizados e fornecem uma base sólida para o controle de versão e a
colaboração no desenvolvimento de software.

10
Instalação do Git
Siga os passos abaixo, a depender do seu sistema operacional – Windows, macOS, Linux –,
para instalar o Git no seu computador:

Windows
Estas são as etapas para a instalação do Git no Windows:
1. Acesse https://git-scm.com/downloads.
2. Será exibida a página de download do Git. Verifique se a versão correta do Windows
está selecionada (32 bits ou 64 bits) e clique no botão de download.
3. Após o download, execute o instalador do Git. Siga as instruções do assistente de
instalação, aceitando os termos de uso e mantendo as configurações padrão, a menos
que você tenha algum requisito específico.
4. Durante a instalação, você pode escolher um editor de texto padrão para o Git, como
o Vim ou o Notepad++. Se você já tiver um editor de texto preferido, pode selecioná-
lo ou simplesmente deixar a opção padrão.
5. Quando a instalação estiver concluída, abra o prompt de comando do Git Bash ou o
Git GUI a partir do menu Iniciar. Isso confirma que a instalação foi bem-sucedida.

macOS
A instalação do Git no macOS pode ser feita seguindo estas etapas:
1. Acesse https://git-scm.com/downloads.
2. Será exibida a página de download do Git. Clique no link de download para macOS.
3. Após o download, abra o pacote de instalação (.dmg). Uma janela será aberta.
4. Siga as instruções do assistente de instalação, aceitando os termos de uso e mantendo
as configurações padrão, a menos que você tenha algum requisito específico.
5. Quando a instalação estiver concluída, você pode verificar se o Git foi instalado
corretamente abrindo o terminal e digitando o comando git --version. Isso exibirá a
versão do Git instalada no seu sistema.

Linux
A instalação do Git em distribuições Linux pode variar um pouco dependendo da distribuição
específica. Aqui está um exemplo de como instalar o Git em algumas distribuições populares:

11
Ubuntu ou Debian
Abra um terminal e execute o seguinte comando:

sudo apt-get update

sudo apt-get install git

Fedora ou CentOS
Abra um terminal e execute o seguinte comando:

sudo dnf install git

Após a conclusão do processo de instalação, você pode verificar se o Git foi instalado
corretamente digitando o comando git --version no terminal.
Com o Git instalado, vamos começar a explorar os conceitos básicos do Git, incluindo a
inicialização de um repositório e os comandos essenciais para o gerenciamento de versões.

12
MÓDULO II – CONCEITOS E COMANDOS
BÁSICOS DO GIT

Para uma experiência agnóstica de linguagens de programação ou mesmo de experiência

prévia em programação, trabalharemos os nossos exemplos com um artefato fictício, chamado
“notas.txt”, que nada mais será que um documento de texto. O Git pode ser utilizado para versionar
qualquer tipo de arquivo, inclusive documentos de texto simples. No limite, arquivos de código
também são apenas arquivos de texto com extensões específicas.
No início deste texto, vamos supor que existe um arquivo “notas.txt” que está vazio.

Inicialização de um repositório Git

Após instalar o Git no seu computador, o primeiro passo é inicializar um repositório Git para
começar a versionar o seu arquivo “notas.txt”. Um repositório Git é basicamente um diretório que
contém todos os arquivos e o histórico de versões do seu projeto.
Para inicializar um repositório Git, siga os passos abaixo:
1. Abra o terminal ou prompt de comando no diretório onde o seu arquivo “notas.txt” está
localizado. Por exemplo, se o arquivo está na pasta “Documentos”, navegue até essa pasta
usando comandos de navegação do sistema operacional. Uma vez dentro do diretório
correto, digite o seguinte comando no terminal:

git init

2. Isso criará um novo repositório Git no diretório atual. O Git agora estará pronto para
rastrear as alterações feitas no arquivo “notas.txt”. Verifique se o repositório foi
inicializado com sucesso executando o seguinte comando:

git status
 3. O comando git status exibe informações sobre o estado atual do repositório. No
momento, ele deve mostrar que não há nada para ser confirmado (commit), pois ainda
não adicionamos o arquivo “notas.txt” ao controle de versão.

Agora que o repositório Git foi inicializado, podemos prosseguir para os comandos básicos
do Git para gerenciar as alterações no nosso arquivo “notas.txt”.

Comandos básicos: add, commit, status e log

Agora que temos o repositório Git criado, vamos aprender alguns comandos básicos para
gerenciar as alterações no nosso arquivo “notas.txt”.

Comando git add

Adicionando arquivos ao controle de versão: para começar a rastrear as alterações no nosso
arquivo “notas.txt”, utilizamos o comando git add. No terminal, execute o seguinte comando:

git add notas.txt

Isso informa ao Git para incluir o arquivo “notas.txt” ao controle de versão. Esse processo é
chamado de staging, e é uma etapa intermediária do fluxo de trabalho no Git, que antecede o commit,
que será tratado adiante, que, por sua vez, é o registro definitivo das mudanças no repositório.
É possível adicionar diversos arquivos simultaneamente, da seguinte forma:

git add notas.txt pasta1/arquivo1.ext1 notas-rascunho.docx pasta2/arquivo2.ext2

Configuração de usuário local

Para utilizar o Git localmente, você precisará identificar-se com um e-mail e um nome de
usuário. Para isso, utilize os seguintes comandos:

git config --global user.email “[email protected]”

em que “[email protected]” é um e-mail. Em seguida, crie um nome de usuário para esse

usuário com o comando:

git config --global user.name “usuario”

em que “usuario” é um nome qualquer. Com isso, você será capaz de executar comandos
como o git commit.

14
Comando git commit
Realizando um commit: o commit é o ato de confirmar as alterações no nosso repositório
Git. É uma forma de criar uma nova versão com um histórico de alterações. Para fazer um commit,
utilize o comando git commit. No terminal, execute o seguinte comando:

git commit -m “Adicionando arquivo de notas.txt”

Esse comando cria um novo commit com uma mensagem de descrição informada entre aspas.
A mensagem deve ser descritiva e indicar o propósito das alterações realizadas.
A partir de agora, o estado atual de “notas.txt” está versionado e pode ser recuperado a
qualquer momento. Novos commits podem ser produzidos. Suponha que editemos “notas.txt” para
adicionar o seguinte texto:

Lorem ipsum

Quando o arquivo for salvo e fechado, um novo commit pode ser realizado:

git add notas.txt

git commit -m “Lorem ipsum”

Comando git status

Verificando o status: o comando git status é útil para verificar o status do repositório em
relação às alterações. Execute-o no terminal para obter informações sobre arquivos modificados,
arquivos que foram adicionados ao commit e outras informações relevantes.

Comando git log

Visualizando o histórico de commits: o comando git log permite visualizar o histórico de
commits do repositório. Execute-o no terminal para obter uma lista de commits anteriores, incluindo
informações como autor, data e mensagem de cada commit.
Por exemplo, usar git log após o primeiro commit que realizamos retornará:

commit 6a14413ab5cd05d27d723547b6f75cb3ad39a51a (HEAD -> master)

Author: usuario <[email protected]>
Date: Tue Jun 13 20:49:52 2023 -0300

15
 Adicionando arquivo de notas.txt

Após o segundo commit, veremos:

commit 2b5a03a557018175fc287acf064a88397b52e53b (HEAD -> master)

Author: usuario <[email protected]>
Date: Tue Jul 13 20:57:08 2023 -0300

Lorem ipsum

commit 6a14413ab5cd05d27d723547b6f75cb3ad39a51a (HEAD -> master)

Author: usuario <[email protected]>
Date: Tue Jun 13 20:49:52 2023 -0300

Adicionando arquivo de notas.txt

Visualização e navegação no histórico de commits

Após realizar alguns commits, é importante visualizar e navegar pelo histórico de alterações do
seu repositório Git. Isso permite entender quais modificações foram feitas, quando e por quem:
 visualizando o histórico completo – o comando git log já mencionado anteriormente é
usado para visualizar o histórico completo de commits. Ele exibe informações detalhadas
sobre cada commit, como o autor, a data, a mensagem e um identificador exclusivo (hash);
 visualizando os detalhes de um commit específico – para visualizar os detalhes de um commit
específico, copie o identificador exclusivo do commit (hash) e execute o seguinte comando:

git show <hash_do_commit>

Substitua <hash_do_commit> pelo identificador real do commit que você deseja

visualizar. Isso exibirá as informações detalhadas desse commit em particular;

 navegando entre commits – o Git permite que você navegue entre diferentes commits do
seu histórico usando o comando git checkout. Por exemplo, se você quiser voltar para um
commit anterior, basta executar o seguinte comando:

git checkout <hash_do_commit>

Substitua <hash_do_commit> pelo identificador do commit desejado. Isso colocará o seu

repositório no estado exato em que estava no momento daquele commit.

16
Desfazimento de alterações com revert, reset e checkout
Às vezes, pode ser necessário desfazer alterações em um commit ou descartar alterações não
confirmadas. O Git fornece várias opções para realizar essas ações, como veremos a seguir.

Comando git revert

 Revertendo um commit: o comando git revert é usado para desfazer as alterações
introduzidas por um commit específico, criando um novo commit que desfaz as alterações
anteriores. Para reverter um commit, utilize o seguinte comando:

git revert <hash_do_commit>

Substitua <hash_do_commit> pelo identificador do commit que você deseja reverter. Por
exemplo, utilizando:

git checkout 6a14413ab5cd05d27d723547b6f75cb3ad39a51a

Veremos, no terminal, o retorno:

Note: switching to '6a14413ab5cd05d27d723547b6f75cb3ad39a51a'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may do so (now or later) by
using -c with the switch command. Example:

git switch -c <new-branch-name>

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 6a14413 Adicionando arquivo de notas.txt

17
 O arquivo “notas.txt” será revertido ao estado do hash
6a14413ab5cd05d27d723547b6f75cb3ad39a51a, que era o do arquivo vazio, antes da adição do
texto Lorem ipsum a ele.

Comando git checkout

 Descartando alterações não confirmadas: se você deseja descartar todas as alterações
feitas em um arquivo que ainda não foram adicionadas ao controle de versão, pode utilizar
o comando git checkout seguido do nome do arquivo. Por exemplo:

git checkout notas.txt

Isso descartará as alterações feitas no arquivo “notas.txt” e o restaurará para a versão mais
recente do último commit.

Comando git reset

 Resetando o repositório: o comando git reset é usado para reverter o estado do repositório
para um commit anterior, descartando todos os commits subsequentes. Isso pode ser útil
quando você deseja desfazer várias alterações.

Para realizar um reset, utilize o seguinte comando:

git reset <hash_do_commit>

Substitua <hash_do_commit> pelo identificador do commit para o qual você deseja redefinir
o repositório.
� Tenha muito cuidado ao utilizar esse comando, pois ele remove permanentemente as
alterações resetadas do histórico, por isso deve ser utilizado apenas como último recurso.

Criação e gerenciamento de branches

Em Git, uma branch – ou ramificação – é uma linha independente de desenvolvimento que
permite que desenvolvedores trabalhem em recursos ou correções de bugs de forma isolada do
código principal do projeto. Uma branch é essencialmente uma cópia do repositório em um
determinado ponto no tempo, permitindo que alterações sejam feitas de forma separada e sem afetar
diretamente o código do branch principal, geralmente chamado de master ou main. Quando
utilizamos git init, geramos uma branch principal chamada master, e outras podem ser criadas.

18
 As branches tornam o desenvolvimento colaborativo mais eficiente, pois diferentes membros
da equipe podem trabalhar em tarefas distintas sem conflitos. Cada branch tem a sua própria história
de commits, permitindo que os desenvolvedores acompanhem o progresso, testem novas
funcionalidades e corrijam problemas sem perturbar a estabilidade do projeto principal.
Uma vez que as alterações em uma branch são concluídas e testadas, é possível fundi-la de
volta ao branch principal, combinando as modificações realizadas com o código existente.

Comando git branch

 Criando uma nova branch: para criar uma nova branch, utilize o seguinte comando:

git branch <nome_da_branch>

Substitua <nome_da_branch> pelo nome que deseja dar à sua nova branch. Por exemplo, se
você quiser criar uma branch chamada “nova-feature”, execute o comando git branch nova-feature.

Alternância entre branches

 Alternando para uma branch específica: para alternar para uma branch existente, utilize
o comando git checkout seguido do nome da branch. Por exemplo:

git checkout <nome_da_branch>

Isso permitirá que você trabalhe na branch especificada e faça alterações independentes.

 Listando todas as branches: para listar todas as branches existentes no seu repositório,
execute o comando git branch. Isso mostrará todas as branches disponíveis e indicará em
qual delas você está atualmente.
 Merge de branches: o comando git merge é usado para combinar as alterações de uma
branch em outra. Por exemplo, se você quiser mesclar as alterações da branch “nova-
feature” na branch principal, você precisa estar na branch principal e executar o seguinte
comando:

git merge nova-feature

Isso combinará as alterações da branch “nova-feature” na branch atual.

Agora, vamos explorar o trabalho com repositórios remotos, incluindo a configuração de um
repositório remoto no GitHub e a sincronização de alterações com push e pull.

19
MÓDULO III – TRABALHO COM REPOSITÓRIOS
REMOTOS NO GITHUB

O GitHub é uma plataforma de hospedagem de código-fonte baseada em nuvem que utiliza o

Git como sistema de controle de versão. Antes de começarmos a trabalhar com repositórios remotos
no GitHub, é necessário criar uma conta de usuário no GitHub. Neste módulo, explicaremos como
criar um usuário no GitHub e como instalar o GitHub Desktop, uma interface gráfica para o Git.

Criação de um usuário no GitHub

Passo a passo para a criação de uma conta no GitHub
Figura 1 – GitHub: criação de conta

Fonte: elaborado pelo autor

 1. Acesse o site oficial do GitHub em https://github.com.
2. Na página inicial do GitHub, clique em “Sign up” (ou “Cadastrar-se”) no canto
superior direito.
3. Preencha as informações solicitadas no formulário, incluindo nome de usuário, endereço
de e-mail e senha. Você também pode inscrever-se em newsletters e receber atualizações
do GitHub.
4. Após preencher o formulário, clique em “Create account” (ou “Criar conta”). O GitHub
pode solicitar a verificação da sua conta por meio de um e-mail de confirmação.
5. Verifique o seu e-mail e siga as instruções para confirmar a sua conta.

Agora que criou a sua conta no GitHub, você poderá configurar um repositório remoto para
o versionamento do nosso arquivo “notas.txt”.

Figura 2 – GitHub: visão de um repositório

Fonte: elaborado pelo autor

22
Opcional: instalação do GitHub Desktop
O GitHub Desktop é uma interface gráfica para o Git que simplifica o trabalho com
repositórios Git no GitHub. Ele fornece uma maneira fácil de clonar, fazer commits e sincronizar
alterações com repositórios remotos, como o GitHub.

Figura 3 – GitHub Desktop: instalação

Fonte: GitHub Desktop

Siga estas instruções para instalar o GitHub Desktop:

1. Acesse o site oficial do GitHub Desktop em https://desktop.github.com.
2. Na página de download do GitHub Desktop, clique no botão de download
correspondente ao seu sistema operacional (Windows ou macOS).
3. Após o download, execute o instalador do GitHub Desktop e siga as instruções do
assistente de instalação.
4. Depois que a instalação for concluída, abra o GitHub Desktop e faça login com as
suas credenciais do GitHub: nome de usuário e senha.

23
 Agora, você tem uma conta no GitHub e possui o GitHub Desktop instalado no seu
computador. A seguir, veremos como configurar um repositório remoto no GitHub e como clonar
um repositório existente usando tanto a linha de comando do Git quanto o GitHub Desktop.

Configuração de um repositório remoto no GitHub

Após criar a sua conta no GitHub, você pode configurar um repositório remoto para hospedar
o seu projeto e versionar o arquivo “notas.txt“ nele. O GitHub oferece a opção de criar repositórios
privados e compartilhados. Nesta unidade, vamos explicar como configurar um repositório remoto
no GitHub – criando-o diretamente no GitHub ou por linha de comando no seu computador local
– e abordar as diferenças entre repositórios privados e compartilhados.

Criação de um novo repositório no GitHub diretamente no GitHub

Figura 4 – GitHub: criação de novo repositório

Fonte: elaborado pelo autor

24
 Para criar um novo repositório no GitHub diretamente na plataforma, siga estas etapas:
1. Faça login na sua conta do GitHub em https://github.com.
2. No canto superior direito da página inicial, clique no ícone “+” e selecione “New
repository” (ou “Novo repositório”).
3. Na página de criação de um novo repositório, forneça um nome para o repositório.
Por exemplo, você pode chamá-lo de “notas”.
4. Opcionalmente, você pode adicionar uma descrição para o repositório, tornando
mais fácil entender o propósito do projeto.
5. Escolha se deseja que o repositório seja público ou privado. Repositórios públicos são
visíveis para todos os usuários do GitHub, enquanto repositórios privados são
acessíveis apenas para você e as pessoas que você convida explicitamente.
Exploraremos mais sobre as diferenças entre repositórios privados e compartilhados
em seguida.
6. Você também pode inicializar o repositório com um arquivo ReadME.md, que é útil
para fornecer informações adicionais sobre o projeto. No entanto, essa etapa é opcional.
7. Clique em “Create repository” (ou “Criar repositório”) para criar o repositório
no GitHub.

Criação de um novo repositório no GitHub por linha de comando no

computador local
Você também pode criar um novo repositório no GitHub usando a linha de comando do Git
no seu computador local. Siga estas etapas:
1. Abra o terminal ou prompt de comando no diretório onde o seu arquivo “notas.txt” está
localizado. Certifique-se de que o diretório esteja configurado como um repositório Git,
conforme explicado na unidade “Inicialização de um repositório Git” deste material.
2. Execute o seguinte comando para adicionar o repositório remoto no GitHub:

git remote add origin <URL_do_repositório>

3. Substitua <URL_do_repositório> pela URL do repositório remoto que você deseja criar
no GitHub. Por exemplo:

git remote add origin <https://github.com/seu-usuario/notas.git>

4. Após adicionar o repositório remoto, você pode prosseguir com os comandos de adição,
commit e push que serão abordados adiante.

25
Diferenças entre repositórios privados e compartilhados
O GitHub oferece duas opções principais para a visibilidade de um repositório: público e privado.
É importante entender as diferenças entre eles para escolher a opção adequada para o seu projeto:
 repositórios públicos – são visíveis para qualquer usuário do GitHub. Isso significa que
qualquer pessoa pode visualizar, clonar e contribuir para o projeto. São adequados para
projetos de código aberto ou para quem deseja compartilhar o seu código com a
comunidade e permitir colaborações abertas;
 repositórios privados – são acessíveis apenas para você e as pessoas que você convida
explicitamente. São ideais para projetos comerciais ou para quem deseja manter o seu código
protegido e restrito a um grupo seleto de colaboradores. Ao usar um repositório privado, você
tem controle total sobre quem pode visualizar, clonar e contribuir para o projeto.

É importante observar que os repositórios privados no GitHub são pagos, enquanto os

repositórios públicos são gratuitos. O GitHub oferece planos de assinatura para repositórios
privados, dependendo das necessidades específicas do projeto e da equipe.
Ao criar um novo repositório, leve em consideração a natureza do projeto, a sua intenção de
colaboração e a segurança do código-fonte ao escolher entre um repositório público ou privado.
Agora que você configurou um repositório remoto no GitHub, vamos aprender a clonar um
repositório existente no GitHub tanto usando a linha de comando do Git quanto o GitHub Desktop.

Clonagem de um repositório existente no GitHub

Para trabalhar com um repositório existente no GitHub, você pode cloná-lo para o seu ambiente
local. Clonar um repositório permite que você faça uma cópia completa do projeto, incluindo todos os
arquivos e o histórico de versões. Nesta unidade, vamos aprender a clonar um repositório existente no
GitHub usando tanto a linha de comando do Git quanto o GitHub Desktop.

Clonagem de um repositório por linha de comando

Para clonar um repositório existente no GitHub usando a linha de comando do Git,
acompanhe os passos a seguir:
1. Abra o terminal ou prompt de comando no diretório em que deseja clonar o repositório.
Por exemplo, se você deseja clonar o repositório para a pasta “Documentos”, navegue até
essa pasta usando comandos de navegação do sistema operacional.
2. No GitHub, acesse o repositório que você deseja clonar. Clique no botão “Code” (ou
“Código”) verde para obter a URL do repositório.

26
 3. No terminal ou prompt de comando, execute o seguinte comando de clonagem,
substituindo <URL_do_repositório> pela URL que você copiou anteriormente:

git clone <URL_do_repositório>

Por exemplo:

git clone <https://github.com/usuario/repo.git>

4. O Git clonará o repositório para o diretório atual, criando uma nova pasta com o nome
do repositório. Aguarde até que o processo de clonagem seja concluído.

Agora, você tem uma cópia do repositório clonado no seu ambiente local. Você pode acessar
e trabalhar com os arquivos do projeto dentro dessa nova pasta.

Clonagem de um repositório com o GitHub Desktop

Se você preferir utilizar uma interface gráfica, como o GitHub Desktop, para clonar um
repositório existente, veja as instruções a seguir:
1. Abra o GitHub Desktop e faça login com as suas credenciais do GitHub, caso ainda não
tenha feito isso.
2. No menu superior, clique em “File” (ou “Arquivo”) e selecione “Clone repository” (ou
“Clonar repositório”).
3. Na janela “Clone a repository” (ou “Clonar um repositório”), selecione a aba “URL” e
cole a URL do repositório que você deseja clonar.
4. Escolha o diretório local onde deseja clonar o repositório. Você pode clicar no botão
“Choose” (ou “Escolher”) para selecionar uma pasta específica ou deixar o campo em
branco para clonar para o diretório padrão.
5. Clique em “Clone” (ou “Clonar”) para iniciar o processo de clonagem. O GitHub
Desktop clonará o repositório e criará uma cópia local no seu computador.

Agora, você tem uma cópia do repositório clonado no seu ambiente local, seja utilizando a
linha de comando do Git ou o GitHub Desktop. Você pode começar a trabalhar com os arquivos
e realizar alterações no projeto.
Na próxima unidade, vamos aprender a sincronizar as alterações entre o repositório local e o
repositório remoto no GitHub, usando os comandos push e pull tanto na linha de comando quanto
com o GitHub Desktop.

27
Sincronização de alterações com push e pull no GitHub
Após clonar um repositório existente no GitHub para o seu ambiente local, você pode
começar a trabalhar nos arquivos e fazer alterações. No entanto, é importante sincronizar essas
alterações com o repositório remoto no GitHub para manter uma cópia atualizada do projeto.
Nesta unidade, vamos aprender a sincronizar as alterações usando os comandos push e pull tanto na
linha de comando do Git quanto no GitHub Desktop.
No cotexto do GitHub, as ações push e pull são usadas para sincronizar alterações entre um
repositório local e um repositório remoto no GitHub. Elas têm propósitos diferentes e são aplicadas
em situações distintas. A seguir, veja as diferenças entre push e pull no GitHub.

Push
O comando push é usado para enviar as alterações locais para um repositório remoto no
GitHub. É utilizado quando você deseja compartilhar as suas modificações e atualizar o repositório
remoto com as alterações que você fez no seu ambiente local. É especialmente útil quando você
trabalha em equipe, permitindo que outros membros do projeto tenham acesso às suas alterações.
Ao realizar um push, os commits locais são enviados para o repositório remoto, atualizando o
histórico de versões. Os outros colaboradores poderão visualizar essas alterações, clonar o repositório
e integrá-las ao seu ambiente local usando pull ou fetch.

Pull
O comando pull é usado para obter as alterações remotas e incorporá-las ao seu repositório
local. É utilizado quando você deseja atualizar o seu ambiente local com as alterações que ocorreram
no repositório remoto. É geralmente usado quando outros colaboradores fizeram push das suas
modificações e você deseja trazer essas alterações para o seu ambiente local.
Ao realizar um pull, o Git recupera as alterações remotas, mescla-as com as suas alterações locais,
se houver, e atualiza o seu repositório local. É importante observar que, se houver conflitos de merge,
você precisará resolvê-los manualmente para que as alterações possam ser mescladas corretamente.
Em resumo, o push é usado para enviar as suas alterações locais para o repositório remoto,
enquanto o pull é usado para obter as alterações remotas e atualizar o seu repositório local com base
nessas alterações.
Essas ações, push e pull, são fundamentais para a colaboração em projetos do GitHub,
permitindo que os membros da equipe compartilhem e atualizem as suas alterações de forma
eficiente, mantendo o repositório sincronizado e facilitando a colaboração.

28
Sincronizando alterações com push com a linha de comando do Git
Para sincronizar as alterações com o repositório remoto usando a linha de comando do Git,
veja os passos a seguir:
1. Faça as alterações desejadas nos arquivos do projeto, como o arquivo “notas.txt”.
2. No terminal ou prompt de comando, navegue até o diretório do repositório clonado, caso
ainda não esteja nele.
3. Use o comando git status para verificar o status das alterações. Se houver modificações nos
arquivos que você deseja incluir no próximo commit, adicione-os ao controle de versão
usando o comando git add. Por exemplo:
git add notas.txt
4. Faça o commit das alterações usando o comando git commit -m “Mensagem de commit”.
Por exemplo:

git commit -m “Primeiro commit”

Agora, você pode enviar as alterações para o repositório remoto usando o comando
git push. Por exemplo:

git push origin main

5. Esse comando envia as alterações da branch “main” para o repositório remoto. Se você
estiver usando uma branch diferente, substitua “main” pelo nome da sua branch. As suas
credenciais no GitHub serão solicitadas:

Figura 5 – GitHub: solicitação de credenciais

29
 Figura 6 – GitHub: autorização de credenciais

Autorize as credenciais e, em seguida, as suas alterações serão enviadas para o repositório

remoto no GitHub:

Figura 7 – GitHub: envio das alterações para o repositório remote

30
Sincronização de alterações com o GitHub Desktop
Se preferir utilizar o GitHub Desktop para sincronizar as alterações com o repositório remoto,
acompanhe as instruções a seguir:
1. Faça as alterações desejadas nos arquivos do projeto, como o arquivo “notas.txt”.
2. Abra o GitHub Desktop e selecione o repositório clonado na lista de repositórios.
3. No painel superior direito, você verá as alterações detectadas pelo GitHub Desktop.
Forneça uma descrição para as alterações no campo de resumo.
4. Clique no botão “Commit to main” (ou “Commitar para a main”) para fazer o commit
das alterações na branch principal (main).
5. Após o commit, clique no botão “Push origin” (ou “Enviar para a origem”) para enviar as
alterações para o repositório remoto.

Agora, as alterações foram sincronizadas com o repositório remoto no GitHub utilizando o

GitHub Desktop.

Atualização do repositório local com o pull

Em alguns casos, outras pessoas podem ter feito alterações no repositório remoto enquanto
você trabalhava nas suas modificações locais. Para atualizar o seu repositório local com as alterações
mais recentes, você pode usar o comando pull na linha de comando do Git ou o botão “Fetch
origin” seguido do botão “Pull origin” no GitHub Desktop.
No Git por linha de comando:

git pull origin main

No GitHub Desktop:
1. Selecione o repositório clonado no GitHub Desktop.
2. Clique no botão “Fetch origin” (ou “Obter da origem”).
3. Após o fetch, clique no botão “Pull origin” (ou “Puxar da origem”) para atualizar o seu
repositório local com as alterações mais recentes.

Agora, você pode continuar trabalhando no projeto e sincronizar as alterações com o

repositório remoto sempre que necessário.

31
Tópico avançado: resolução de conflitos de merge no
GitHub
Ao trabalhar em um projeto compartilhado no GitHub, pode haver momentos em que duas
ou mais pessoas fizeram alterações conflitantes no mesmo arquivo. Esses conflitos de merge ocorrem
quando o Git não consegue determinar automaticamente como mesclar as alterações. Nesta
unidade, vamos aprender a lidar com conflitos de merge no GitHub, tanto utilizando a linha de
comando do Git quanto o GitHub Desktop.

Resolução de conflitos de merge com a linha de comando do Git

Quando ocorre um conflito de merge, você precisará resolver manualmente as diferenças no
arquivo e informar ao Git como mesclar as alterações. Veja a seguir os passos para resolver conflitos
de merge usando a linha de comando do Git:
1. Quando você executar o comando git pull ou git merge e ocorrer um conflito, o Git
indicará os arquivos que têm conflitos. Abra o arquivo em conflito em um editor de texto.
Você verá marcações que indicam as alterações conflitantes. Por exemplo:

<<<<<<< HEAD
Seção anterior do arquivo
=======
Nova seção do arquivo
>>>>>>> branch-name

2. As linhas entre <<<<<<< HEAD e ======= representam as alterações atuais no seu

repositório local (branch atual), enquanto as linhas entre ======= e >>>>>>> branch-
name representam as alterações conflitantes da outra branch.
3. Edite o arquivo para resolver os conflitos. Mantenha apenas as partes necessárias das
alterações e remova as marcações de conflito.
4. Após resolver os conflitos, salve o arquivo e execute o comando git add para adicionar o
arquivo modificado ao próximo commit.
5. Faça o commit das alterações resolvendo o conflito usando o comando git commit. O
Git adicionará automaticamente uma mensagem de commit padrão para indicar a
resolução do conflito.
6. Finalmente, execute o comando git push para enviar as alterações resolvidas para o
repositório remoto.

32
Resolução de conflitos de merge com o GitHub Desktop
O GitHub Desktop também oferece uma maneira intuitiva de resolver conflitos de merge.
Veja os passos a seguir:
1. Quando você realizar um “Pull origin” no GitHub Desktop e ocorrer um conflito, o
GitHub Desktop indicará os arquivos que têm conflitos. Clique em “Resolve conflicts”
(ou “Resolver conflitos”) para iniciar o processo de resolução de conflitos.
2. O GitHub Desktop abrirá o editor de texto padrão do seu sistema operacional, exibindo o
arquivo em conflito. Você verá as mesmas marcações de conflito mencionadas anteriormente.
3. Edite o arquivo para resolver os conflitos, mantendo apenas as partes necessárias das
alterações. Remova as marcações de conflito.
4. Após resolver os conflitos, salve o arquivo.
5. Volte para o GitHub Desktop e você verá o arquivo em conflito com uma opção para marcar
o arquivo como resolvido. Clique em “Mark as resolved” (ou “Marcar como resolvido”).
6. O GitHub Desktop adicionará automaticamente o arquivo modificado ao próximo
commit. Forneça uma descrição para o commit e clique em “Commit to main” (ou
“Commitar para a main”).
7. Por fim, clique em “Push origin” (ou “Enviar para a origem”) para enviar as alterações
resolvidas para o repositório remoto.

Com isso, é possível resolver conflitos de merge no GitHub usando tanto a linha de comando
do Git quanto o GitHub Desktop. É importante ter atenção a esses conflitos ao trabalhar em
projetos compartilhados para garantir que as alterações sejam mescladas corretamente.

33
34
MÓDULO IV – GITFLOW

Considere que, em vez de utilizar uma única ramificação principal (master), optamos por
utilizar duas ramificações para gerenciar o histórico do projeto. A ramificação master continuará
armazenando o histórico de lançamentos oficiais, enquanto a ramificação develop será utilizada
como uma ramificação de integração para novas funcionalidades.

Branches de desenvolvimento (develop)

A primeira etapa desse processo consiste em complementar a ramificação main padrão por
meio da criação de uma ramificação develop. Na figura 8, a seguir, veja como, a partir da sua criação,
a branch develop segue o próprio caminho, independente da branch master.

Figura 8 – Develop

Fonte: Openclipart, licenciado com Creative Commons. Disponível em: https://openclipart.org/. Acesso em: 26 dez. 2023.
Branches de recursos (features)
Em desenvolvimento de software ou qualquer outro trabalho colaborativo que possa valer-se
das vantagens do Git, cada novo recurso ou funcionalidade deve ser desenvolvido na sua própria
ramificação, a qual pode ser enviada para o repositório principal posteriormente por meio de um
push para fins de backup e colaboração. Desse modo, podemos ter o seguinte cenário:

Figura 9 – Features

Fonte: Openclipart, licenciado com Creative Commons. Disponível em: https://openclipart.org/. Acesso em: 26 dez. 2023.

Branches de lançamento (release)

Quando a ramificação develop acumula recursos suficientes para um lançamento ou quando
uma data de lançamento predeterminada se aproxima, inicia-se um novo ciclo de lançamento,
criando uma ramificação específica chamada release a partir da develop. A partir desse momento,
nenhum novo recurso deve ser adicionado à ramificação de lançamento; apenas atualizações de
segurança, tarefas relacionadas à geração de documentação e outras correções específicas para o
lançamento são permitidas nessa ramificação.

36
 Figura 10 – Release

Fonte: Openclipart, licenciado com Creative Commons. Disponível em: https://openclipart.org/. Acesso em: 26 dez. 2023.

Com a ramificação de lançamento pronta para o lançamento, ela será fundida (merge) na
ramificação principal master e marcada com o número da versão correspondente. Além disso, a
ramificação de lançamento deve ser mesclada de volta à ramificação develop, que pode ter
progredido desde o início do ciclo de lançamento.
Esse uso de uma ramificação dedicada para o preparo de lançamentos possibilita que a equipe
trabalhe no aperfeiçoamento do lançamento atual, enquanto outra equipe continua desenvolvendo
recursos para o próximo lançamento. Além disso, cria fases de desenvolvimento bem definidas, tornando
mais fácil identificar e acompanhar o progresso das versões dentro da estrutura do repositório.
Elaborar ramificações de lançamento é uma operação de ramificação simples, assim como as
ramificações de recurso. Elas são criadas a partir da ramificação develop e podem ser facilmente
criadas usando os métodos disponíveis no Git.

Branches de correções rápidas (hotfix)

As ramificações de hotfix ou manutenção são utilizadas para corrigir rapidamente
lançamentos de produção. Elas possuem semelhanças com as ramificações de release e feature, mas
a principal diferença é que são baseadas diretamente na ramificação master em vez da develop. Essa
é a única situação em que uma ramificação deve ser criada diretamente a partir da master.

37
 Figura 11 – Hotfix

Fonte: Openclipart, licenciado com Creative Commons. Disponível em: https://openclipart.org/. Acesso em: 26 dez. 2023.

Uma vez que a correção é concluída, é necessário fazer o merge dela tanto na ramificação
master quanto na develop – ou na ramificação release atual, caso exista –, e a ramificação master deve
ser marcada com um número de versão atualizado.
Essa abordagem de ter uma linha de desenvolvimento dedicada para atualizações de segurança
permite que a equipe lide com problemas sem interromper o fluxo de trabalho normal ou aguardar
o próximo ciclo de lançamento. É possível pensar nas ramificações de hotfix como ramificações
release ad hoc que trabalham diretamente com a master.

Fluxo geral do Gitflow

O fluxo geral do Gitflow é o seguinte:
1. Uma ramificação develop é criada a partir da master.
2. Uma ramificação de lançamento é criada a partir da ramificação de desenvolvimento (develop).
3. As ramificações de recurso são criadas a partir da ramificação de desenvolvimento (develop).
4. Quando um recurso é concluído, ele é mesclado na ramificação de desenvolvimento (develop).

38
5. Quando a ramificação de lançamento é feita, é feito o merge dela na ramificação de
desenvolvimento (develop) e na ramificação principal (master).
6. Se for detectado um problema na ramificação principal (master), uma ramificação de
hotfix será criada a partir dela.
7. Depois que o hotfix for concluído, ele passará por merge para a ramificação de
desenvolvimento (develop) e para a ramificação principal (master).

39
APÊNDICE – RESUMO GERAL DOS
COMANDOS GIT

Deixamos reservado para esta parte do curso um resumo dos comandos Git mais essenciais
que você usará ao trabalhar com controle de versão no Git. Cada comando é fundamental para
rastrear, gerenciar e colaborar em projetos de desenvolvimento de software. O conhecimento destes
comandos é uma habilidade fundamental para qualquer pessoa que trabalhe na área:

git status
Mostra o status da branch atual, os arquivos que foram modificados, aqueles que estão em
fase de staging e aqueles não estão. Mostra também o status da sua branch local em relação à branch
remota, se houver. É um comando muito associado ao git add, geralmente precedendo-o.

git branch
Cria uma branch ou mostra uma lista de branches locais ou remotas. Com este comando,
podemos adicionar opções relacionadas a branches:
 git branch nova-branch – cria uma branch a partir da branch atual, com o nome nova-branch;
 -d or --delete – exclui uma branch:
 Por exemplo: git branch -d nome-da-branch;
 -D – força a exclusão da branch. É utilizado quando queremos excluir uma branch que
possui mudanças que não foram enviadas ou mescladas ao servidor:
 Por exemplo: git branch -D nome-da-branch;
 -a or --all – exibe todas as branches, locais ou remotas:
 Por exemplo: git branch -a.
git fetch
Realiza uma busca por branches no servidor, obtém o seu histórico e as informações associadas.
Também é possível utilizar git fetch origin para atualizar as suas ramificações de rastreamento remoto.

git pull
Atualiza o seu diretório de trabalho realizando um git fetch, seguido de um git merge. Isso é útil
quando você deseja atualizar a sua branch para estar em conformidade com a branch de rastreamento
remoto. Você também pode usar a opção --rebase para executar um rebase em vez de um merge.

git checkout
Este comando tem várias funções. Pode ser usado para criar uma nova branch a partir da
branch atual, para verificar uma branch do servidor ou para alternar para outra branch:
 git checkout develop – você utilizará isso com frequência. Isso o mudará da branch atual
para a branch develop. Se você tiver alterações na branch atual, será necessário guardá-las
temporariamente (stash) ou desfazer as alterações antes de trocar de branch;
 git checkout branch-no-servidor – se você quiser trabalhar em uma branch de outra pessoa,
assumindo que já tenham enviado a branch para o repositório remoto, você pode usar este
comando para criar uma cópia da branch na sua máquina local. Você precisará fazer git
fetch primeiro para obter as informações sobre a branch;
 git checkout -b novo-nome-da-branch – cria uma nova branch a partir da branch atual e troca
para essa nova branch. Se você estiver na develop, isso criará uma nova branch a partir da
develop. Este comando é sinônimo de git branch novo-nome-da-branch && git checkout
novo-nome-da-branch.

git add
Você fez alterações na sua branch e deseja prepará-las para serem commitadas. Você precisa
adicioná-las ao que é conhecido como “índice”. A seguir, estão duas maneiras de fazer isso:
 git add /caminho/arquivo.extensao – adicionará o arquivo específico;
 git add . – adicionará todos os arquivos alterados. Tenha cuidado aqui; certifique-se de
não adicionar alterações indesejadas revisando as suas alterações usando git status. Se você
acidentalmente adicionou arquivos indesejados, observe o git reset, descrito adiante.

41
git commit
Se você deseja fazer um commit, veja como fazer:
 git commit – fará um commit dos arquivos que você preparou com git add e abrirá um
editor VIM, ou qualquer editor configurado no seu .gitconfig, para inserir a sua mensagem
de commit;
 git commit -a – fará um commit e adicionará todos os arquivos alterados, abrindo um editor
para inserir a sua mensagem de commit. Isso é o mesmo que fazer git add . && git commit;
 git commit -m “mensagem de commit” – pule o editor e coloque toda a mensagem no comando;
 git commit -a -m “mensagem de commit” – combine todos eles. Ótimo!

git push
Após fazer um commit, você precisa enviar as suas alterações para o servidor para que fiquem
visíveis para todas as pessoas:
 git push branch ou git push origin HEAD – envia a sua branch para o servidor. Você pode
usar qualquer versão. Usar origin HEAD é apenas uma maneira mais detalhada de fazer o
push. Isso significa que você está enviando a ponta (HEAD) da sua branch para o mesmo
nome no repositório remoto origin.

git log
Mostra o histórico de todas as branches e os seus commits. É útil para ver o commit mais recente
e obter os hashes dos commits:
 git log – mostra todos os commits nesta branch, juntamente com o hash do commit, autor,
data e mensagem;
 git log --oneline – mostra uma versão simplificada do comando acima, exibindo apenas o
hash do commit e a mensagem do commit;
 git log --graph – mostra um gráfico do histórico de commits da sua branch (incrível);
 git log --max-count <n> – limita o número de commits exibidos;
 git log --oneline --graph --max-count 50 – combine todos eles. Uau!

42
git rebase
O rebasing é um pouco mais avançado, mas incrivelmente útil quando necessário. Quando você
realiza um rebase, está alterando a base da sua branch. Em essência, um rebase examinará cada commit
na sua branch e atualizará o código para parecer que você estava trabalhando na nova base o tempo todo.
Às vezes, um rebase encontrará problemas ao tentar atualizar um trecho de código que você já modificou.
Nesse caso, ele não saberá qual versão do código usar, então deixará para você resolver manualmente.
Embora tenham usos semelhantes, um rebase difere de um merge, pois um rebase atualiza a
sua branch ajustando cada commit, enquanto um merge atualiza a sua branch criando um novo
commit na ponta da sua branch. Normalmente, em um projeto ou uma equipe, existem padrões e
práticas em torno do método preferido. Tenha uma discussão com a sua equipe sobre qual fluxo de
trabalho as pessoas preferem.

git stash
O stash permite que você salve as suas alterações atuais – não preparadas – e reverta a sua
branch para um estado não modificado. Quando você guarda, as suas alterações são colocadas em
uma pilha. Isso é especialmente útil se você precisar alternar rapidamente para outra branch sem ter
de commitar as suas alterações incompletas:
 git stash – guarde as suas alterações não preparadas;
 git stash pop – desfaça as suas alterações guardadas;
 git stash drop – descarte as suas alterações guardadas. Cuidado, você perderá as suas
alterações;
 git stash push <caminho> – guarde um único arquivo;
 git stash -m <mensagem> – adicione uma mensagem à sua guarda.

git reset
O git reset é usado para desfazer o staging de arquivos ou remover commits. Ele faz isso
alterando o que a ponta da branch (HEAD) aponta. Três “árvores” são afetadas por um reset:
 HEAD – a ponta da sua branch;
 Index – a área de staging, que é como um commit proposto;
 Diretório de trabalho – os arquivos atualmente no seu disco. Existem três modos de reset,
isto é, -soft, -mixed (padrão) e -hard:
 -soft – é o primeiro passo em qualquer modo de reset. Para um reset suave,
 -mixed;
 -hard;

43
  Desfazer git add:
 git add .;
 git reset -- arquivo.html (desfaz um único arquivo);
 git reset (desfaz tudo);
 Desfazer o commit mais recente:
 git commit -a -m “mensagem do commit”;
 git reset --soft HEAD^ (desfaz o commit que está na ponta da branch);
 git commit -a -m “nova mensagem do commit”;
 Desfazer um commit permanentemente:
 git reset --hard HEAD~2 (destrói os dois commits mais recentes, ou seja, HEAD e HEAD^).

Essas traduções devem ajudar a entender melhor o significado e o uso de cada comando no
contexto do Git e GitHub.

44
CONCLUSÃO

O controle de versão e a colaboração são elementos essenciais no desenvolvimento de

software, permitindo que desenvolvedores trabalhem de forma eficiente, rastreiem alterações,
colaborem em equipe e entreguem um produto final de alta qualidade. Neste curso, exploramos o
Git e o GitHub.
O Git é um sistema de controle de versão distribuído, projetado para lidar com projetos com
rapidez e eficiência. Fornece recursos como rastreamento de alterações, criação de branches
independentes e mesclagem de alterações de forma controlada. O GitHub, por sua vez, é uma
plataforma de hospedagem de código-fonte baseada em nuvem que utiliza o Git como sistema de
controle de versão subjacente. Oferece recursos adicionais para facilitar a colaboração entre
desenvolvedores, como revisões de código, gerenciamento de issues e integração contínua.
Neste curso, falamos da instalação do Git em diferentes sistemas operacionais e exploramos
os seus conceitos básicos, incluindo a inicialização de um repositório, os comandos essenciais como
add, commit, status e log, bem como a visualização e a navegação no histórico de commits. Também
aprendemos a desfazer alterações com os comandos revert, reset e checkout, bem como a criação e o
gerenciamento de branches.
Abordamos o trabalho com repositórios remotos no GitHub, aprendendo a criar um usuário
no GitHub, configurar um repositório remoto, clonar um repositório existente e sincronizar
alterações com os comandos push e pull. Exploramos ainda a resolução de conflitos de merge, uma
situação comum ao trabalhar em projetos compartilhados.
Este curso foi uma introdução ao uso do Git e do GitHub no controle de versão e
colaboração. Há ainda muito mais recursos e práticas avançadas que podem ser exploradas. A partir
do conhecimento adquirido aqui, você pode expandir os seus estudos e aprofundar o seu domínio
dessas ferramentas.
REFERÊNCIAS BIBLIOGRÁFICAS
GIT. Downloads. [s.l., s.d.]. Disponível em: https://git-scm.com/downloads. Acesso em: 17 dez. 2023.

GITHUB. [s.l., s.d.]. Disponível em: https://github.com. Acesso em: 17 dez. 2023.

GITHUB DESKTOP. [s.l., s.d.]. Disponível em: https://desktop.github.com. Acesso em: 17 dez. 2023.

OPENCLIPART. [s.l., s.d.]. Licenciado com Creative Commons. Disponível em:

https://openclipart.org. Acesso em: 17 dez. 2023.

README. [s.l., s.d.]. Disponível em: http://readme.md. Acesso em: 17 dez. 2023. Este conteúdo
contém uma checagem que une processos, prazos e interligações das atividades de uma
incorporação imobiliária.

46
PROFESSORES-AUTORES

Carlos Pivotto
Formação acadêmica

 Mestre em Engenharia de Sistemas e Informação pelo

Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa
em Engenharia da Universidade Federal do Rio de Janeiro
(Coppe/UFRJ).
 Engenheiro de Computação e Informação pela UFRJ.

Atividades profissionais
 Engenheiro de software desde 2005.
 Docente em ensino superior desde 2013.

47