O que são os sistemas de versionamento?

Em suma, equipes de desenvolvedores precisavam de uma ferramenta e alternativa para gerenciar, controlar, armazenar todos os códios do projetos. Visto que fazer isso manualmente através de planilhas, comentários, papéis demandava muito trabalho e como era um trabalho humano é bastante sucétivel a erros. Então, surgiu a ideia de criar um robô que controlasse e armazenasse e catalogasse todo o código e as alterações feitas nele, mostrando também os conflitos no qual seriam armazenados dentro de um repositório, e também demandou a criação de uma aplicação e rede de hospedagem para esse repositório, como o GITHUB
Diante desta ideia surgiu o O Git, um sistema de controle de versão criado por Linus Torvalds

Preceitos do GIT

• Acompanhar as alterações desde as versões mais antigas

• A cada mudança que desejamos efetivar, devemos armazenar as alterações nesse repositório.

• Nos permite obter qualquer versão já existente do código

• Alterações nos mesmos arquivos são mescladas de maneira automática sempre que possível.

• possíveis conflitos são identificados e exibidos a cada vez que obtemos as mudanças

Comandos essenciais para o git

cd /caminho/ esse comando entra em diretórios e pastas. é usado para localizar arquivos. Para retornar um caminho/diretório usa-se cd..

O git rastreará todos as mudanças nos arquivos que forem adicionados ao repositório
git init inicializa um repositório dentro da pasta/diretório atual
git add "arquivo" adiciona um arquivo ao repositório
git status vê a situação atual do repositório, commits e arquivos adicionados
git log exibe o histórico de commits

Procedimento para salvar alterações dos arquivos modificados no repositório
1- git add "arquivo modificado" antes do commit e após cada ediçã 2-git commit -m "mensagem"
*é necessário fazer esse procedimento sempre que fizer alguma edição no arquivo

Clonando um repositório de alguém

Bom, como sabemos o sistema de rastreamento de arquivos opera dentro de pastas, então para cada projeto (repositório) precisamos criar uma pasta específica e localizá-la no diretório pela linha de comando

Passos para clonar um repositório (pessoal, ou de outra pessoa):

• Crie uma pasta no gerenciador de arquivos do seu sistema operacional

-No terminal, localize-a utilizando o cd (Change Directory :: Mudar diretório)
-Execute o comando git clone “url do repositório desejado”

IMPORTANTE!

Git e GitHub são a mesma coisa?
Não. Git é um sistema de controle de versionamento, com o qual interagimos
através linha de comando. Já o GitHub é uma rede social para programadores
que disponibiliza e armazena repositórios Git acessíveis remotamente. O GitHub é
muito utilizado para projetos open source que possuem vários colaboradores do mundo todo e também para equipes.

Agora que já foi mostrado os princípios básicos, é necessário esclarecer alguns detalhes

você deve ter notado que o comando git add ativa o rastreamento para um arquivo.

Ok. Mas e caso seja necessário fazer isso com vários arquivos? Não se preocupe, você não precisará fazer isso manualmente, a menos que queira

Basta usar o git add seguido de um . como no exemplo a seguir: git add . com isso todos os arquivos da pasta serão rastreados e linkados ao repositório remoto
e se quisermos adicionar todos o elementos de um diretório específico (caso haja vários)
git add nome da pasta.

- Restringindo arquivos

Em outra situação, precisamos adicionar arquivos no repositório, mas há arquivos que não possuem tanta utilidade, então eles devem ser ignorados, felizmente, o git possuí tal recurso para isso basta criar um arquivo com o nome .gitignore e adicionar o nome ou tipo dos arquivos que deseja ignorar dentro dele.
desse modo:

ignorar.txt (arquivo)
tmp/ (diretório/pasta)
.rty (tipos de arquivos)

Feito isso basta que você adicione o arquivo gitignore usando o procedimento convencional:
git add .gitignore

Quais tipos de arquivos devemos ignorar em projetos reais?
Bem, isso depende da tecnologia ou linguagem que está sendo usada no projeto. Já que cada um possuí suas especificidades
Mas o Github disponibiliza um repositório com os principais arquivos .gitignore segue o link:

GitHub - github/gitignore: A collection of useful .gitignore templates

O termo commit designa a gravação de criação/adição de novos arquivos ou alterações feitas nos mesmos. Comum em qualquer sistema de versão. Os termos “comitar” ou “comitado” não existem no dicionário, mas servem para definir o processo de gravação no repositório.

