Forem: Renato Teixeira

Tudo o que você precisa saber sobre GIT

Renato Teixeira — Mon, 12 Feb 2024 14:30:00 +0000

Certamente você pode imaginar a importância de se versionar um código, para poder reverter alterações, recuperar dados perdidos, entre outras possibilidades. E aposto que você conhece alguém (não eu hehe) que controla a versão dos seus arquivos criando cópias deles com nomes cada vez mais criativos...

Até 1972, provavelmente era assim que qualquer pessoa faria o controle de versão dos seus códigos também, antes do lançamento do SCCS (Source Code Control System), um dos primeiros softwares de gerenciamento de versões centralizados que já foram lançados.

Mas não é o SCCS que nos interessa agora e sim o GIT, software de versionamento de código distribuído open-source que completa 20 anos do seu lançamento no ano que vem (07/04/2005).

Índice

1. O que é GIT?
2. Como o GIT funciona?
3. Instalando o GIT
4. Configurando o GIT
5. Iniciando um repositório local
6. Trabalhando com GIT
7. Conhecendo as branches
8. Sincronizando com o repositório remoto
9. Conclusão
10. Referências

1. O que é GIT?

GIT é um sistema de controle de versão distribuído open-source lançado em 2005, que foi desenvolvido por Linus Torvald (isso mesmo, o criador do kernel do Linux).

Com o GIT, é possível controlar as versões de um projeto localmente (na pasta de trabalho) e sincronizar todas as alterações para um repositório remoto (no GitHub, por exemplo).

2. Como o GIT funciona?

Imagine um arquivo físico onde há uma pasta com todos os arquivos do projeto. Dessa forma, sempre que alguém precisar manipular um arquivo, é preciso pegá-lo, removendo-o de dentro da pasta e retornando-o para a pasta após concluir o trabalho. Assim, é impossível que duas pessoas trabalhem num mesmo arquivo, evitando totalmente possíveis conflitos.

MAS NÃO É ASSIM QUE O GIT FUNCIONA! (ainda bem)

Esse é o funcionamento de um sistema de versionamento CENTRALIZADO, no qual o usuário precisa realizar o "check-out" e "check-in" de arquivos, ou seja, sempre que alguém precisa trabalhar em um determinado arquivo é necessário realizar o "check-out" desse arquivo, removendo-o do repositório, e depois de concluído o trabalho, realizar o "check-in" do arquivo, retornando-o para o repositório.

Em um sistema DISTRIBUÍDO como o GIT, é possível que várias pessoas acessem arquivos de um mesmo repositório remoto. Dessa forma, sempre que alguém precisar manipular um arquivo, basta cloná-lo (ou clonar todo o repositório) localmente para sua máquina, e depois enviar as modificações de volta ao repositório remoto. Assim, é possível que diversas pessoas trabalhem no mesmo projeto, manipulando até mesmo os mesmos arquivos.

Esse tipo de abordagem é o que permite a distribuição de grandes projetos open-source, com pessoas de diversas partes do mundo trabalhando em um mesmo projeto, gerenciando as modificações e possíveis conflitos (sim, conflitos de merge podem acontecer aqui).

3. Instalando o GIT

Atualmente, GIT está disponível para os principais sistemas operacionais (Windows, Linux, MacOs...) e a sua instalação é bem simples, podendo ser feita por linha de comando ou através do instalador oficial em git-scm.com.

3.1 No Windows

Para instalar o GIT no Windows, basta acessar o site oficial e realizar o download do instalador.
Com isso, basta apertar seguir as instruções que tudo deve correr bem e será possível utilizar os comandos do GIT no seu terminal.

3.2 No Linux

Para o Linux, é possível instalar o GIT utilizando o comando abaixo:

sudo apt install git-all

Dessa forma, o GIT estará pronto para ser usado em seu terminal.

3.3 No MacOS

No Mac, a forma mais fácil de instalar o GIT é instalando o Homebrew e então executando o comando abaixo no terminal:

brew install git

