├── .all-contributorsrc
├── 1-pre-requisitos
├── linux.md
├── pre-requisitos.md
└── windows.md
├── 2-o-que-e-git
├── primeiro-exemplo.md
└── segundo-exemplo.md
├── 3-comandos
├── branch.md
├── cherry-pick.md
├── commit.md
├── config.md
├── diff.md
├── fetch.md
├── log.md
├── merge.md
├── rebase.md
├── repositorio.md
├── reset.md
├── stash.md
├── status.md
└── tag.md
├── 4-gitflow
├── estrutura.md
├── exemplos.md
├── extensao-git-flow.md
├── git-flow-comandos.md
├── git-flow-instalacao.md
├── o-que-e-gitflow.md
├── padrao-commit.md
└── releases.md
├── README.md
├── conclusao.md
└── images
├── branches1.png
├── branches2.png
├── branchesx.png
├── commit1.png
├── commit2.png
├── git.svg
├── gitflow-example1.png
├── merge1.png
├── stash_caso_1.gif
└── stash_caso_2.gif
/.all-contributorsrc:
--------------------------------------------------------------------------------
1 | {
2 | "files": [
3 | "README.md"
4 | ],
5 | "imageSize": 100,
6 | "commit": false,
7 | "contributors": [
8 | {
9 | "login": "DanielHe4rt",
10 | "name": "Daniel Reis",
11 | "avatar_url": "https://avatars3.githubusercontent.com/u/6912596?v=4",
12 | "profile": "https://danielheart.dev",
13 | "contributions": [
14 | "code",
15 | "maintenance",
16 | "ideas",
17 | "review"
18 | ]
19 | },
20 | {
21 | "login": "filipe-crespo",
22 | "name": "Filipe Crespo",
23 | "avatar_url": "https://avatars2.githubusercontent.com/u/22672919?v=4",
24 | "profile": "https://github.com/filipe-crespo",
25 | "contributions": [
26 | "code",
27 | "maintenance",
28 | "ideas",
29 | "review"
30 | ]
31 | },
32 | {
33 | "login": "Ryandgs",
34 | "name": "Ryan Douglas",
35 | "avatar_url": "https://avatars1.githubusercontent.com/u/43894463?v=4",
36 | "profile": "https://github.com/Ryandgs",
37 | "contributions": [
38 | "code",
39 | "maintenance",
40 | "ideas",
41 | "review"
42 | ]
43 | }
44 | ],
45 | "contributorsPerLine": 7,
46 | "projectName": "git4noobs",
47 | "projectOwner": "DanielHe4rt",
48 | "repoType": "github",
49 | "repoHost": "https://github.com",
50 | "skipCi": true
51 | }
52 |
--------------------------------------------------------------------------------
/1-pre-requisitos/linux.md:
--------------------------------------------------------------------------------
1 | # Linux (Base Debian)
2 |
3 | Apenas execute o comando abaixo no seu terminal e a magica vai estar feita:
4 |
5 | ```
6 | sudo apt install git
7 | ```
8 |
9 | Ir para: [2.1 O que é git? - Primeiro Exemplo](../2-o-que-e-git/primeiro-exemplo.md)
10 |
--------------------------------------------------------------------------------
/1-pre-requisitos/pre-requisitos.md:
--------------------------------------------------------------------------------
1 | # Pré-requisitos
2 |
3 | Bom, só precisamos que você tenha o Git instalado na sua máquina. Aqui vai como você pode baixar:
4 |
5 | [Tutorial Linux](linux.md)
6 |
7 | [Tutorial Windows](windows.md)
8 |
--------------------------------------------------------------------------------
/1-pre-requisitos/windows.md:
--------------------------------------------------------------------------------
1 | # Windows
2 |
3 | Vá até o site [Git SCM](https://git-scm.com/downloads) e faça download da versão mais atualizada e siga os passos do instalador.
4 | Ao terminar o download você terá o app Git Bash instalado no seu Windows pronto para uso.
5 |
6 | Ir para: [2.1 O que é git? - Primeiro Exemplo](../2-o-que-e-git/primeiro-exemplo.md)
--------------------------------------------------------------------------------
/2-o-que-e-git/primeiro-exemplo.md:
--------------------------------------------------------------------------------
1 | # Primeiro Exemplo
2 |
3 | Git é um sistema de controle de versão de arquivos. Através dele podemos desenvolver projetos na qual diversas pessoas podem contribuir simultaneamente no mesmo, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas.
4 |
5 | Ir para: [2.2. Segundo Exemplo](segundo-exemplo.md)
--------------------------------------------------------------------------------
/2-o-que-e-git/segundo-exemplo.md:
--------------------------------------------------------------------------------
1 | # Segundo Exemplo
2 |
3 | Git é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo. Cada diretório de trabalho do Git é um repositório com um histórico completo e habilidade total de acompanhamento das revisões, não dependente de acesso a uma rede ou a um servidor central.
4 |
5 | Ir para: [3. Comandos e Conceitos - Repositório](../3-comandos/repositorio.md)
--------------------------------------------------------------------------------
/3-comandos/branch.md:
--------------------------------------------------------------------------------
1 | # Branch
2 |
3 | Simplificado: _Universo Paralelo_
4 | Podemos dizer que a branch é um universo ou uma realidade alternativa onde em algum ponto irá se juntar com a realidade principal. Achou esse exemplo estranho? Então deixa eu te mostrar uns exemplos.
5 | Pense em um cenário onde seu time encontra um problema que precisa ser resolvido, porém nem sempre há apenas uma única solução para finalizar essa tarefa, certo? É ai que a branch entra para ajudar nessa organização entre os devs.
6 | Continuando nesse cenário hipotético, os desenvolvedores irão criar uma nova vertente do código partindo da branch **master** (branch principal gerada a partir do primeiro commit), assim criando a branch implementacao-css.
7 |
8 | A tarefa hipotética é: implementar uma regra CSS especifica na nossa index.html.
9 |
10 | Porém, antes precisamos criar uma nova branch e para isso iremos usar o comando **git checkout** com o primeiro argumento **-b (branch)** e o segundo sendo o nome da nova branch.
11 |
12 | ```
13 | $ git checkout -b implementacao-css
14 | Switched to a new branch 'implementacao-css'
15 | $ git branch
16 | master
17 | * implementacao-css
18 | ```
19 |
20 | 
21 |
22 | Podemos ver que agora estamos em um outro universo diferente do principal (master) e toda e qualquer alteração feita nessa nova branch não afetará nenhuma outra dentro do projeto.
23 | Tá, mas o que eu faço com essa branch? A ideia é você ter liberdade para criar coisas novas sem alterar onde está tudo funcionando (master).
24 | Vamos fazer algumas alterações no nosso projeto dentro dessa nova branch:
25 |
26 | - Crie um novo arquivo na raiz do projeto chamado main.css
27 | - Commite esse arquivo com a mensagem "criação de arquivo main.css"
28 |
29 | ```
30 | $ touch main.css
31 | $ git add main.css
32 | $ git commit -m "criação de arquivo main.css"
33 | [implementacao-css f56f97a] criando arquivo main.css
34 | 1 file changed, 0 insertions(+), 0 deletions(-)
35 | create mode 100644 main.css
36 | ```
37 |
38 | Após isso iremos fazer outro commit para adicionar uma regra css simples a esse arquivo. Apenas entre no arquivo criado e adicione alguma regra a tag body:
39 |
40 | ```css
41 | /*
42 | Arquivo: ./main.css
43 | */
44 | body {
45 | background-color: mediumpurple;
46 | color: white;
47 | }
48 | ```
49 |
50 | Salve o arquivo alterado com os mesmos comandos feitos anteriormente e faça mais um commit:
51 |
52 | ```
53 | $ git add main.css
54 | $ git commit -m "adicionando regras para o main.css"
55 | [implementacao-css ab4a625] adicionando regras para o main.css
56 | 1 file changed, 5 insertions(+)
57 | ```
58 |
59 | Podemos ver na imagem abaixo que há duas linhas de tempo diferentes que não se conflitaram (até o momento) e podem ser alteradas sem que ninguém atropele o código do outro no projeto, evitando conflitos e sempre mantendo tudo que é feito documentado dentro do repositório.
60 |
61 | 
62 |
63 | Ir para [3.5. Merge](merge.md)
--------------------------------------------------------------------------------
/3-comandos/cherry-pick.md:
--------------------------------------------------------------------------------
1 | # Cherry Pick
2 |
3 | O comando `cherry-pick` é usado para pegar um commit específico de uma branch e aplicar em outra branch.
4 |
5 | ## Exemplo
6 |
7 | Vamos supor que você está trabalhando em uma branch `feature` e você precisa aplicar um commit específico da branch `main` na sua branch `feature`. Para isso, você pode usar o comando `cherry-pick`:
8 |
9 | ```bash
10 | git cherry-pick
11 | ```
12 |
13 | ## Como usar
14 |
15 | Dando um exemplo de estado de ramificação:
16 |
17 | ```
18 | a - b - c - d Main
19 | \
20 | e - f - g Feature
21 | ```
22 |
23 | Se você quiser aplicar o commit `c` na branch `Feature`, você pode usar o comando `cherry-pick`:
24 |
25 | ```bash
26 | git cherry-pick c
27 | ```
28 |
29 | O resultado será:
30 |
31 | ```
32 | a - b - c - d Main
33 | \
34 | e - f - g - c' Feature
35 | ```
36 |
37 | ## Intervalo de commits
38 |
39 | Você também pode usar o comando `cherry-pick` para aplicar um intervalo de commits. Por exemplo, se você quiser aplicar os commits `b` e `c` na branch `Feature`, você pode usar o comando `cherry-pick`:
40 |
41 | Há algumas formas de fazer isso:
42 |
43 | ```sh
44 | # opção 1
45 | git cherry-pick b^..d
46 | # opção 2
47 | git cherry-pick b..d
48 | ```
49 |
50 | Na opção 1, indica que todos os commits entre o commit `b` (exclusivo) e o commit `d` (inclusivo) serão aplicados na branch `Feature`.
51 |
52 | O `^` apos o commit `b` indica que o commit `b` não será aplicado.
53 |
54 | Então irá ser aplicado todas as alterações entre o commit `b` e o commit `d` na branch `Feature`.
55 |
56 | O resultado será:
57 |
58 | ```
59 | # Opção 1: b^..d
60 | a - b - c - d Main
61 | \
62 | e - f - g - c' - d' Feature
63 | ```
64 |
65 | Na opção 2, indica que todos os commits entre o commit `b` (inclusivo) e o commit `d` (inclusivo) serão aplicados na branch `Feature`, mas não irá aplicar o commit `b`.
66 |
67 | O resultado será:
68 |
69 | ```
70 | # Opção 2: b..d
71 | a - b - c - d Main
72 | \
73 | e - f - g - b' - c' - d' Feature
74 | ```
75 |
76 |
77 | ## Conflitos
78 |
79 | Pode haver casos em que o Git reconheça conflitos entre o commit que esta sendo cherry-picked e as mudanças da branch de destino, nesse caso você precisará resolver manualmente as mudanças.
80 |
81 | Depois que resolver os conflitos, você indica que as mudanças foram resolvidas com o comando:
82 |
83 | ```bash
84 | git add
85 | git cherry-pick --continue
86 | ```
87 |
88 | Ao executar o comando, o Git irá criar um novo commit com as mudanças resolvidas e que o git pode continuar no processo de aplicação dos commits.
89 |
90 | Mas caso você queira abortar o cherry-pick, você pode usar o comando:
91 |
92 | ```bash
93 | git cherry-pick --abort
94 | ```
95 |
96 |
97 | ## Comandos complementares
98 |
99 | O comando `cherry-pick` pode ser usado em conjunto com outros comandos, conhecidas como `flags`, como por exemplo:
100 |
101 |
102 | `git cherry-pick --edit ` - Abre o editor de texto para editar a mensagem do commit
103 |
104 | `git cherry-pick --signoff ` - Adiciona a assinatura do autor do commit
105 |
106 | `git cherry-pick --no-commit ` - Aplica o commit sem fazer o commit
107 |
108 | `git cherry-pick --continue ` - Continua o cherry-pick após resolver os conflitos
109 |
110 | `git cherry-pick --abort ` - Cancela o cherry-pick
111 |
112 | `git cherry-pick --quit ` - Sai do cherry-pick
113 |
114 | `git cherry-pick --ff ` - Aplica o commit com fast-forward
115 |
116 | `git cherry-pick --no-ff ` - Aplica o commit sem fast-forward
117 |
118 | `git cherry-pick --allow-empty ` - Permite que o cherry-pick seja feito em um commit vazio
119 |
120 | `git cherry-pick --keep-redundant-commits ` - Mantém os commits redundantes
121 |
122 | `git cherry-pick --mainline ` - Define a linha principal de desenvolvimento
123 |
124 | `git cherry-pick --quiet ` - Não mostra o log do cherry-pick
125 |
126 | `git cherry-pick --verbose ` - Mostra o log do cherry-pick
127 |
128 | `git cherry-pick --progress ` - Mostra o progresso do cherry-pick
129 |
130 | `git cherry-pick --no-progress ` - Não mostra o progresso do cherry-pick
131 |
132 |
133 | Sim, existem várias possibilidades de uso do comando `cherry-pick`. Você pode ver mais detalhes sobre o comando `cherry-pick` na [documentação oficial](https://git-scm.com/docs/git-cherry-pick/pt_BR).
134 |
135 |
--------------------------------------------------------------------------------
/3-comandos/commit.md:
--------------------------------------------------------------------------------
1 | # Commit
2 |
3 | Simplificado: _Registro de um diário_
4 | Um dos problemas mais mundanos no desenvolvimento de software, é que com o dado tempo de um projeto em andamento, as pessoas começam a esquecer o quê e o porquê estão fazendo aquilo.
5 | Enquanto você trabalha em um projeto, você pode editar e salvar arquivos no seu repositório quantas vezes você quiser. E em certo ponto, você decidir **commitar** suas alterações para o seu repositório.
6 |
7 | Vamos dar um exemplo abaixo (no CLI e exemplo visual):
8 |
9 | - Crie um arquivo na raiz do seu projeto (Repositório) chamado `index.html` e adicione algum conteúdo a ele
10 | - Logo após adicione o arquivo criado a lista de alterações com o comando `git add nomearquivo`
11 | - Crie um novo registro (commit) repositório
12 |
13 | ```
14 | echo "Hello Rocket Devs" > index.html
15 | git add index.html
16 | git commit -m "inserção de index.html"
17 | ```
18 |
19 | 
20 |
21 | Em um certo ponto, você percebe que cometeu algum erro ao subir essa alteração no seu projeto. Agora você tem duas opções: reverter ou sobrescrever.
22 | Nesse caso, iremos sobrescrever a alteração para manter o registro anterior no nosso repositório com os passos abaixo:
23 |
24 | - Altere o texto da sua index.html para "Hello He4rt Devs"
25 | - Salve o arquivo e adicione a lista de alterações com o comand `git add nomearquivo`
26 | - Crie um novo registro (commit) no seu repositório com uma descrição usando o comando `git commit -m "alteração index.html"`
27 |
28 | ```
29 | echo "Hello He4rt Devs" > index.html
30 | git add index.html
31 | git commit -m "alteração de index.html"
32 | ```
33 |
34 | 
35 |
36 | Após fazer a alteração, podemos ver que foi adicionado outro registro em nosso repositório, uma nova entrada na qual está marcada as alterações mais recentes e com os registros anteriores guardados e documentados igualmente.
37 |
38 | Um commit significa a adição/alteração/remoção de um ou mais arquivos dentro do seu repositório.
39 |
40 | Ir para: [3.4. Branch](branch.md)
--------------------------------------------------------------------------------
/3-comandos/config.md:
--------------------------------------------------------------------------------
1 | # Config
2 |
3 | Simplificado: _Configurações gerais_
4 | Para uma boa usabilidade e um bom rendimento o **config** e uma forma de deixar suas configurações padrões do jeito que você deseja.
5 |
6 | Imagine você e um amigo querem criar um novo projeto e precisão utiliza o git, com isso e possivel criar uma configuração na sua maquina ou no seu repositorio local do git que assine todos os commits feito por você com o seu nome tendo assim uma melhor visualização de quem fez aquele respectivo commit.
7 |
8 | Adicionando o seu **nome** e **e-mail** nas configurações global para que o git assine os commits automaticamente.
9 | ```
10 | $ git config --global user.name "Seu Nome"
11 |
12 | $ git config --global user.email "Seu Email"
13 | ```
14 |
15 | Listando todas as configurações existentes:
16 | ```
17 | git config --list
18 | ```
19 |
20 | Ir para: [3.3. Commit](commit.md)
--------------------------------------------------------------------------------
/3-comandos/diff.md:
--------------------------------------------------------------------------------
1 | # Diff
2 |
3 | Passamos por todo esse processo de criar commits e entender branches, creio que tenha ficado bem claro que há um fluxo a ser seguido. Mas como vamos saber o que exatamente foi alterado nos arquivos?
4 | O comando **git diff nomearquivo.ext** consegue resolver esse problema e para entendermos melhor, iremos fazer algumas alterações no nosso projeto:
5 |
6 | - Altere o arquivo **main.css** adicionando e editando as linhas descritas abaixo;
7 | - Utilize o comando **"git diff main.css"** para ver as alterações criadas.
8 |
9 | ```css
10 | /*
11 | Arquivo: ./main.css
12 | */
13 | body {
14 | background-color: mediumpurple;
15 | color: red;
16 | }
17 | p {
18 | color: blue;
19 | }
20 | ```
21 |
22 | ```
23 | $ git diff main.css
24 | diff --git a/main.css b/main.css
25 | index 85d348e..2cfe522 100644
26 | --- a/main.css
27 | +++ b/main.css
28 | @@ -1,4 +1,8 @@
29 | body{
30 | background-color:mediumpurple;
31 | - color:white;
32 | + color:red;
33 | +}
34 | +
35 | +p{
36 | + color:blue;
37 | }
38 | ```
39 |
40 | Agora vamos para uma breve interpretação do retorno acima:
41 |
42 | - Ele está comparando com o último commit feito no mesmo arquivo;
43 | - O sinal "+" significa tudo que foi ADICIONADO ao documento;
44 | - O sinal "-" significa tudo que foi REMOVIDO do document.
45 |
46 | Uma coisa interessante de saber é que se você adicionar o arquivo com o **"git add"** e tentar usar o **"git diff"** no mesmo arquivo, você não verá as alterações pois elas já estão prontas para serem commitadas.
47 |
48 | Ir para: [3.8. Tag](tag.md)
--------------------------------------------------------------------------------
/3-comandos/fetch.md:
--------------------------------------------------------------------------------
1 | # Fetch
2 |
3 | Com o comando `fetch` atualizamos nossa árvore de commits local para a árvore do nosso repositório. Baixando todas as branchs e todas as tags presentes para o nosso local podendo utilizá-las.
4 |
5 | Podemos atualizar todo o projeto:
6 |
7 | ```bash
8 | git fetch --all
9 | ```
10 |
11 | Ou podemos especificar uma branch:
12 |
13 | ```bash
14 | git fetch origin master
15 | ```
16 |
17 | Ir para: [3.11. Log](../3-comandos/log.md)
18 |
--------------------------------------------------------------------------------
/3-comandos/log.md:
--------------------------------------------------------------------------------
1 | # Log
2 |
3 | Este comando puxa o histórico de alterações que o projeto teve até o momento. Mostrando da alteração mais recente para a mais antiga, assim você pode entender as mudanças que outras pessoas realizaram ou mudanças que você próprio fez.
4 |
5 | Você pode usar as teclas de seta para cima e para baixo para percorrer os registros e pressionar o Q para retornar ao terminal.
6 | ```
7 | $ git log
8 |
9 | Estrutura
10 |
11 | commit: codigo hash
12 | Autor: autor da alteração
13 | Data: data da alteração
14 | Mensagem do commit
15 | ```
16 |
17 | Verificar o que foi mudado nos arquivos
18 | ```
19 | $ git log -p
20 | ```
21 |
22 | Mostrar estatísticas de todos os commits como:
23 | - Hash completa
24 | - Data
25 | - Comentário
26 | - Quantidade de alterações
27 | ```
28 | $ git log --stat
29 | ```
30 |
31 | Mostrar o commit inteiro de forma reduzida
32 | ```
33 | $ git log --oneline
34 | ```
35 |
36 | Mostrar histórico de alterações filtrando por um autor especifico
37 | ```
38 | $ git log --author=usuario
39 | ```
40 |
41 | Exibir o historico das das ultimas 2 alterações
42 | ```
43 | $ git log -p -2
44 | ```
45 |
46 | exibir o histórico de uma arquivo em especifico
47 | ```
48 | git log --
49 | ```
50 |
51 | Ir para: [4.1 Gitflow - O que é Git Flow](../4-gitflow/o-que-e-gitflow.md)
--------------------------------------------------------------------------------
/3-comandos/merge.md:
--------------------------------------------------------------------------------
1 | # Merge
2 |
3 | Simplificado: _Fusão de duas branches_
4 | Quando algum desenvolvedor falar de **merge**, quer dizer que houve uma fusão ou junção de códigos em uma única branch. Tá, mas como assim?
5 | Vamos continuar na nossa situação hipotética dos commits acima, já que temos duas branches nesse repositório. Iremos criar um merge da branch **implementacao-css** para a branch **master**. Em outras palavras, vamos juntar todas as alterações feitas na branch **implementacao-css** dentro da branch **master**, mantendo a nossa master com todo o conteúdo.
6 |
7 | ```
8 | $ git checkout master
9 | $ git merge implementacao-css
10 | Updating 9b61048..ab4a625
11 | Fast-forward
12 | main.css | 5 +++++
13 | 1 file changed, 5 insertions(+)
14 | create mode 100644 main.css
15 | ```
16 |
17 | 
18 |
19 | Podemos ver que a master agora possui as funcionalidades da implementação-css sem precisar mexer em nada relacionado a ela, e em questão de organização você sabe onde e quando foi feito as alterações.
20 |
21 | Ir para: [3.6. Status](status.md)
--------------------------------------------------------------------------------
/3-comandos/rebase.md:
--------------------------------------------------------------------------------
1 | # Rebase
2 |
3 | O comando rebase é responsavel por reorganizar os commits de uma branch, nos permitindo alguns comando nos commits selecionados.
4 | Mais opções deste comando na [documentação do git](https://git-scm.com/docs/git-rebase).
5 | O mais comum do uso do rebase é para mesclarmos commit, agrupando alterações em apenas um.
6 |
7 | ## Rebase Interativo
8 |
9 | ```bash
10 | git rebase -i HEAD~2 # o 2 representa o numero de commits que o comando irá buscar para o rebase.
11 | ```
12 |
13 | Após rodar este comando é apresentado em seu editor padrão do git, um arquivo para você editar os comandos, e executar a tarefa desejada.
14 |
15 | ```txt
16 | 1 pick d93ec63 Add dockerfile and docker-compose.yml
17 | 2 pick 3be8acd Add dockerfile and docker-compose.yml
18 | 3
19 | 4 # Rebase 7b870a1.git commit --amend.3be8acd onto 7b870a1 (2 commands)
20 | .
21 | .
22 | .
23 | ```
24 |
25 | Commandos:
26 |
27 | * p, pick = usa o commit
28 | * r, reword = usa o commit, mas edita a mensagem do commit
29 | * e, edit = usa o commit, mas para alterar
30 | * s, squash = usa o commit, mas junta com o commit anterior
31 | * f, fixup = igual ao commando "squash", mas discarta a mensagem do commit
32 | * x, exec = run command (the rest of the line) using shell
33 | * b, break = para no commit, apenas continua o rebase apost 'git rebase --continue'
34 | * d, drop = remove o commit
35 | * l, label