- O que significa o conceito de staging e staged no git?

Stage (área de staging ou index) é uma pasta que irá conter os arquivos que passaram a ser rastreados (tracked files) através do git add alterações que ainda não foram salvas no repositório git, entenda como um diretório “secundário” ou “temporário” que armazena os commits que posteriormente serão adicionados ao principal.
Nota: O git não rastreia pastas vazias

Exemplo de arquivo não rastreado (não presente na área de staging):

$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
stage.doc

nothing added to commit but untracked files present (use "git add" to track)

Exemplo de arquivo rastreado (presente na área de staging) através do git add stage.doc ou git stage stage.doc:

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   stage.doc

Nota: arquivos adicionados na área de staging estão preparados para serem commitados e para removê-los da área de staging usa-se "git restore --staged "arquivo" ou git restore -S "arquivo" ; **Apenas “S” não s!!

Porém, este comando remove as alterações apenas na área de staging, elas ainda estarão no diretório padrão, para descartar-las completamente usa-se git restore “arquivos” sem o “S” (Caso esteja na área de staging será necessário remover de ambas individualmente)**

• O conceito por trás da área de staging está no fato de permitir selecionar cautelosamente as alterações que que serão adicionadas, evitar erros e conflitos evitando assim a necessidade de desfazer constantemente reversões desnecessárias além de criar commits mais descritivos e eficientes

Remover mudanças não rastreadss (untracked ou unstaged)

Caso tenha feito uma mudança no arquivo, e este mesmo ainda não foi adicionado á área de Stage, e posteriormente deseja desfazer/reverter ao estado anterior, basta usar git checkout -- "arquivo.txt"

O comando git checkout desfaz as alterações ainda não rastreadas, ou seja, que ainda não estão na área de stage, voltando ao conteúdo anterior do arquivo (também serve para recuperar arquivos deletados acidentalmente)

Caso haja mudanças já rastreada no arquivo, dentro da área de stage, ao executarmos o comando git checkout, apenas as alterações fora da stage, serão desfeitas.

Como fazer Commit e rastrear arquivos simultaneamente

O git permite que você realize ambos através de git commit -a -m "mensagem" ou git commit -am "mensagem" e todas as alterações serão adicionadas ao staging e subsequentemente ( removida, já que serão commitado) commitadas.

A opção -a do comando git commit já efetua o rastreamento das mudanças, adicionando-as à área de stage, e a -m serve para designar a mensagem (descrição) do commit. Porém, ela não adiciona arquivos que ainda não foram adicionados (untracked files) sendo necessário fazer isso manualmente usando git add

Comparar e verificar as alterações

Seria bastante produtivo e eficiente se fosse possível ver as mudanças que foram feitas no arquivo não acha diretamente de um terminal sem abrir um editor de código? e isto é realidade graças ao git. O sistema possuí uma função que verifica e compara as alterações feitas com o commit mais recente através do comando git diff que mostra o que foi adicionado e removido em todos os arquivos, segue o exemplo:

$git diff