Assim, o GIT também ficará disponível para ser utilizado em seu terminal.

4. Configurando o GIT

Após a instalação, é importante configurar o GIT utilizando os comandos abaixo:

git config --global user.name "[username]"
# ex.: John Doe

git config --global user. email "[email@email.com]"
# ex.: johndoe@email.com

Também é possível configurar usuários específicos para determinados repositórios locais removendo a tag --global.

5. Iniciando um repositório local

Com o GIT configurado, podemos iniciar nosso repositório.
Para isso, é possível iniciar um novo repositório do zero ou clonar um repositório remoto existente.

5.1 Iniciando do zero (git init)

Para iniciar um novo repositório, basta navegar até a pasta raiz que desejamos tornar um repositório e executar o comando abaixo:

git init

Dessa forma, um diretório .git será criado dentro da pasta do projeto, que será responsável pelo controle de versão na pasta de trabalho desse repositório local.

5.2 Clonando um repositório (git clone)

Clonar um repositório remoto existente é tão fácil quanto iniciar um novo repositório do zero. Para isso, basta utilizar o comando git clone passando a URL do repositório à ser clonado como parâmetro dentro da pasta em que deseja clonar o repositório:

git clone [url-do-repositório-clonado]

Dessa forma, todo o repositório sera clonado para sua máquina local, sendo automaticamente atrelado ao repositório remoto de origem.

Em um repositório clonado não haverá necessidade de utilizar o comando git remote no futuro.

6. Trabalhando com GIT

Tendo o repositório local inicializado, é possível trabalhar em nosso projeto utilizando o controle de versão do GIT localmente.

Dentro do nosso repositório local, podemos criar os arquivos necessários para o nosso projeto, mas eles não serão sincronizados automaticamente pelo GIT, para isso é necessário que informemos quando houver mudanças para serem versionadas.

Assim, podemos manipular os arquivos como quisermos e, após concluir as alterações desejadas, enviar os arquivos atualizados para o GIT.

Para isso, é importante entender que existe um fluxo infinito (sim, infinito) de 3 estágios no controle de versões:

                    MODIFY -> STAGE -> COMMIT

MODIFY: Primeiro estágio do controle de versões, aqui são colocados os arquivos que sofreram alguma alteração comparada à última versão disponível.
STAGE: Segundo estágio do controle de versões, aqui são colocados os arquivos modificados que queremos adicionar ao próximo commit.
COMMIT: Estágio final do controle de versões, quando confirmamos as modificações feitas, enviando os arquivos modificados que estavam em stage para o repositório local.

Com os arquivos commitados, temos uma nova versão disponível no repositório local, que pode novamente sofrer alterações, passando novamente para "modified", ter essas novas alterações colocadas em "stage" e novamente "commitadas", confirmando uma nova versão e assim por diante (e por isso "infinito" lol).

Um commit não exclui a versão antiga dos arquivos modificados, apenas inclui a nova versão com um apontamento para a última versão disponível, mantendo assim o rastreamento das versões de cada arquivo rastreado pelo GIT.

6.1 Adicionando e commitando (git add e git commit)

Apesar de parecer complexo, executar o fluxo de versionamento é bem simples. Após concluir as modificações desejadas, adicionamos os arquivos modificados que desejamos commitar em stage:

git add [nome-do-arquivo]

git add -A -> adiciona todos os arquivos modificados para stage de uma vez.

git add *.[extensão-do-arquivo] -> adiciona todos os arquivos modificados com a extensão especificada para stage de uma vez (ex.: git add *.html).

É possível verificar o status atual do nosso repositório a qualquer momento utilizando o comando git status:

Perceba que, ao executar o git status dentro do repositório após criar um novo arquivo, o novo arquivo é exibido como "Untracked". Isso significa que esse arquivo é novo e ainda precisa ser adicionado à algum commit para que seja rastreado pelo GIT.

É possível fazer com que o GIT ignore determinados arquivos ou pastas dentro do repositório. Para isso basta adicionar um arquivo à pasta raiz chamado .gitignore e, dentro dele, destacar o nome dos arquivos ou pastas que devem ser ignorados.

ATENÇÃO: Arquivos e pastas ignorados não aparecem mais no rastreamento do GIT, nem mesmo como "Untracked". Para retornar o rastreamento basta apagar os nomes do arquivo .gitignore.

Para incluir um arquivo, podemos executar o comando git add que vimos antes com o nome do arquivo que desejamos adicionar ("index.html" nesse caso):

Dessa forma, ao executar novamente o git status podemos perceber que o novo arquivo foi adicionado ao "stage" e está finalmente pronto para ser enviado no nosso próximo commit, que pode ser feito utilizando o comando abaixo:

git commit -m "[mensagem-descritiva]"

COMMITS possuem ID's (hash) únicos e são IMUTÁVEIS, ou seja, não podem ser modificados após confirmados.

git commit -a -> realiza o commit direto, adicionando todos os arquivos modificados em stage e realizando o commit.

Após realizar o commit com sucesso, ao executar o git status percebemos que não há mais arquivos modificados para serem enviados, uma vez que todas as modificações foram efetivamente salvas no nosso repositório local com o último commit.

Ainda é possível comprovar as mudanças realizadas ao rever o log de commits do repositório, utilizando o comando git log, que mostra alguns metadados de todos os commits realizados como o código hash, branch, autor, data, etc.

Todo esse processo pode ser repetido para adicionar novos arquivos que sejam necessários ao seu projeto, modificá-los e enviá-los ao repositório local através de commits.

git log -N -> exibe o log dos últimos N commits.

git log [branch-A] [branch-B] -> exibe o log dos commits que estão na "branch-B" mas não estão na "branch-A".

git log --follow [nome-do-arquivo] -> exibe o log dos commits que alteraram o arquivo especificado, mesmo que ele tenha mudado de nome.

git diff -> lista as modificações feitas em relação à última versão disponível no repositório.

git diff [nome-do-arquivo] -> lista as modificações feitas no arquivo especificado em relação à sua última versão disponível no repositório.

6.2 Desfazendo mudanças antes e depois do commit

Antes de realizar um commit, todas as mudanças feitas no repositório local podem ser desfeitas, ou alteradas, mas após realizar o commit, não é possível alterá-lo. Isso porque commits são objetos imutáveis, ou seja, é impossível editar ou alterar as informações de um commit realizado.

Ainda assim, é possível realizar novos commits que desfazem alguma alteração, ou corrigem informações incorretas em commits anteriores. Para ambos os casos, podemos utilizar um dos comandos listados abaixo:

git checkout -- [nome-do-arquivo]
# Descarta as mudanças feitas no arquivo local, antes do commit (ação irreversível)

git reset --hard HEAD
# Descarta as mudanças feitas em um arquivo que está em stage, antes do commit

git reset --hard HEAD~1
# Descarta o último commit realizado no repositório local (somente o último commit)

git commit --amend
# Realiza um novo commit, substituindo o último commit feito no repositório local

git revert [hash-do-commit]
# Realiza um novo commit revertendo as alterações do commit especificado

7. Conhecendo as branches

Uma branch nada mais é do que uma ramificação do repositório e, até agora, todas as ações foram realizadas na branch master/main.

Por padrão, a primeira branch criada no repositório é a branch master/main, que é a branch principal do repositório.

7.1 Pra que servem as branches?

A princípio pode não parecer grande coisa, mas as branches dão um poder enorme pro desenvolvimento do projeto.

Imagine que estamos desenvolvendo uma plataforma web e queremos testar uma nova feature, mas nosso repositório já está sendo hospedado ou compartilhado com outras pessoas e qualquer alteração problemática pode causar uma péssima experiência à essas pessoas. O que podemos fazer?

Se você pensou em duplicar a pasta do projeto, criando uma "versão de testes", você acertou! Bom, em partes...

Com o GIT, é possível fazer algo parecido utilizando as branches. Como elas são ramificações, podemos simplesmente criar uma nova branch, chamada de "teste" (por exemplo), e assim teremos uma versão do nosso projeto em uma branch totalmente isolada, pronta pra ser revirada sem qualquer risco de impactar a branch principal.