diff --git a/mimamumi.ppt b/mimamumi.ppt
index e69de29..5ae846f 100644
--- a/mimamumi.ppt
+++ b/mimamumi.ppt
@@ -0,0 +1,2 @@
+jijijiji      (linhas e textos adicionados
+jo
\ No newline at end of file
diff --git a/teste.txt b/teste.txt
index af949a9..ffc35ed 100644
--- a/teste.txt
+++ b/teste.txt
@@ -1,4 +1,5 @@
git config --global user.mail "seu email"
git config --global [user.name](http://user.name/) "seu nome"
dsaldsakdj
-lmjbug
\ No newline at end of file
+lmjbugsaddsdsadsad
+sadsad
\ No newline at end of file

Caso queira verificar apenas as alterações em um arquivo específico, basta usar git diff "arquivo" Porém, o “diff” sem parâmetros registra apenas arquivos não rastreados, isto é, que não estão dentro da área de Staging (não foram adicionados pelo git add). Para arquivos staged usa-se git diff --staged

Renomeando arquivos com git

Imagine a seguinte situação, você precisa renomear arquivos para enquadrar-se em novas nomenclaturas a fim de manter o padrão e legibilidade no seu projeto, se optasse pelo jeito manual, seria necessário copiar o conteúdo, excluir o arquivo original, criar outro com nome diferente e adicioná-lo ao git, esse método além de ser trabalhoso e desnecessário é também arriscado, visto que os commits anteriores são de outro arquivo e não é possível transferir para o novo. Por sorte, o Tio Linus Torvalds resolveu essa pra gente e criou uma função que altera o nome do arquivo e todos os commits passados.

Basta usar git mv "arquivo.txt" "novonome.txt" e voalá, renomeação concluída com sucesso, volte sempre!

Movendo Arquivos entre (sub)diretórios

Para mover arquivos para um subdiretório, primeiramente é necessário que haja um. Então hipoteticamente será definido um nome genérico para ilustrar, então /docs , feito isso para adicionarmos basta que usamos o mesmo comando que renomeação (explicarei o porquê logo abaixo) com o diretório “docs/arquivo.exe"

Ficando da seguinte forma: git mv arquivo.exe docs/arquivo.exe

Mas então, Sensei, Por quê o comando é o mesmo para renomear e mover?

Então, pequeno gafanhoto, Isto acontece devido a fins estratégico padrões da computação que visa economizar recursos e evitar processamento desnecessário afim de assegurar a eficiência do programa. Então para o git, seria demasiadamente trabalhoso e desnecessário separar e especificar cada um, sendo assim, o processo de renomeação e mudança do local é considerado a mesma coisa, visto que o conteúdo foi transferido para um novo local de qualquer forma.

Do ponto de vista computacional, a renomeação funciona da seguinte forma: os dados do arquivos são atualizados no registro do diretório, sendo assim, o arquivo não é movido no disco, ou seja, permanece o mesmo, mas com informações atualizadas.

Excluindo arquivos do repositório

O git permite que você exclua arquivos do repositório, no entanto, ele ficará salvo no histórico de commits, e portanto o seu tamanho permanecerá o mesmo. Ademais, é possível excluir permanentemente arquivos e será explicado posteriormente. Para excluir usa-se git -rm arquivo.

Lembrando que: cada alteração feita em arquivos independente de qual seja, até mesmo exclusão passa pelo ciclo “local-staging-commited”

Revertendo commits

Para reverter commits, é necessário possuir o código identificador que pode ser obtido através do git log —-oneline (estamos utilizando o parâmetro “oneline” pois só é necessário os 7 primeiros dígitos do código, diferente do que seria obtido se usássemos apenas git log)

O comando git revert --no-edit “1234567” reverte as alterações de determinado commit, o parâmetro “no-edit” é responsável por pular a mensagem de commit

Repositórios Remotos

Repositórios Bare X Repositórios comum (não-bare)

Repositórios Bare: repositório central armazenado remotamente, destinado a a integração e compartilhamento em ambientes de colaboração ondes todos podem efetuar alterações por pull ou push sem risco de conflitos, contém apenas as alterações(commits) e o código fonte armazenado, sem working tree e rastreamento de arquivos.

Repositórios comum: repositório local conectado diretamente ao git, usado por desenvolvedores individuais trabalharem ativamente em projetos editando, testando, adicionando ou removendo códigos, cada qual tem as sua própria cópia armazenadas na máquina, as mudanças feitas são detectadas pelo git, possuem área de staging e working tree, ou seja

Mas qual a necessidade de haver essa distinção?

Simples, para trabalhos com equipe, é conntra-produtivo que o código esteja armazenado localmente (em uma máquina) visto que pode acontecer problemas técnicos, erros de sincronização. Sendo assim, seria muito mais prático que desenvolvedores usassem um repositório central que será utilizado por todos e sincronizará todas as alterações automaticamente, e criasse um repositório local de trabalho conectados a este

Qual a origem do termo "bare"?

Em suma, significa "leve" ou "nu", uma analogia por conter apenas o essencial, no caso os metadados do repositório

Resumindo,

Os repositórios bare não possuem uma working tree logo, também não possuem área de staging — Github é um exemplo — , só ficam armazenadas as alterações feitas por pull ou push, sendo assim, para adicionar, remover, alterar o código, é necessário usar git push e adicionar a atualização ao repositório. Então, não é possível trabalhar utilizando repositório bare (github), sendo necessário clonar o respositório na máquina e assim poder fazer as possíveis e alterações e depois de feitas, adicionadas ao repositório central, remoto (Bare) via push ou pull

Site para treinar git:

Visualizing Git