7.2 Criando branches (git branch)

Criar uma branch significa criar uma cópia paralela do repositório que pode ser trabalhada independentemente, sem impactar a branch master/main. Para isso, basta utilizar o comando abaixo:

git branch [nome-da-branch]

Executar o comando git branch sem um nome exibe a lista de branches disponíveis no repositório, com um "*" na branch que está sendo utilizada atualmente.

Antes de executar o comando git branch teste, o comando git branch retornava somente a branch master.

Após criar uma nova branch, é possível alternar entre as branches disponíveis utilizando o comando abaixo:

git checkout [nome-da-branch]

Após executar o comando git checkout teste, podemos ver que a branch ativa é alternada. A partir desse momento todo o trabalho commitado estará sendo enviado para a branch teste do repositório, sem impactar a branch master/main.

É possível criar quantas branches forem necessárias e podemos interagir com as branches criadas utilizando os comandos abaixo:

git checkout -b [nome-da-branch] -> cria uma nova branch com o nome especificado e já alterna para ela.

git branch -d [nome-da-branch] -> exclui a branch especificada.

git branch -m [novo-nome] -> altera o nome da branch atual para o nome especificado.

7.3 Combinando branches (git merge)

Quando finalizamos o trabalho em uma branch diferente e temos segurança de que as alterações feitas não ocasionaram problemas no código, podemos mergear (combinar) a branch atual com a branch master/main, aplicando todas as mudanças da branch atual à branch principal do repositório.

Para realizar o merge de uma branch à outra, devemos alternar para a branch que vai receber as alterações e utilizar o comando abaixo:

git merge [nome-da-branch]
# faz o merge da branch especificada na branch atual

Nos nossos exemplos, como estamos na branch teste, devemos alternar para a branch master utilizando o comando git checkout e então executar o comando git merge com o nome da branch que desejamos combinar ("teste", nesse caso)

Dessa forma, todo o trabalho feito na branch teste (a criação do arquivo style.css, nesse caso) será combinado com a branch master.

7.4 Conflitos no merge

Combinando diferentes branches com o git merge podemos nos deparar com alguns conflitos nos casos em que um ou mais arquivos tenham sido alterados nas mesmas linhas e a combinação não pode ser realizada de maneira automática.

Nesses casos, podemos executar o comando git status para verificar quais arquivos estão conflitando.

Será necessário resolver os conflitos antes de prosseguir com o merge, definindo quais alterações devem prevalecer ou refazendo as alterações para que sejam mutuamente comportadas. Para isso, o próprio GIT insere marcações dentro dos arquivos conflitantes que auxiliam a resolução.

Após resolver os conflitos, basta recolocar os arquivos modificados em stage, realizar o commit das novas versões sem conflitos e executar novamente o comando git merge que tudo deve ser combinado sem maiores problemas.

8. Sincronizando com o repositório remoto

Sabemos que é possível relacionar o nosso repositório local à um repositório remoto para sincronizar todo o nosso trabalho remotamente e mantê-lo sempre atualizado.

Para isso, utilizaremos o comando git push, que envia todos os commits do repositório local para o repositório remoto, mas antes, precisamos configurar um repositório remoto apropriado.

8.1 Configurando um repositório remoto

Iniciar um repositório remoto é bastante simples. Aqui vamos utilizar o GitHub para isso.

Primeiro, devemos iniciar um novo repositório vazio em nossa conta do GitHub (apenas escolhendo um nome e clicando em "Criar repositório"):

Após isso, precisamos configurar a relação entre o repositório remoto e o repositório local, executando o comando abaixo dentro do nosso repositório local:

git remote add origin [url-do-repositorio-remoto]

git remote -v -> exibe a URL do repositório remoto conectado ao repositório local atualmente.

Com o repositório remoto conectado, devemos alterar o nome da nossa branch master/main local para "main" com o comando git branch -m main (ignorar se a sua branch local já se chamar main):

É importante que a branch principal do repositório local tenha o mesmo nome da branch principal do repositório remoto ao qual vamos realizar o push.

Finalmente, após cumprir os passos acima, podemos sincronizar nosso trabalho local com o repositório remoto pela primeira vez utilizando o comando abaixo:

git push -u origin main

Ao executar o comando git push -u origin main pode ser necessário informar suas credenciais do GitHub (usuário e token de acesso).

Se você não sabe o que é um token de acesso do GitHub, ou ainda não tem seu token de acesso configurado, clique aqui.

Também é possível contornar isso configurando a autenticação com o CLI do GitHub. Saiba como clicando aqui.

Após autenticar, o git push deve ser executado com sucesso, sincronizando todos os commits do repositório local com o repositório remoto.

8.2 Git push depois da primeira vez (git push)

Depois de passar por todas as etapas acima, novas sincronizações podem ser realizadas somente utilizando o comando git push, sem que haja necessidade de passar qualquer parâmetro, como vemos abaixo.

Nesse caso, a autenticação necessária para realizar o git push foi contornada utilizando o CLI do GitHub. Saiba como clicando aqui.

8.3 Atualizando o repositório local (git pull)

Com um repositório remoto distribuído, é possível que alterações sejam feitas remotamente (diretamente no repositório remoto), fazendo com que nosso repositório local fique desatualizado.

Por isso, é muito importante atualizar o repositório local, sincronizando quaisquer mudanças existentes no repositório remoto, garantindo que o código local esteja sempre em sua última versão disponível no repositório remoto. Para isso, podemos utilizar o comando abaixo:

git pull

Imagine que um novo arquivo README.md foi criado diretamente no repositório remoto e, com isso, nosso repositório local está desatualizado.

Dentro do repositório local, podemos sincronizar as alterações do repositório remoto com o git pull.

As primeiras 7 linhas retornadas ao executar o comando git pull são resultado do comando git fetch. Ou seja, ao executar o comando git pull sem executar o comando git fetch previamente, o GIT executa ambos em conjunto para recuperar as atualizações do repositório remoto e sincronizá-las no repositório local.

git fetch -> Recupera as atualizações do repositório remoto, mas não sincroniza o repositório local (necessita do git pull)

9. Conclusão

Tudo isso nos traz a certeza de que o GIT é um sistema de controle de versão necessário no dia a dia de um programador, e conhecer seus principais comandos e utilidades pode ser o divisor de águas em nossa senioridade técnica.
Por fim, com os repositórios locais e remotos sincronizados e atualizados e com tudo o que aprendemos até agora, estamos prontos para seguir em frente com a praticidade desse incrível sistema de controle de versão.

10. Referências

Publicado originalmente em Inglês:
Everything you need to know about GIT

Everything you need to know about GIT

Renato Teixeira — Mon, 05 Feb 2024 14:30:00 +0000

I'm sure you can imagine the importance of versioning code, so that we can revert changes and recover lost data among other possibilities.
I bet you know someone (not me hehe) who does version control with their files by creating copies of them with increasingly creative names...

This was probably how anyone would do version control with their code as well before 1972, with the release of SCCS (Source Code Control System), one of the first centralized version control software ever released.

But we're not here to talk about SCCS, what really interests us now is GIT, the distributed open-source version control software that celebrates its 20th anniversary next year (07/04/2005).

1. What's GIT?
2. How does GIT work?
3. Installing GIT
4. Configuring GIT
5. Starting a local repository
6. Working with GIT
7. Knowing branches
8. Syncing with the remote repository
9. Conclusion
10. References

1. What's GIT?

GIT is an open-source distributed version control system launched in 2005 and developed by Linus Torvald (yh, the Linux kernel creator).

With GIT, we can locally control the versions of a project (in the working folder) and synchronize all changes to a remote repository (on GitHub, for example).

2. How does GIT work?

Imagine a physical file cabinet where there's a folder with all the project files. Whenever someone needs to manipulate a file, they have to pick it up, removing it from the folder and returning it to the folder after finishing. So, it is impossible for two people to work on the same file, completely avoiding any possible conflicts.

BUT THAT'S NOT HOW GIT WORKS! (thank God)

This is how a CENTRALIZED version control system works, in which the user needs to "check-out" and "check-in" files, i.e. whenever someone needs to work on a specific file, they need to check-out that file, removing it from the repository, and then check-in the file once the work is done, returning it to the repository.

In a DISTRIBUTED system like GIT, it's possible for several people to access files from the same remote repository. Whenever someone needs to manipulate a file, they can simply clone it (or clone the entire repository) locally to their machine, and then send the modifications back to the remote repository. This makes it possible for several people to work on the same project, even manipulating the same files.

This is what allows the distribution of large open-source projects, with people from different parts of the world working on the same project, managing modifications and possible conflicts (yes, merge conflicts can happen here).

3. Installing GIT

GIT is available for the main operating systems (Windows, Linux, MacOs...) with a very simple installation process, which can be done by command line or through the official installer at git-scm.com.

3.1 On Windows

To install GIT on Windows, simply go to the official website and download the installer. Then just follow the instructions and everything should be fine then we'll be able to use the GIT commands in our terminal.

3.2 On Linux

For Linux, we can install GIT using the command below:

sudo apt install git-all

By doing this, GIT must be ready to run in our terminal.

3.3 On MacOS

For Mac, the easiest way to install GIT is to install Homebrew and then run the command below in the terminal:

brew install git

Then GIT must be ready to run in our terminal.

4. Configuring GIT

After installing, it's important to configure GIT with the commands below:

git config --global user.name "[username]"
# e.g. John Doe

git config --global user. email "[email@email.com]"
# e.g. johndoe@email.com

Also, it's possible to configure specific users for certain local repositories by removing the --global tag.

5. Starting a local repository

With GIT configured, we can start our local repository. To do this, we can start a new repository from scratch or clone an existing remote repository.

5.1 Starting from scratch (git init)

To start a new repository, simply navigate to the desired repository root folder and run the command below:

git init

By doing this, a .git directory will be created inside the project folder, which will be responsible for the version control in the working folder of this local repository.

5.2 Cloning an existing repository (git clone)

Cloning an existing remote repository is as easy as starting a new one from scratch. To do this, simply use the git clone command, with the remote repository URL to be cloned inside the folder where we want to download the repository:

git clone [repository-url]

Then the entire repository must be cloned to our local machine and automatically linked to the related remote repository.

With a cloned repository, we will no longer need to use the git remote command in the future.

6. Working with GIT

Within our local repository, we can create the files needed for our project, but they won't be automatically synced by GIT, we'll need to report it when there are any changes to be versioned.

Thus, we can manipulate the files as we wish and after finishing the desired changes, send the updated files to GIT.

To do this, it is important to understand that there is a 3 stage infinite flow (yes, infinite) in version control:

              MODIFY -> STAGE -> COMMIT

MODIFY: The first stage of version control, this is where we find the files that have changed compared to the last available version.
STAGE: The second stage of version control, this is where we place modified files that we want to add to our next commit.
COMMIT: Final stage of version control, when we confirm the changes, sending the modified files that were in stage to the local repository.

After committing the modified files, we have a new version available in the local repository, which can again receive updates, going one more time to "modified", then placed in "stage" and, again, being "committed", confirming a newer version and so on (and therefore, "infinite" lol).

It's important to notice that a commit doesn't overwrite the old version of the modified files, but includes the new version with a pointer to the last version, thus keeping track of the versions of each file tracked by GIT.

6.1 Adding and commiting (git add and git commit)

Although it might sounds complex, performing the version control flow is very simple. Since the desired modifications are completed, we add the modified files that we want to commit on stage with the command below:

git add [filename]

git add -A -> adds all modified files to stage at once.

git add *.[extensão-do-arquivo] -> adds all modified files with the specified file extension to stage at once (e.g. git add *.html)

We can check our current local repository status at any time using the git status command:

Note that when we run git status inside the repository after creating a new file, the new file is shown as "Untracked". This means that this file is fresh new and still needs to be added to any commit in order to be tracked by GIT.

It's possible to let GIT ignore specific files or folders within the repository. To do this, we can simply add a file to the root folder called .gitignore and write the name of the files or folders that should be ignored inside it.

CAUTION: Ignored files and folders will no longer appear to the GIT track, not even as "Untracked". To reset the tracking, simply delete the desired names from the .gitignore file.

To include a file, we can run the git add command with the name of the file that we want to add ("index.html" in this case):

This way, by re-running git status we can see that the new file has been added to "stage" and is finally ready to be sent in our next commit, which can be done using the command below:

git commit -m "[descriptive-message]"

Commits have unique IDs (hash codes) and are IMMUTABLE, i.e. they cannot be modified once they have been confirmed.

git commit -a -> performs a direct commit, adding all the modified files to stage and committing them.

After successfully committing a file, when running git status we notice that there are no more modified files to be uploaded, since all the modifications were effectively saved in our local repository with our last commit.

Also, it's possible to verify the changes made by reviewing the repository's commit log, using the git log command, which shows some metadata of all the commits made, such as the hash code, branch, author, date, etc.

This whole process can be repeated to add new files that are needed for our project, modify them and send them to the local repository by making new commits.

git log -N -> displays a log with the last N commits.

git log [branch-A] [branch-B] -> displays a log of commits that are in "branch-B" but not in "branch-A".

git log --follow [filename] -> displays a log of commits that changed the specified file, even if it has changed its name.

git diff -> lists the changes made compared to the latest available version in the repository.

git diff [nome-do-arquivo] -> lists the changes made to the specified file in relation to its last available version in the repository.

6.2 Undo changes before and after commiting

Before a commit is made, any changes made to the local repository can be undone or changed, but once the commit is made, it cannot be changed. This is because commits are immutable objects, meaning that it is impossible to edit or change the data in a commit.

However, it is possible to make new commits that undo changes, or correct incorrect information in previous commits. In either way, we can use one of the commands below:

git checkout -- [filename]
# Discards changes made to the local file before the commit (irreversible action)

git reset --hard HEAD
# Discards changes made to a file that is in stage (before the commit)

git reset --hard HEAD~1
# Discards the last commit made in the local repository (only the last commit)

git commit --amend
# Creates a new commit, replacing the last commit made in the local repository

git revert [commit-hash]
# Creates a new commit, reverting the changes of the specified commit

7. Knowing branches

A branch is nothing more than a ramification of the repository, and so far all actions have been performed on the branch master/main'.

By default, the first branch created in the repository is the master/main, which is the main branch of the repository.

7.1 Why use branches?

It may not seem like much at first, but branches give enormous power to the project development.

Imagine we're developing a web platform, and we want to test a new feature, but our repository is already hosted or shared with other people, and any problematic change could cause a bad experience for them. What can we do?

If you've been thinking about copy and paste the project folder, creating a new "test version", you're right! Well, almost...

With GIT, we can do something similar with branches. Since they are branches, we can simply create a new branch called "test", and thus have a version of our project in a completely isolated branch, ready to be flipped without risking the main branch.

7.2 Creating branches (git branch)

Creating a branch means creating a parallel copy of the repository that can be worked on independently, without affecting the master/main branch. To do this, we can simply run the command below:

git branch [branch-name]

Running the git branch command without a specific branch name must display the list of available branches in the repository, with a "*" marking the branch that's currently in use.

Before running the git branch test command, the git branch command only returned the master branch.

After creating a new branch, we can run the command below to switch between the available branches:

git checkout [branch-name]

After running the git checkout test command we can see that the active branch is switched. From that moment on, all committed information will be sent to the test branch of the repository, without affecting the branch master/main.

It's possible to create as many branches as we need, and we can interact with the existing branches using the commands below:

git checkout -b [branch-name] -> creates a new branch with the given name and directly switches to it.

git branch -d [branch-name] -> deletes the specified branch.

git branch -m [new-name] -> changes the name of the current branch to the given name.

7.3 Merging branches (git merge)

When finished working on a different branch, and we're sure that the changes we've made haven't caused any problems in the project, we can merge the current branch in the master/main branch, applying all the changes from the current branch to the main branch of the repository.

To merge branches, we need to switch to the branch that will receive the changes and run the following command:

git merge [branch-name]
# Merge the given branch into the active branch

Here, since we are on the branch test, we should switch to the branch master using the git checkout command, and then run the git merge command with the name of the branch we want to merge ("test", in this case).

By doing this, all the work done on the branch test (in this case, the creation of the style.css file) will be merged in the branch master.

7.4 Merge conflicts

Merging different branches with git merge can lead to some conflicts in cases where one or more files have been changed on the same lines and the merge cannot be done automatically.

When this happens, we can run the git status command to check which files are in conflict.

We'll need to solve the conflicts before proceeding with the merge, either by defining which changes should take place, or by reviewing the changes so that they are mutually compatible. To do this, GIT will insert markers into the conflicting files to help with the resolution.

After solving the conflicts, we just need to put the modified files back on stage, commit the new no-conflict versions, and run the git merge command again, which must successfully merge without any problems.

8. Syncing with the remote repository

We already know that it's possible to connect our local repository to a remote repository and synchronize all our work remotely, keeping it up to date.

To do this we'll need to run the git push command, which sends all commits from the local repository to the remote repository, but first we need to **configure a remote repository.

8.1 Configuring the remote repository

Starting a remote repository is quite simple. Here we'll use GitHub to do it.

First, we need to start a new empty repository in our GitHub account (just by choosing a name and clicking "Create repository"):

Next, we need to configure the relationship between the remote repository and the local repository by running the following command inside our local repository:

git remote add origin [remote-repository-url]

git remote -v -> shows the URL of the remote repository that's actually connected to the local repository.

With the remote repository properly connected, we need to change the name of our local branch master/main to "main" with the command git branch -m main (ignore this step if your local branch is already called main):

It's important to keep the main branch of the local repository with the same name as the main branch of the remote repository to which we are pushing.

Finally, after completing the above steps, we can sync our local repository with the remote repository for the first time using the following command:

git push -u origin main

When we run the git push -u origin main command, we may need to enter our GitHub credentials (user and access token).

If you don't know what a GitHub access token is, or you don't have one access token set up, click here.

We can also work around this by configuring authentication using the GitHub CLI. Find out how by clicking here.

After authenticating, git push should run successfully, synchronizing all commits in the local repository with the remote repository.

8.2 Git push after the first time (git push)

After going through all the above steps, new syncs can be done using the git push command alone, without any additional parameters, like shown below.

In this case, the authentication needed to run the command git push was bypassed using the GitHub CLI. You can find out how by clicking here.

8.3 Updating the local repository (git pull)

With a distributed remote repository, it's possible for changes to be made remotely (directly in the remote repository), causing our local repository to become outdated.

Thinking about that, it's very important to update the local repository and sync any changes that we got in the remote repository, ensuring that the local project is always with the latest version available in the remote repository. To do this we can run the following command:

git pull

Imagine that a new file README.md has been created directly in our remote repository and because of that our local repository is now outdated.

Within the local repository we can synchronize the changes from the remote repository using git pull as mentioned above.

The first 7 lines returned when we run the git pull command are the return of the git fetch command. In other words, if we run the git pull command without first running the git fetch command, GIT will run both together to retrieve the updates from the remote repository and synchronize them to the local repository.

git fetch -> fetch updates from the remote repository, but does not sync the local repository (requires git pull).

9. Conclusion

All this leads us to the certainty that GIT is a version control system that is necessary in the daily life of a programmer, and knowing its main commands and uses can be the turning point in our technical seniority. Finally, with the local and remote repositories synced and updated and with everything we've learned so far, we're ready to move forward with the practicality of this awesome version control system.