├── ApostilaGit.brf ├── ApostilaGit.idx ├── .gitignore ├── ApostilaGit.pdf ├── imagens ├── cmder.png ├── logp.png ├── merge.png ├── comandos.png ├── commit.png ├── commit2.png ├── develop.png ├── estagio1.png ├── estagio2.png ├── estagio3.png ├── feature.png ├── gitlog.png ├── hotfix.png ├── pretty.png ├── rebase.png ├── repositorio ├── terminal.png ├── voltando.png ├── conflito1.png ├── conflito2.png ├── conflito3.png ├── conflito4.png ├── estrategia.png ├── gitignore.png ├── novobranch.png ├── configuracao.png ├── criandorep1.png ├── criandorep2.png ├── criandorep3.png ├── criandorep4.png ├── initGitFlow.png ├── repositorio.png ├── feature-merges.png └── merge.svg ├── Informações ├── bugfix4.png ├── bugfixes.png ├── bugfixes2.png ├── features.png ├── gitflow.png ├── hotfixes.png ├── hotfixes2.png └── release3.png ├── ApostilaGit.blg ├── README.md ├── biblio.bib ├── ApostilaGit.bbl └── ApostilaGit.tex /ApostilaGit.brf: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ApostilaGit.idx: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.log 2 | *.aux 3 | *.lof 4 | *.gz 5 | *.toc 6 | -------------------------------------------------------------------------------- /ApostilaGit.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/ApostilaGit.pdf -------------------------------------------------------------------------------- /imagens/cmder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/cmder.png -------------------------------------------------------------------------------- /imagens/logp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/logp.png -------------------------------------------------------------------------------- /imagens/merge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/merge.png -------------------------------------------------------------------------------- /imagens/comandos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/comandos.png -------------------------------------------------------------------------------- /imagens/commit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/commit.png -------------------------------------------------------------------------------- /imagens/commit2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/commit2.png -------------------------------------------------------------------------------- /imagens/develop.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/develop.png -------------------------------------------------------------------------------- /imagens/estagio1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/estagio1.png -------------------------------------------------------------------------------- /imagens/estagio2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/estagio2.png -------------------------------------------------------------------------------- /imagens/estagio3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/estagio3.png -------------------------------------------------------------------------------- /imagens/feature.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/feature.png -------------------------------------------------------------------------------- /imagens/gitlog.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/gitlog.png -------------------------------------------------------------------------------- /imagens/hotfix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/hotfix.png -------------------------------------------------------------------------------- /imagens/pretty.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/pretty.png -------------------------------------------------------------------------------- /imagens/rebase.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/rebase.png -------------------------------------------------------------------------------- /imagens/repositorio: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/repositorio -------------------------------------------------------------------------------- /imagens/terminal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/terminal.png -------------------------------------------------------------------------------- /imagens/voltando.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/voltando.png -------------------------------------------------------------------------------- /imagens/conflito1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/conflito1.png -------------------------------------------------------------------------------- /imagens/conflito2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/conflito2.png -------------------------------------------------------------------------------- /imagens/conflito3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/conflito3.png -------------------------------------------------------------------------------- /imagens/conflito4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/conflito4.png -------------------------------------------------------------------------------- /imagens/estrategia.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/estrategia.png -------------------------------------------------------------------------------- /imagens/gitignore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/gitignore.png -------------------------------------------------------------------------------- /imagens/novobranch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/novobranch.png -------------------------------------------------------------------------------- /Informações/bugfix4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/bugfix4.png -------------------------------------------------------------------------------- /Informações/bugfixes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/bugfixes.png -------------------------------------------------------------------------------- /Informações/bugfixes2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/bugfixes2.png -------------------------------------------------------------------------------- /Informações/features.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/features.png -------------------------------------------------------------------------------- /Informações/gitflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/gitflow.png -------------------------------------------------------------------------------- /Informações/hotfixes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/hotfixes.png -------------------------------------------------------------------------------- /Informações/hotfixes2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/hotfixes2.png -------------------------------------------------------------------------------- /Informações/release3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/Informações/release3.png -------------------------------------------------------------------------------- /imagens/configuracao.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/configuracao.png -------------------------------------------------------------------------------- /imagens/criandorep1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/criandorep1.png -------------------------------------------------------------------------------- /imagens/criandorep2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/criandorep2.png -------------------------------------------------------------------------------- /imagens/criandorep3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/criandorep3.png -------------------------------------------------------------------------------- /imagens/criandorep4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/criandorep4.png -------------------------------------------------------------------------------- /imagens/initGitFlow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/initGitFlow.png -------------------------------------------------------------------------------- /imagens/repositorio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/repositorio.png -------------------------------------------------------------------------------- /imagens/feature-merges.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/angelomedeiros/apostila-git/HEAD/imagens/feature-merges.png -------------------------------------------------------------------------------- /ApostilaGit.blg: -------------------------------------------------------------------------------- 1 | This is BibTeX, Version 0.99dThe top-level auxiliary file: ApostilaGit.aux 2 | The style file: abntex2-alf.bst 3 | Database file #1: abntex2-options.bib 4 | Database file #2: biblio.bib 5 | Warning--I didn't find a database entry for "moura" 6 | Warning--campo year vazio ou faltando em nvie 7 | Warning--campo year vazio ou faltando em marklodato 8 | Warning--campo year vazio ou faltando em gitready 9 | Warning--campo year vazio ou faltando em cgti 10 | Warning--campo year vazio ou faltando em danielkummer 11 | Warning--campo year vazio ou faltando em stackoverflow2 12 | Warning--campo year vazio ou faltando em devmedia1 13 | Warning--campo year vazio ou faltando em book 14 | Warning--campo year vazio ou faltando em rogerdudler 15 | Warning--campo year vazio ou faltando em ndpsoftware 16 | Warning--campo year vazio ou faltando em gitlab 17 | Warning--campo year vazio ou faltando em wikiversity 18 | Warning--campo year vazio ou faltando em devmedia2 19 | Warning--campo year vazio ou faltando em atlassian 20 | Warning--campo year vazio ou faltando em gitflow 21 | Warning--campo year vazio ou faltando em semver 22 | Warning--campo year vazio ou faltando em tribo 23 | Warning--campo year vazio ou faltando em stackoverflow 24 | +---------------------------------------------------------+ 25 | | Estilo bibliográfico abntex2-alf.bst versão v-1.9.6 | 26 | | Em caso de dúvidas ou problemas com este estilo procure | 27 | | http://www.abntex.net.br/ | 28 | +---------------------------------------------------------+ 29 | (There were 19 warnings) 30 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Uma breve introdução ao Git, GitLab e Git-flow 2 | 3 | Essa apostila tem como objetivo plantar uma sementinha na mente de vocês sobre 4 | o controle de versão, suas vantagens e como ele tornará seu desenvolvimento mais ágil e 5 | seguro. 6 | 7 | ## Sumário 8 | 9 | 1. ANTES DE TUDO, O QUE É CONTROLE DE VERSÃO? 10 | 1. O Git 11 | 1. O GitLab 12 | 1. O Git-flow 13 | 1. A ESTRATÉGIA DE RAMIFICAÇÃO 14 | 1. Os branches 15 | 1. O branch master 16 | 1. O branch develop 17 | 1. O branch feature 18 | 1. O branch release 19 | 1. Os branches hotfixes e bugfixes 20 | 1. PRIMEIROS PASSOS COM O GIT 21 | 1. Configuração inicial 22 | 1. OS 3 ESTÁGIOS 23 | 1. Criando um repositório 24 | 1. O primeiro estágio 25 | 1. O segundo estágio 26 | 1. O terceiro estágio 27 | 1. COMANDOS MAIS USADOS NO GIT 28 | 1. Visualizando o log 29 | 1. Criando branches 30 | 1. Mesclando branches 31 | 1. Mesclando usando o merge 32 | 1. Mesclando usando o rebase 33 | 1. Voltando versões 34 | 1. Algumas dicas 35 | 1. Ignorando arquivos com o Git 36 | 1. Alterando o proxy 37 | 1. TRABALHANDO COM REPOSITÓRIO REMOTO 38 | 1. Criando seu primeiro repositório remoto 39 | 1. Realizando seu primeiro push 40 | 1. Realizando seu primeiro clone 41 | 1. Criando um branch a partir do repositório remoto 42 | 1. Realizando seu primeiro pull 43 | 1. Trabalhando com tags 44 | 1. Versionamento Semântico 45 | 1. Criando tags com o git 46 | 1. Resolvendo conflitos 47 | 1. TRABALHANDO COM O GIT-FLOW 48 | 1. Criando o repositório usando o git-flow 49 | 1. Criando features 50 | 1. Criando releases 51 | 1. Criando hotfixes 52 | 1. Criando bugfixes 53 | 1. Resumo dos comandos do git-flow 54 | 55 | ## Apostila sobre git, gitLab e git-flow 56 | Download da apostila 57 | 58 | ### Como a apostila foi escrita? 59 | 60 | A apostila foi escrita utilizando o LaTeX(conjunto de macros para diagramação de textos). 61 | 62 | ## Encontrou algum erro ou quer contribuir? 63 | 64 | Para reportar um erro crie um novo _issue_ e para contribuir faça um _fork_(solicite pull request depois). Se você ainda não têm experiência com o gitHub envie um email para angeloprogrammer@gmail.com. 65 | 66 | ## Contato 67 | 68 | Qualquer dúvida envie um email para angeloprogrammer@gmail.com. 69 | 70 | -------------------------------------------------------------------------------- /biblio.bib: -------------------------------------------------------------------------------- 1 | @misc{cgti, 2 | subtitle={Modelo desenvolvimento}, 3 | title={CGTI}, 4 | url={http://git.mj.gov.br/CGTI/modelo-desenvolvimento/wikis/Manual-do-Usuario#manual-do-usu-rio}, 5 | urlaccessdate={24 ago. 2017}} 6 | 7 | @misc{gitready, 8 | subtitle={git ready}, 9 | title={Atalho para comandos \'uteis}, 10 | url={http://pt-br.gitready.com/intermediario/2009/02/06/helpful-command-aliases.html}, 11 | urlaccessdate={26 ago. 2017}} 12 | 13 | @misc{stackoverflow, 14 | subtitle={stackoverflow}, 15 | title={What's the difference between 'git merge' and 'git rebase'?}, 16 | url={https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase/16666418#16666418}, 17 | urlaccessdate={25 ago. 2017}} 18 | 19 | @misc{atlassian, 20 | subtitle={Atlassian}, 21 | title={Merging vs. Rebasing}, 22 | url={https://www.atlassian.com/git/tutorials/merging-vs-rebasing}, 23 | urlaccessdate={26 ago. 2017}} 24 | 25 | @misc{ndpsoftware, 26 | subtitle={ndpsoftware}, 27 | title={Git Cheatsheet}, 28 | url={http://ndpsoftware.com/git-cheatsheet.html#loc=stash;}, 29 | urlaccessdate={26 ago. 2017}} 30 | 31 | @misc{rogerdudler, 32 | subtitle={rogerdudler}, 33 | title={git - guia prático}, 34 | url={http://rogerdudler.github.io/git-guide/index.pt_BR.html}, 35 | urlaccessdate={28 ago. 2017}} 36 | 37 | @misc{danielkummer, 38 | subtitle={danielkummer}, 39 | title={cheatsheet do git-flow}, 40 | url={https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html}, 41 | urlaccessdate={27 ago. 2017}} 42 | 43 | @misc{nvie, 44 | subtitle={nvie}, 45 | title={A successful Git branching model}, 46 | url={http://nvie.com/posts/a-successful-git-branching-model/}, 47 | urlaccessdate={29 ago. 2017}} 48 | 49 | @misc{gitflow, 50 | author={Fernando Jorge Mota}, 51 | title={Git Flow – Uma forma legal de organizar repositórios git}, 52 | url={https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git/}, 53 | urlaccessdate={29 ago. 2017}} 54 | 55 | @misc{wikiversity, 56 | subtitle={wikiversity}, 57 | title={GitLab}, 58 | url={https://pt.wikiversity.org/wiki/GitLab}, 59 | urlaccessdate={28 ago. 2017}} 60 | 61 | @misc{stackoverflow2, 62 | subtitle={stackoverflow}, 63 | title={Como excluir um ramo(branch) do Git local e remoto?}, 64 | url={https://pt.stackoverflow.com/questions/61428/como-excluir-um-ramobranch-do-git-local-e-remoto}, 65 | urlaccessdate={26 ago. 2017}} 66 | 67 | @misc{tribo, 68 | subtitle={Tribo do C.I.}, 69 | title={TOP 5 REPOSITÓRIOS DE CÓDIGO FONTE GRÁTIS PARA O SEU SOFTWARE}, 70 | url={http://tribodoci.net/artigos/top-5-repositoros-de-codigo-fonte-gratis-para-o-seu-software/}, 71 | urlaccessdate={27 ago. 2017}} 72 | 73 | @misc{devmedia1, 74 | subtitle={DevMedia}, 75 | title={Ger\^encia de Configuração de Software}, 76 | url={http://www.devmedia.com.br/gerencia-de-configuracao-de-software/9145}, 77 | urlaccessdate={29 ago. 2017}} 78 | 79 | @misc{devmedia2, 80 | author={juanplopes}, 81 | title={Integração Contínua - Artigo .net Magazine 85}, 82 | url={http://www.devmedia.com.br/integracao-continua-artigo-net-magazine-85/21086}, 83 | urlaccessdate={29 ago. 2017}} 84 | 85 | @misc{book, 86 | subtitle={Book}, 87 | title={Git}, 88 | url={https://git-scm.com/book/pt-br/v2}, 89 | urlaccessdate={26 ago. 2017}} 90 | 91 | @misc{marklodato, 92 | subtitle={marklodato}, 93 | title={A Visual Git Reference}, 94 | url={http://marklodato.github.io/visual-git-guide/index-en.html}, 95 | urlaccessdate={26 ago. 2017}} 96 | 97 | @misc{gitlab, 98 | subtitle={Documentação}, 99 | title={GitLab}, 100 | url={https://docs.gitlab.com/ee/README.html}, 101 | urlaccessdate={25 ago. 2017}} 102 | 103 | @misc{semver, 104 | subtitle={semver}, 105 | title={Semantic Versioning 2.0.0}, 106 | url={http://semver.org/}, 107 | urlaccessdate={29 ago. 2017}} 108 | 109 | -------------------------------------------------------------------------------- /ApostilaGit.bbl: -------------------------------------------------------------------------------- 1 | \providecommand{\abntreprintinfo}[1]{% 2 | \citeonline{#1}} 3 | \setlength{\labelsep}{0pt}\begin{thebibliography}{} 4 | \providecommand{\abntrefinfo}[3]{} 5 | \providecommand{\abntbstabout}[1]{} 6 | \abntbstabout{v-1.9.6 } 7 | 8 | \bibitem[A successful Git branching model]{nvie} 9 | \abntrefinfo{A\ldots}{A\ldots}{a} 10 | {A successful Git branching model: nvie. 11 | Dispon{\'\i}vel em: 12 | $<$http://nvie.com/posts/a-successful-git-branching-model/$>$. Acesso em: 29 13 | ago. 2017.} 14 | 15 | \bibitem[A Visual Git Reference]{marklodato} 16 | \abntrefinfo{A\ldots}{A\ldots}{b} 17 | {A Visual Git Reference: marklodato. 18 | Dispon{\'\i}vel em: 19 | $<$http://marklodato.github.io/visual-git-guide/index-en.html$>$. Acesso em: 20 | 26 ago. 2017.} 21 | 22 | \bibitem[Atalho para comandos \'uteis]{gitready} 23 | \abntrefinfo{Atalho\ldots}{ATALHO\ldots}{} 24 | {ATALHO para comandos \'uteis: git ready. 25 | Dispon{\'\i}vel em: 26 | \url{http://pt-br.gitready.com/intermediario/2009/02/06/helpful-command-aliases.html}. 27 | Acesso em: 26 ago. 2017.} 28 | 29 | \bibitem[CGTI]{cgti} 30 | \abntrefinfo{CGTI}{CGTI}{} 31 | {CGTI: Modelo desenvolvimento. 32 | Dispon{\'\i}vel em: 33 | \url{http://git.mj.gov.br/CGTI/modelo-desenvolvimento/wikis/Manual-do-Usuario\#manual-do-usu-rio}. 34 | Acesso em: 24 ago. 2017.} 35 | 36 | \bibitem[cheatsheet do git-flow]{danielkummer} 37 | \abntrefinfo{cheatsheet\ldots}{CHEATSHEET\ldots}{} 38 | {CHEATSHEET do git-flow: danielkummer. 39 | Dispon{\'\i}vel em: 40 | \url{https://danielkummer.github.io/git-flow-cheatsheet/index.pt\_BR.html}. 41 | Acesso em: 27 ago. 2017.} 42 | 43 | \bibitem[Como excluir um ramo(branch) do Git local e remoto?]{stackoverflow2} 44 | \abntrefinfo{Como\ldots}{COMO\ldots}{} 45 | {COMO excluir um ramo(branch) do Git local e remoto?: stackoverflow. 46 | Dispon{\'\i}vel em: 47 | \url{https://pt.stackoverflow.com/questions/61428/como-excluir-um-ramobranch-do-git-local-e-remoto}. 48 | Acesso em: 26 ago. 2017.} 49 | 50 | \bibitem[Ger\^encia de Configuração de Software]{devmedia1} 51 | \abntrefinfo{Ger\^encia\ldots}{GER\^ENCIA\ldots}{} 52 | {GER\^ENCIA de Configuração de Software: Devmedia. 53 | Dispon{\'\i}vel em: 54 | \url{http://www.devmedia.com.br/gerencia-de-configuracao-de-software/9145}. 55 | Acesso em: 29 ago. 2017.} 56 | 57 | \bibitem[Git]{book} 58 | \abntrefinfo{Git}{GIT}{} 59 | {GIT: Book. 60 | Dispon{\'\i}vel em: \url{https://git-scm.com/book/pt-br/v2}. Acesso em: 26 ago. 61 | 2017.} 62 | 63 | \bibitem[git - guia prático]{rogerdudler} 64 | \abntrefinfo{git\ldots}{GIT\ldots}{} 65 | {GIT - guia prático: rogerdudler. 66 | Dispon{\'\i}vel em: 67 | \url{http://rogerdudler.github.io/git-guide/index.pt\_BR.html}. Acesso em: 28 68 | ago. 2017.} 69 | 70 | \bibitem[Git Cheatsheet]{ndpsoftware} 71 | \abntrefinfo{Git\ldots}{GIT\ldots}{} 72 | {GIT Cheatsheet: ndpsoftware. 73 | Dispon{\'\i}vel em: 74 | \url{http://ndpsoftware.com/git-cheatsheet.html\#loc=stash;}. Acesso em: 26 75 | ago. 2017.} 76 | 77 | \bibitem[GitLab]{gitlab} 78 | \abntrefinfo{GitLab}{GITLAB}{a} 79 | {GITLAB: Documentação. 80 | Dispon{\'\i}vel em: \url{https://docs.gitlab.com/ee/README.html}. Acesso em: 25 81 | ago. 2017.} 82 | 83 | \bibitem[GitLab]{wikiversity} 84 | \abntrefinfo{GitLab}{GITLAB}{b} 85 | {GITLAB: wikiversity. 86 | Dispon{\'\i}vel em: \url{https://pt.wikiversity.org/wiki/GitLab}. Acesso em: 28 87 | ago. 2017.} 88 | 89 | \bibitem[juanplopes]{devmedia2} 90 | \abntrefinfo{juanplopes}{JUANPLOPES}{} 91 | {JUANPLOPES. \emph{Integração Contínua - Artigo .net Magazine 85}. 92 | Dispon{\'\i}vel em: 93 | \url{http://www.devmedia.com.br/integracao-continua-artigo-net-magazine-85/21086}. 94 | Acesso em: 29 ago. 2017.} 95 | 96 | \bibitem[Merging vs. Rebasing]{atlassian} 97 | \abntrefinfo{Merging\ldots}{MERGING\ldots}{} 98 | {MERGING vs. Rebasing: Atlassian. 99 | Dispon{\'\i}vel em: 100 | \url{https://www.atlassian.com/git/tutorials/merging-vs-rebasing}. Acesso em: 101 | 26 ago. 2017.} 102 | 103 | \bibitem[Mota]{gitflow} 104 | \abntrefinfo{Mota}{MOTA}{} 105 | {MOTA, F.~J. \emph{Git Flow – Uma forma legal de organizar repositórios 106 | git}. 107 | Dispon{\'\i}vel em: 108 | \url{https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git/}. 109 | Acesso em: 29 ago. 2017.} 110 | 111 | \bibitem[Semantic Versioning 2.0.0]{semver} 112 | \abntrefinfo{Semantic\ldots}{SEMANTIC\ldots}{} 113 | {SEMANTIC Versioning 2.0.0: semver. 114 | Dispon{\'\i}vel em: \url{http://semver.org/}. Acesso em: 29 ago. 2017.} 115 | 116 | \bibitem[TOP 5 REPOSITÓRIOS DE CÓDIGO FONTE GRÁTIS PARA O SEU 117 | SOFTWARE]{tribo} 118 | \abntrefinfo{TOP\ldots}{TOP\ldots}{} 119 | {TOP 5 REPOSITÓRIOS DE CÓDIGO FONTE GRÁTIS PARA O SEU SOFTWARE: Tribo do 120 | c.i. 121 | Dispon{\'\i}vel em: 122 | \url{http://tribodoci.net/artigos/top-5-repositoros-de-codigo-fonte-gratis-para-o-seu-software/}. 123 | Acesso em: 27 ago. 2017.} 124 | 125 | \bibitem[What's the difference between 'git merge' and 'git 126 | rebase'?]{stackoverflow} 127 | \abntrefinfo{What's\ldots}{WHAT'S\ldots}{} 128 | {WHAT'S the difference between 'git merge' and 'git rebase'?: stackoverflow. 129 | Dispon{\'\i}vel em: 130 | \url{https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase/16666418\#16666418}. 131 | Acesso em: 25 ago. 2017.} 132 | 133 | \end{thebibliography} 134 | -------------------------------------------------------------------------------- /imagens/merge.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /ApostilaGit.tex: -------------------------------------------------------------------------------- 1 | \documentclass[12pt,openright,oneside,a4paper,english,brazil]{abntex2} 2 | 3 | \usepackage{lmodern} % Usa a fonte Latin Modern 4 | \usepackage[T1]{fontenc} % Selecao de codigos de fonte. 5 | \usepackage[utf8]{inputenc} % Codificacao do documento (conversão automática dos acentos) 6 | \usepackage{lastpage} % Usado pela Ficha catalográfica 7 | \usepackage{indentfirst} % Indenta o primeiro parágrafo de cada seção. 8 | \usepackage{color} % Controle das cores 9 | \usepackage{graphicx} % Inclusão de gráficos 10 | \usepackage{microtype} % para melhorias de justificação 11 | \usepackage{amsmath,amsfonts,amssymb} 12 | \usepackage{longtable} 13 | \usepackage{float} 14 | 15 | \chapterstyle{lyhne} 16 | 17 | \addto\captionsbrazil{ 18 | \renewcommand{\tablename}{Tabela} 19 | \renewcommand{\listtablename}{Lista de Tabelas} 20 | } 21 | 22 | \usepackage{lipsum} 23 | \usepackage{multirow} 24 | \usepackage{longtable} 25 | 26 | \usepackage[brazilian,hyperpageref]{backref} 27 | \usepackage[alf]{abntex2cite} 28 | 29 | \titulo{Git, uma abordagem \\ pragmática} 30 | \autor{Angelo Medeiros Nóbrega} 31 | \local{João Pessoa - PB} 32 | \data{2017 - V1.0.0} 33 | \tipotrabalho{Trabalho de Conclusão de Curso} 34 | 35 | \preambulo{Introdução ao controle de versão e boas práticas com o Git e o Git-flow, usando como repositório remoto o Gitlab.} 36 | 37 | 38 | \makeatletter 39 | \hypersetup{ 40 | pdftitle={\@title}, 41 | pdfauthor={\@author}, 42 | pdfsubject={\imprimirpreambulo}, 43 | pdfcreator={LaTeX with abnTeX2}, 44 | pdfkeywords={abnt}{latex}{abntex}{abntex2}{Trabalho de Conclusão do curso}, 45 | colorlinks=true, 46 | linkcolor=blue, 47 | citecolor=blue, 48 | filecolor=magenta, 49 | urlcolor=blue, 50 | bookmarksdepth=4 51 | } 52 | \makeatother 53 | 54 | \setlength{\parindent}{1.3cm} 55 | \setlength{\parskip}{0.2cm} 56 | \makeindex 57 | 58 | 59 | \begin{document} 60 | \selectlanguage{brazil} 61 | \frenchspacing 62 | 63 | \imprimircapa 64 | \imprimirfolhaderosto* 65 | 66 | 67 | \pdfbookmark[0]{\listfigurename}{lof} 68 | \listoffigures* 69 | \cleardoublepage 70 | 71 | \pdfbookmark[0]{\contentsname}{toc} 72 | \tableofcontents* 73 | \cleardoublepage 74 | 75 | % ---------------------------------------------------------- 76 | % ELEMENTOS TEXTUAIS 77 | % ---------------------------------------------------------- 78 | \textual 79 | 80 | \chapter[Antes de tudo, o que é controle de versão?]{Antes de tudo, o que é controle de versão?} 81 | Antes de começar a utilizar o \textit{git} para versionar seus trabalhos (códigos, imagens, layouts...) você deve entender o que é controle de versão. Após entender esse conceito você estará apto a usar todo o poder que o \textit{git} proporciona. 82 | 83 | O controle de versão(CV) é um sistema usado para ter controle sobre todas(isso se for usada corretamente) as mudanças feitas em um determinado arquivo. O CV permite você reverter sua aplicação que se encontra em um estado que está apresentando um \textit{bug}, para um estado anterior onde o \textit{bug} não havia se manifestado. Permite você também descobrir quem introduziu um problema, quando foi introduzido e onde foi introduzido. Se estiver usando um repositório remoto, você não correrá o risco de perder seu arquivos e melhor ainda, você também não perderá o controle sobre as mudanças feitas localmente. 84 | 85 | O controle de versão ajudará na organização, facilitará na hora de trabalhar em equipe, sem aquela história de dois desenvolvedores alterarem o mesmo arquivo ao mesmo tempo por estarem desenvolvendo um mesmo projeto. Segurança, vocês desenvolverão todos os projetos sem medo de perder algum código ou acabar errando alguma atualização sem ter como voltar. Você verá que existem muitas outras razões para usar um sistema para controle de versão. 86 | 87 | Muitas vezes o controle de versão é confundido com backup, lembre-se que no controle de versão você terá acesso ao arquivo atual e todas alterações ligadas ao arquivo e, no backup você terá acesso apenas a última versão do arquivo. 88 | 89 | Lembre-se também que todas essas \textit{features} que o controle de versão oferece só existirão se forem usadas corretamente. 90 | 91 | \section{O Git} 92 | 93 | O Git é a ferramenta que você utilizará para fazer todo o controle de versão. O Git surgiu quando Linus Torvalds, o criador do Linux, começou a enfrentar problemas quando desenvolvia o kernel do linux (projeto open source, ou seja, o Linus trabalhava com apoio de uma comunidade para seu desenvolvimento) com as ferramentas de versionamento da época havendo a necessidade da criação de uma nova ferramenta. A proposta para o Git era aprensentar algumas \textit{features} que o sistema antigo não oferecia: 94 | 95 | \begin{enumerate} 96 | \item Velocidade; 97 | \item Projeto simples; 98 | \item Forte suporte para desenvolvimento não-linear (milhares de ramos paralelos); 99 | \item Completamente distribuído; 100 | \item Capaz de lidar com projetos grandes como o núcleo o Linux com eficiência (velocidade e tamanho dos dados). 101 | \end{enumerate} 102 | 103 | Desde 2005 quando o Git foi criado ele passou por um longo período de evolução e ainda continua. Hoje ele está em uma versão estável oferecendo todas as \textit{features} citadas acima. 104 | 105 | \section{O GitLab \label{gitlab}} 106 | 107 | O GitLab nada mais é que um gerenciador de repositório \textit{git} remoto. O \textit{Gitlab} apresenta algumas vantagens em relação ao \textit{Github}: 108 | 109 | \begin{enumerate} 110 | \item Numero de Repositórios ilimitados; 111 | \item Espaço ilimitado (futuramente será cobrado por projetos maiores que 5Gb), atualmente o \textit{GitHub} limita em 1GB por projeto; 112 | \item Integração continua integrada (\textit{GitLab} CI); 113 | \item Importação projetos do \textit{GitHub}, \textit{BitBucket} e \textit{Gitorious}; 114 | \item Armazenamento de repositórios em servidores privados. 115 | \end{enumerate} 116 | 117 | A integração continua integrada funciona apenas para sistemas operacionais baseados no Linux. 118 | 119 | \section{O Git-flow \label{git-flow}} 120 | O \textit{git-flow} é uma extensão do \textit{git} para auxiliar o controle de versão usando comandos pré-definidos como boas práticas nesse quesito. Na minha opinião o \textit{git-flow} é muito mais do que uma simples extensão, é uma filosofia, é uma nova maneira de pensar sobre o controle de versão. 121 | 122 | Você pode aplicar a metodologia do \textit{git-flow} sem a necessidade de ter ele instalado, usando apenas comandos nativos do \textit{git}. 123 | 124 | \chapter{A estratégia de ramificação \label{ramificacao}} 125 | A estratégia de ramificação assemelha-se muito a estruta de uma árvore, por isso alguns comandos do \textit{git} usam termos como \textit{branch}(que significa ramo ou galho), ferramentas como o \textit{SourceTree} que serve para visualizar toda a ramificação do projeto em forma de grafos (a título de informação, \textit{tree} significa árvore). 126 | 127 | A estratégia que está representada na figura \ref{estrategia}, é uma estratégia que grandes e pequenas empresas usam a bastante tempo. Explicarei como ela é construída e como iremos trabalhar em cima dessa estratégia usando o \textit{git}, e como usar a poderosa extensão do \textit{git}, o \textit{\textit{git-flow}}, para facilitar ainda mais nosso trabalho. 128 | 129 | 130 | \begin{figure}[h] 131 | \caption{\label{estrategia}Estratégia de ramificação} 132 | \begin{center} 133 | \includegraphics[width=0.85\linewidth]{imagens/estrategia} 134 | \end{center} 135 | \legend{Fonte: (http://nvie.com/posts/a-successful-git-branching-model/)} 136 | \end{figure} 137 | 138 | 139 | \section{Os branches} 140 | 141 | Na estratégia que iremos adotar vamos trabalhar com seis tipos de ramos, são eles, dois ramos principais e quatro tipos de ramos de apoio. 142 | 143 | Os ramos principais são os ramos \textit{master} e o \textit{develop}. Os ramos de apoio serão os branches \textit{feature}, \textit{release}, \textit{hotfix} e \textit{buxfix}. A seguir irei descrever cada um desses ramos. 144 | 145 | \subsection{O \textit{branch} \textit{master}} 146 | 147 | O branch \textit{master} é o ramo que irá abrigar os códigos em suas versões mais estáveis, ele será o branch de produção. É o ramo que dará origem a aplicação final. Em algum momento do desenvolvimento todos os códigos produzidos em outros ramos farão um \textit{merge}(ato de mesclar os ramos, colocar os arquivos de um \textit{branch} em outro) com o \textit{branch master}, de forma direta ou indireta. 148 | 149 | \subsection{O \textit{branch develop}} 150 | 151 | Este ramo será responsável por conter os códigos em nível de desenvolvimento para o próximo \textit{deploy}(significa implementar, mas pode mudar de significado de acordo com o contexto). Lembre-se que os códigos não serão criados nesse \textit{branch}, ele é responsável apenas em abrigar os códigos que estão em desenvolvimento. Após os códigos serem devidamente testados o \textit{branch develop} fará um merge com o \textit{branch master}, isso se nem um \textit{bug} for encontrado no processo de testes, esse processo está representado na figura \ref{develop}. Se o código aprensentar \textit{bug}, será criado outro branch a partir do \textit{branch develop} para a correção dos \textit{bugs} e posteriormente mesclado com o \textit{branch master}. 152 | 153 | \begin{figure}[h] 154 | \caption{\label{develop}O \textit{branch} \textit{develop}} 155 | \begin{center} 156 | \includegraphics[width=0.6\linewidth]{imagens/develop} 157 | \end{center} 158 | \legend{Fonte: (http://nvie.com/posts/a-successful-git-branching-model/)} 159 | \end{figure} 160 | 161 | Os branches \textit{master} e \textit{develop} possuem ``vida infinita'', ou seja, eles sempre estarão presentes durante o desenvolvimento, e sempre serão criados quando o repositório for inicializado(isso se você estiver usando o git-flow, por padrão o git cria apenas o master). Os branches a seguir terão vida curta, eles serão criados durante a evolução do projeto e, após suas utlizações eles serão finalizados e excluídos, esse processo firará mais claro na prática. 162 | 163 | \subsection{O \textit{branch} \textit{feature}} 164 | 165 | O branch feature representado na figura \ref{feature} será utlizado sempre que uma nova funcionalidade precisar ser criada. Ele sempre será criado a partir do\textit{ branch develop} e finalizado no \textit{branch develop} independente em qual ramo você esteja(isso se você estiver utlizando o \textit{git-flow}). 166 | 167 | Ao contrário do ramo \textit{master} e \textit{develop}, o ramo \textit{feature} pode ser criado múltiplas vezes, uma para cada nova funcionalidade. Esse branch possui como prefixo \textit{feature/*}, onde o asterisco(*) será substituido pelo nome do ``sub-ramo'' digamos assim, por exemplo, \textit{feature/cadastrodeclientes}, \textit{feature/teladelogin}. 168 | 169 | \begin{figure}[h] 170 | \caption{\label{feature}O \textit{branch} \textit{feature}} 171 | \begin{center} 172 | \includegraphics[width=0.26\linewidth]{imagens/feature} 173 | \end{center} 174 | \legend{Fonte: (http://nvie.com/posts/a-successful-git-branching-model/)} 175 | \end{figure} 176 | 177 | 178 | São duas as principais maneiras de mesclar branches, figura \ref{feature-merges}. A primeira é fazendo a mesclagem criando um novo \textit{commit} com as alterações dentro do ramo \textit{develop} sem adicionar os \textit{commits} criados durante o desenvolvimento do ramo feature e, a outra é adicionando os \textit{commits} criados no ramo \textit{feature} dentro do ramo \textit{develop} e mais um novo \textit{commit} indicando a mesclagem, o git-flow usa como padrão esse último. Novamente, esse proceso ficará mais claro durante a prática. 179 | 180 | 181 | \begin{figure}[h] 182 | \caption{\label{feature-merges}Tipos de merges} 183 | \begin{center} 184 | \includegraphics[width=0.8\linewidth]{imagens/feature-merges} 185 | \end{center} 186 | \legend{Fonte: (http://nvie.com/posts/a-successful-git-branching-model/)} 187 | \end{figure} 188 | 189 | \subsection{O \textit{branch release}} 190 | 191 | Esse branch é o ramo intermediário entre o \textit{develop} e o \textit{master}. O objetivo desse branch é a criação de tags(são os números que indicam a versão da aplicação, 1.0.0 por exemplo). Ele inicia no \textit{branch develop} e termina no \textit{branch master} e no \textit{develop}. Você deve está se perguntando porquê um \textit{branch} que inicia-se no \textit{develop} tem que terminar no \textit{develop}. Isso acontece porquê o \textit{branch} \textit{develop} tem que ter a mesma \textit{tag} do \textit{branch master}. 192 | 193 | O prefixo usado pelo \textit{branch release} é \textit{release/*} onde o asterisco(*) deve ser substituido pela tag da \textit{realese}, por exemplo, \textit{release/0.1.0}. Mais na frente iremos aprender um conjunto de regras para a criação dessas tags, conhecido como versionamento semântico. 194 | 195 | Sempre quando falo que um branch ``termina'' ou ``finaliza'', me refiro a mesclagem de um branch em outro usado por padrão pelo git-flow. 196 | 197 | \subsection{Os \textit{branches hotfixes} e \textit{bugfixes}} 198 | 199 | O \textit{branch hotfix} e \textit{bugfix} tem o objetivo de correção de erros. A diferença entre eles é onde cada um é inicializado. 200 | 201 | Se o \textit{bug} for encotrado no ramo de produção(\textit{branch master}), um \textit{branch hotfix}, ver figura \ref{hotfix}, deve ser criado para tratar o erro a partir do ramo \textit{master}. Após a correção do erro uma nova \textit{tag} será criada automaticamente e, o \textit{branch hotfix} será mesclado com o ramo \textit{master} e também ao ramo \textit{develop} para que esse não apresente o erro em futuras versões. 202 | 203 | Análogo ao \textit{branch release} o prefixo do \textit{branch hotfix} é \textit{hotfix/*}, onde o asterisco(*) deve ser substituido pela nova tag, por exemplo, \textit{hotfix/0.1.1}. 204 | 205 | \begin{figure}[h] 206 | \caption{\label{hotfix}O \textit{branch hotfix}} 207 | \begin{center} 208 | \includegraphics[width=0.6\linewidth]{imagens/hotfix} 209 | \end{center} 210 | \legend{Fonte: (http://nvie.com/posts/a-successful-git-branching-model/)} 211 | \end{figure} 212 | 213 | O \textit{branch bugfix} deve ser criado quando um \textit{bug} é encontrado durante o desenvolvimento. Ele é iniciado e finalizado no \textit{branch develop}. Seu prefixo é semelhante ao do \textit{branch feature}, por exemplo, \textit{bugfix/erro-cadastramento}. 214 | 215 | \chapter{Primeiros passos com o Git} 216 | 217 | Nessa etapa vamos supor que todos estejam com o Git e o Git-flow instalados, caso haja a necessidade de um guia para as instalações, esse será adicionado como apêncide no final livro em futuras versões. 218 | 219 | \section{Configuração inicial \label{configinicial}} 220 | 221 | O primeiro passo é abrir seu console preferido, se estiverem no Linux ou macOS, abram o terminal por exemplo. Se estiverem utilizando o Windows vocês podem usar o Git Bash que é instaldo com o Git. Ainda para usuários Windows, uma dica que dou é usar o Cmder, é um console free e muito mais agradável de se trabalhar e não prescisa ser instaldo, apenas baixado, ver figura \ref{cmder}. Sugiro também não utilizar o CMD, nem o PowerShell. 222 | 223 | \begin{figure}[h] 224 | \caption{\label{cmder}Uma alternativa para o CMD, o \textit{Cmder}} 225 | \begin{center} 226 | \includegraphics[width=1\linewidth]{imagens/cmder} 227 | \end{center} 228 | \legend{Fonte: (http://cmder.net/)} 229 | \end{figure} 230 | 231 | Com o seu console aberto digite \textit{git} e aperte enter, isso irá verificar se o git foi instaldo corretamente. Se ele tiver sido instalado corretamente irá aparecer algo semelhante a figura \ref{terminal}. 232 | 233 | \begin{figure}[h] 234 | \caption{\label{terminal}Verificando a instalação do git} 235 | \begin{center} 236 | \includegraphics[width=1\linewidth]{imagens/terminal} 237 | \end{center} 238 | \legend{Fonte: (Do autor)} 239 | \end{figure} 240 | 241 | Com o git devidamente instalado vamos começar a configuração. Para isso insira os seguintes comandos, o primeiro será para o git identificar seu nome, e o segundo seu email(figura \ref{configuracao}): 242 | 243 | \begin{verbatim} 244 | git config --global user.name "Angelo Medeiros" 245 | git config --global user.email "angelo@email.com" 246 | \end{verbatim} 247 | 248 | Caso queira visualizar suas configuração globais digite o comando: 249 | 250 | \begin{verbatim} 251 | git config --global --list 252 | \end{verbatim} 253 | 254 | O próximo comando serve para facilitar o entendimento visual: 255 | 256 | \begin{verbatim} 257 | git config --global color.ui true 258 | \end{verbatim} 259 | 260 | \begin{figure}[h] 261 | \caption{\label{configuracao}Configuração inicial do git} 262 | \begin{center} 263 | \includegraphics[width=1\linewidth]{imagens/configuracao} 264 | \end{center} 265 | \legend{Fonte: (Do autor)} 266 | \end{figure} 267 | 268 | \chapter{Os 3 estágios} 269 | 270 | Nesse capítulo ensinarei a criar seu primeiro repositório git e, quais são os três principais estágios do processo para o versionamento usado pelo git. 271 | 272 | \section{Criando um repositório} 273 | 274 | O primeiro passo é acessar a pasta pelo terminal que você quer iniciar o repositório git. Para exemplificar eu criei uma pasta chamada gitLegal e usei os seguintes comandos(ver figura \ref{repositorio}): 275 | 276 | \begin{verbatim} 277 | Criando a pasta gitLegal: mkdir gitLegal 278 | Acessando a pasta criada: cd gitLegal 279 | Verificando o conteudo da pasta: ls 280 | Iniciando o repositório git: git init 281 | Verificando novamente a pasta: ls 282 | Verificando a existência de arquivos ocultos: ls -a 283 | \end{verbatim} 284 | 285 | \begin{figure}[h] 286 | \caption{\label{repositorio}Criando repositório git} 287 | \begin{center} 288 | \includegraphics[width=1\linewidth]{imagens/repositorio} 289 | \end{center} 290 | \legend{Fonte: (Do autor)} 291 | \end{figure} 292 | 293 | O processo de verificação da pasta foi feito apenas para mostrar que quando o repositório é inicializado o git cria uma pasta oculta. Nessa pasta oculta estão todos os arquivos necessário para o git gerenciar seu repositório. Na prática você usará apenas o comando \textit{git init}. 294 | 295 | \section{O primeiro estágio} 296 | 297 | O primeiro estágio é chamado de "untracked files". Assim que você faz alguma aleteração no repositório, criando uma pasta ou arquivo, ou alterando um arquivo existente, isso faz com que o elemento que você alterou entre no primeiro estágio. 298 | 299 | Para verificar em que estágio seus elementos estão basta digitar o comando \textit{git status}. 300 | 301 | Se for dado um \textit{git status} na pasta gitLegal não irá aparecer nada, pois, o repositório não teve nenhuma alteração. 302 | 303 | Para demonstrar o primeiro estágio irei criar um arquivo em branco chamado \textit{helloWorld} e em seguida executarei o comando para verificar o estágio(ver figura \ref{estagio1}). 304 | 305 | \begin{figure}[h] 306 | \caption{\label{estagio1}O primeiro estágio} 307 | \begin{center} 308 | \includegraphics[width=1\linewidth]{imagens/estagio1} 309 | \end{center} 310 | \legend{Fonte: (Do autor)} 311 | \end{figure} 312 | 313 | O comando \textit{touch} foi usado para a criação do arquivo \textit{helloWorld}. 314 | 315 | \section{O segundo estágio} 316 | 317 | O segundo estágio é chamado de ``Changes to be committed''. Nessa etapa você irá adicionar os elementos do primeiro estágio para serem ``commitados'' no terceiro estágio. Irei criar outro arquivo em branco chamado helloWorld2, apenas para ficar mais claro a importância dessa etapa(ver figura \ref{estagio2}). 318 | 319 | \begin{figure}[h] 320 | \caption{\label{estagio2}O segundo estágio} 321 | \begin{center} 322 | \includegraphics[width=1\linewidth]{imagens/estagio2} 323 | \end{center} 324 | \legend{Fonte: (Do autor)} 325 | \end{figure} 326 | 327 | Agora vamos entender o que foi feito. Com a adição do arquivo helloWorld2, o primeiro estágio agora tem dois elementos. Vamos supor que você queira adicionar apenas o primeiro helloWorld world para o último estágio. Para fazer isso, foi necessário apenas usar o comando \textit{git add helloWorld}. 328 | 329 | Como mostra a figura \ref{estagio2}, no segundo estágio encontra-se apenas o primeiro \textit{helloWorld}. Peço desculpas pela falta de criatividade ao nomear os elementos. 330 | 331 | Na maioria das vezes é necessário adicionar mais de uma arquivo ao terceiro estágio e não é viável adicionar um por um. Uma alternativa mais eficiente para essa situação é usar o comando ``\textbf{git add .}'', ele irá adicionar todos os arquivos ao terceiro estágio. Preste atenção no ponto seguido do add, ele também faz parte do comando. 332 | 333 | \section{O terceiro estágio} 334 | 335 | Nesse estágio é onde acontece o famoso \textit{commit}. Para quem não sabe o que é um \textit{commit}, ele nada mais é que um \textit{snapshot} do estado de sua aplicação. Na figura \ref{estagio3} mostra o arquivo \textit{helloWorld} sendo ``commitado''. Observe que após o \textit{commit} o arquivo \textit{helloWorld} não aparece mais quando é usado o comando \textit{git status}. O arquivo só voltará a aparecer quando sofrer alguma alteração novamente. 336 | 337 | \begin{figure}[h] 338 | \caption{\label{estagio3}O terceiro estágio} 339 | \begin{center} 340 | \includegraphics[width=1\linewidth]{imagens/estagio3} 341 | \end{center} 342 | \legend{Fonte: (Do autor)} 343 | \end{figure} 344 | 345 | Existem duas principais maneiras de realizar um \textit{commit}, na figura \ref{estagio3} mostra uma delas. Na figura \ref{commit} mostrarei a outra maneira realizando um \textit{commit} do \textit{helloWorld2}. 346 | 347 | \begin{figure}[h] 348 | \caption{\label{commit}Outra maneira de realizar um commit} 349 | \begin{center} 350 | \includegraphics[width=1\linewidth]{imagens/commit2} 351 | \end{center} 352 | \legend{Fonte: (Do autor)} 353 | \end{figure} 354 | 355 | A primeira maneira deve ser usada quando você fez poucas alterações, e você consegue descrever todas esses mudanças em apenas uma linha usado o commando \textit{git commit -m "comentario"}. A segunda maneira deve ser usada quando for preciso descrever diversas alterações e apenas uma linha não basta. Uma dica é, evite usar acentuação dentro dos comentários, quando a acentuação é usada, algumas vezes quando você for visualizar os commits a acentuação poderá não ser reconhecida pelo console. 356 | 357 | \chapter{Comandos mais usados no git} 358 | 359 | Nesse capítulo irei apresentar os principais comandos usados pelo git e sempre estarei dando algumas dicas. 360 | 361 | \section{Visualizando o log} 362 | 363 | Até agora vocês aprenderam a visualizar em que estágio está sua aplicação e a criar os \textit{commits}. Agora ensinarei como visualizar os \textit{commits} criados, o \textit{log}. O comando básico para visualizar um \textit{log} é o \textit{git log}(ver figura \ref{gitlog}) mas ele também pode vim com outras opções, ensinarei os mais usados. 364 | 365 | \begin{figure}[h] 366 | \caption{\label{gitlog}Visualizando o log básico} 367 | \begin{center} 368 | \includegraphics[width=1\linewidth]{imagens/gitlog} 369 | \end{center} 370 | \legend{Fonte: (Do autor)} 371 | \end{figure} 372 | 373 | Irei adicionar dentro do arquivo helloWorld o texto a seguir e, farei um novo commit. 374 | 375 | \begin{verbatim} 376 | # Comando para imprimir na tela usando o python 2.x 377 | 378 | print "Hello world!" 379 | \end{verbatim} 380 | 381 | A figura \ref{pretty} mostra a execução do commando \textit{git log --pretty=oneline}. Esse comando exibe o log de forma reduzida, mostrando apenas o \textit{hash} e os comentários em apenas uma linha. 382 | 383 | \begin{figure}[h] 384 | \caption{\label{pretty}Outra maneira de visualizar o log} 385 | \begin{center} 386 | \includegraphics[width=1\linewidth]{imagens/pretty} 387 | \end{center} 388 | \legend{Fonte: (Do autor)} 389 | \end{figure} 390 | 391 | Outra opção para o mesmo comando é: 392 | 393 | \begin{itemize} 394 | \item \verb|git log --pretty=oneline -2|, o parâmetro -2, faz com que o comando exiba apenas os dois últimos commits(você pode alterar o parâmetro por qualquer outro valor). 395 | \end{itemize} 396 | 397 | Abaixo seguem outros comandos para vocês experimentarem: 398 | 399 | \begin{itemize} 400 | \item \verb|git log -p|, exibe as alterãções em cada arquivo de todos os commits; 401 | \item \verb|git log -p -1|, exibe as alterãções do último commit(ver figura \ref{logp}); 402 | \item \verb|git log --stat|, exibe um resumo das alterações; 403 | \item \verb|git log --stat -2|, exibe um resumo das alterações dos últimos dois commits; 404 | \item \verb|git log --since=10.minutes|, exibe os commits dos últimos 10 minutos; 405 | \item \verb|git log --since=2.hours|, exibe os commits das últimas duas horas; 406 | \item \verb|git log --since=1.days|, exibe os commits no intervalo de tempo de um dia. 407 | \end{itemize} 408 | 409 | 410 | \begin{figure}[H] 411 | \caption{\label{logp}Mais uma maneira de visualizar o log} 412 | \begin{center} 413 | \includegraphics[width=1\linewidth]{imagens/logp} 414 | \end{center} 415 | \legend{Fonte: (Do autor)} 416 | \end{figure} 417 | 418 | Na figura \ref{logp} as linhas que começam com um símbolo de mais(+) indica algo que foi adicionado. Se começar com o símbolo de menos($-$) significa que algo foi retirado. Os números entre os símbolos de (@) indicam as posições das linhas onde houveram alterações. Quando vocês estiverem praticando isso ficará mais claro. 419 | 420 | \section{Criando branches \label{criandobranch}} 421 | 422 | Para criar um novo \textit{branch} usamos o comando \textit{git checkout -b nomeBranch}. Onde \textit{nomeBranch} deve ser substituído pelo nome do \textit{branch} que você quer criar. Vale resaltar que um \textit{branch} é sempre criado baseado no \textit{branch} atual, ou seja, se você estiver no\textit{ branch master}, o novo \textit{branch} será um ``clone'' do \textit{branch master}, ver figura \ref{novobranch}. 423 | 424 | \begin{figure}[H] 425 | \caption{\label{novobranch}Criando um branch} 426 | \begin{center} 427 | \includegraphics[width=1\linewidth]{imagens/novobranch} 428 | \end{center} 429 | \legend{Fonte: (Do autor)} 430 | \end{figure} 431 | 432 | Observe que quando você cria um \textit{branch} o \textit{git} já inicia dentro do novo \textit{branch}. Irei listar abaixo os principais comandos relacionados a manipulação dos branches. 433 | 434 | \begin{itemize} 435 | \item \verb|git checkout nomeDoBranch|, troca do \textit{branch} atual para o \textit{branch nomeDoBranch}; 436 | \item \verb|git branch|, exibe os branches criados localmente; 437 | \item \verb|git branch -a|, exibe os branches locais e os remotos(se você tiver trabalhano com branches remotos); 438 | \item \verb|git remote -v|, exibe os branches remotos; 439 | \item \verb|git branch -d nomeDoBranch|, deleta o \textit{branch nomeDoBranch}; 440 | \item \verb|git branch -D nomeDoBranch|, força a exlusão do \textit{branch nomeDoBranch}. 441 | \end{itemize} 442 | 443 | \section{Mesclando branches} 444 | 445 | Mesclar branches na maioria das vezes é uma tarefa fácil. Porém algumas vezes ocorrem conflitos, esse assunto será tratado em uma seção mais na frente. Por enquanto vamos se preocupar apenas em mesclar os \textit{branches}. São duas as principais maneiras de fazer a mesclagem usando o git, você pode usar o \textit{merge} ou o \textit{rebase}. 446 | 447 | \subsection{Mesclando usando o merge} 448 | 449 | O comando $$\verb|git merge funcionalidade1|$$ é usado para realizar o merge. Ele irá mesclar o \textit{branch funcionalidade1} com o \textit{branch atual}. 450 | 451 | A vantagem do merge é que ele preserva um histórico completo do seu projeto e, evita problemas quando está trabalhando em um ambiente cooperativo(ver figura \ref{merge}). 452 | 453 | \begin{figure}[H] 454 | \caption{\label{merge}Mesclando usando o merge} 455 | \begin{center} 456 | \includegraphics[width=0.5\linewidth]{imagens/merge} 457 | \end{center} 458 | \legend{Fonte: (https://stackoverflow.com/questions/16666089)} 459 | \end{figure} 460 | 461 | \subsection{Mesclando usando o rebase} 462 | 463 | O rebase preserva um histórico mais limpo e linear do seu projeto, porém ao trabalhar em grupo isso torna-se uma desvantagem, pois o rebase recria os commits. Na figura \ref{rebase} quando o elemento E foi mesclado com o elemento D dando origem ao elemento R, o elemento E foi reescrito com outro commit, isto é, com outro hash. Então para alguém de fora que tenha o elemento E vai ter um commit diferente do seu, apesar de ser o mesmo elemento, tornando algo confuso. 464 | 465 | \begin{figure}[H] 466 | \caption{\label{rebase}Mesclando usando o rebase} 467 | \begin{center} 468 | \includegraphics[width=0.5\linewidth]{imagens/rebase} 469 | \end{center} 470 | \legend{Fonte: (https://stackoverflow.com/questions/16666089)} 471 | \end{figure} 472 | 473 | O rebase é aconselhado apenas quando você está trabalhando localmente, a não ser que você saiba o que está fazendo. Caso contrário, use sempre o merge. A documentação do git descreve diversos parâmetros que podem e devem ser usados, tanto para o rebase e para o merge. 474 | 475 | \section{Voltando versões} 476 | 477 | Na minha opinião essa é a principal função do git, o processo de voltar versões. Existem diversas maneiras de fazer isso. Algumas são simples, mas não oferecem muita segurança para quem está iniciando nesse novo mundo do controle de versões. Outras envolvem mais etapas, porém você sentirá segurança realizando o processo, o fato de ter mais etapas não o torna mais difícil. 478 | 479 | A maioria dos comandos para voltar versões necessitam do \textit{hash} do \textit{commit}, você pode encontrar esse \textit{hash} visualizando o \textit{log}. Não é necessário o hash completo, apenas o começo. A seguir estão os principais comandos: 480 | 481 | \begin{itemize} 482 | \item \verb|git reset d3fbdd741 --hard|, desfaz todas as alterações anteriores do commit d3fbdd741(ver figura \ref{voltando}); 483 | \item \verb|git reset HEAD~2 --hard|, desfaz todas as alterações dos dois últimos commits; 484 | \item \verb|git ckeckout d3fbdd741|, cria um branch temporário a partir do commit d3fbdd741. 485 | \end{itemize} 486 | 487 | \begin{figure}[h] 488 | \caption{\label{voltando}Voltando versão} 489 | \begin{center} 490 | \includegraphics[width=1\linewidth]{imagens/voltando} 491 | \end{center} 492 | \legend{Fonte: (Do autor)} 493 | \end{figure} 494 | 495 | Entendendo a figura \ref{voltando}. Veja que antes do \textit{reset} existia o arquivo \textit{helloWorld2}. No final do processo além de apagar o arquivo \textit{helloWorld2}, as alterações feitas no arquivo \textit{helloWorld} também foram desfeitas apesar de não mostrar na figura. Essas mudanças aconteceram porquê o arquivo \textit{heloWorld2} foi criado no \textit{commit} eddcb203a como pode ser observado nos comentários do \textit{commit} mostrado no \textit{log} e, o conteudo do arquivo \textit{helloWorld} ocorreu no \textit{commit} 2bf2040e30. Por isso a importância de documentar corretamente os \textit{commits}. 496 | 497 | Você pode combinar diversas técnicas para voltar versões usando o git. Quando forem ganhando mais segurança no que estão fazendo, o processo de voltar versões irá se tornar algo natural. Por exemplo, você pode criar um novo \textit{branch} a partir do qual queira voltar uma versão, e depois mesclar esse novo \textit{branch} com o \textit{branch} principal. Depende apenas da sua engenhosidade, então façam diversos testes usando o git para adquirir experiência. 498 | 499 | \section{Algumas dicas} 500 | 501 | Nas seções seguintes serão descritas algumas dicas. 502 | 503 | \subsection{Ignorando arquivos com o Git} 504 | 505 | Geralmente existem arquivos que são criados automaticamente durante um projeto, por exemplo arquivos de log. Tais arquivos sempre ficam aparecendo no segundo estágio e isso não é algo interessante. 506 | 507 | Para impedir que alguns arquivos fiquem aparecendo ao visualizar o status, o git trabalha com o arquivo \textbf{.gitignore}. Esse arquivo é criado na raiz do projeto e, contém os nomes dos arquivos a serem ignorados, ver figura \ref{gitignore}. 508 | 509 | \begin{figure}[h] 510 | \caption{\label{gitignore}Ignorando arquivos} 511 | \begin{center} 512 | \includegraphics[width=1\linewidth]{imagens/gitignore} 513 | \end{center} 514 | \legend{Fonte: (Do autor)} 515 | \end{figure} 516 | 517 | No exemplo da figura \ref{gitignore} os arquivos \textit{idea.log} e \textit{test.aux} não aparecerão mais no status. Todos os arquivos que terminarem com a extensão \textbf{.lot} ou apresentarem a extensão \textbf{.tar}, por exemplo \textit{ubuntuMobile.tar.xz}, também serão ignorados. 518 | 519 | \textit{\textbf{Observação:}} Se um arquivo já tiver sido adicionado para o segundo estágio em algum momento do desenvolvimento ele não será ignorado mesmo que o nome do arquivo esteja presente no \textbf{.gitignore}. Se esse for o caso, o comando $$\verb|git rm --cached nomeDoArquivo|$$ irá retirar o arquivo do segundo estágio, ou seja, do monitoramento e a partir disso ele passará a ser ignorado normalmente, caso queira retirar uma pasta completa use o comando $$\verb|git rm -r --cached nomeDaPasta|$$ experimente ambos como prática. 520 | 521 | 522 | \subsection{Alterando o proxy \label{alterandoproxy}} 523 | 524 | Dependendo do local onde esteja trabalhando será necessário uma configuração prévia do proxy para o git trabalhar com repositórios remotos. 525 | 526 | Os principais comandos para alteração do proxy são: 527 | 528 | \begin{itemize} 529 | \item \verb|git config --global http.proxy "proxy:port"| 530 | \item \verb|git config --global http.proxy "10.10.32.1:3128"|, altera o proxy para 10.10.32.1 na porta 3128 531 | \item \verb|git config --global http.proxy ""|, altera o proxy de \textit{manual} para \textit{nenhum} 532 | \item \verb|git config --global --unset http.proxy|, outra maneira para desativar o proxy 533 | \end{itemize} 534 | 535 | 536 | \chapter{Trabalhando com repositório remoto} 537 | 538 | Na seção \ref{gitlab} falei brevemente sobre o \textit{gitLab}. Nesse capítulo iremos estudar como o \textit{git} se comporta trabalhando com repositórios remotos e faleremos sobre algumas características do \textit{gitLab}. 539 | 540 | Antes de começar a usar os comandos das próximas seções será necessário a criação de uma conta no \textit{gitLab}. 541 | 542 | \section{Criando seu primeiro repositório remoto} 543 | 544 | Com o \textit{gitLab} aberto siga as intruções da figura \ref{criandorep1} para iniciar o processo de criação do seu primeiro repositório remoto. Em \textbf{\textit{1}} você irá abrir as opções para a criação do novo repositório. Em \textbf{\textit{2}} você irá selecionar \textit{New project}, a continuação segue nas figuras subsequentes. 545 | 546 | \begin{figure}[h] 547 | \caption{\label{criandorep1}Criando repositório - 1ª etapa} 548 | \begin{center} 549 | \includegraphics[width=1\linewidth]{imagens/criandorep1} 550 | \end{center} 551 | \legend{Fonte: (Do autor)} 552 | \end{figure} 553 | 554 | Continuando na figura \ref{criandorep2}, em \textbf{\textit{1}} você irá adicionar o nome do repositório, não necessariamente sendo igual ao repositório local. Em \textbf{\textit{2}} exibe as opções de visibilidade do projeto, não tendo relação alguma com as permissões do projeto. Em \textbf{\textit{3}} aperte em \textit{Create project}. 555 | 556 | \begin{figure}[h] 557 | \caption{\label{criandorep2}Criando repositório - 2ª etapa} 558 | \begin{center} 559 | \includegraphics[width=1\linewidth]{imagens/criandorep2} 560 | \end{center} 561 | \legend{Fonte: (Do autor)} 562 | \end{figure} 563 | 564 | O \textit{git} pode se comunicar com os repositórios remotos atráves de dois tipos de protocolos, podendo ser o \textit{HTTPS} e o \textit{SSH}. Com o \textit{HTTPS} não é necessário uma configuração prévia (salvas algumas exceções, como o proxy, dependendo do caso) para iniciar seu uso, enquanto o \textit{SSH} só irá funcionar se você adicionar sua chava pública \textit{SSH} nas configurações do \textit{gitLab}. 565 | 566 | Em \textbf{\textit{1}} na figura \ref{criandorep3}, você pode escolher o tipo de protocolo que você irá usar para conectar seu repositório local com o remoto. Em \textbf{\textit{2}} você pode manipular seu repositório remotamente, criando novos arquivos, novos branches, informando problemas, entre outras opções. Lembre-se que as alterações feitas no repositório remoto não altera o conteúdo do repositório local, a não ser que você utlize comandos no \textit{git} para isso, um \textit{git pull} por exemplo (esse comando será descrito mais a frente). 567 | 568 | \begin{figure}[h] 569 | \caption{\label{criandorep3}Criando repositório - 3ª etapa} 570 | \begin{center} 571 | \includegraphics[width=1\linewidth]{imagens/criandorep3} 572 | \end{center} 573 | \legend{Fonte: (Do autor)} 574 | \end{figure} 575 | 576 | Se você observar o \textit{git} está sempre dando dicas. Com o \textit{gitLab} não é diferente. Um exemplo disso está representado na figura \ref{criandorep4}. O \textit{gitLab} exibe diversas opções para você conectar seu repositório remoto com o repositório local. 577 | 578 | Na primeira etapa da figura \ref{criandorep4} você irá realizar a configuração inicial do git, se você vem seguindo a apostila desde os primeiros capítulos, esse processo de configuração já foi realizado na seção \ref{configinicial}. As etapas 2, 3 e 4, serão casos situacionais. 579 | 580 | A etapa 2 deve ser usada quando não existe um repositório local. A primeira linha da etapa 2 irá criar um repositório local, a partir do repositório remoto, na pasta atual em que seu console se encontra. A segunda linha serve para acessar a pasta do repositório. A terceira linha (opcional) criará um arquivo em branco com o nome \textit{README.md}. A quarta linha como já devem saber, adiciona o arquivo \textit{README.md} para o terceiro estágio. A quinta linha realizará o commit. E a última linha irá adicionar o arquivo \textit{README.md} que foi criado localmente para o repositório remoto, ao \textit{branch master} remoto. 581 | 582 | A etapa 3 deve ser utilizada quando você quer iniciar um repositório local e, em seguida fazer a conexão do repositório criado localmente com o repositório remoto. A primeira linha serve para acessar a pasta do repositório. A segunda é utlizada para criar o repositório local. A terceira linha será responsável em estabelecer a conexão entre o repositório local e o remoto. As linhas seguintes vocês já sabem suas devidas aplicações. 583 | 584 | A etapa 4 deve ser usada quando já existe um repositório criado localmente. Novamente, a segunda linha irá estabelecer a conexão entre os repositórios. A terceira linha adionará todos os branches locais ao repositório remoto. A quarta linha (opcional) irá adiconar todas as tags criadas, caso existam. 585 | 586 | Lembre-se de verificar os tipos de protocolos que estão utilizando. Se tiver em dúvida em qual utilizar opte pelo protocolo \textit{HTTPS}. Lembre-se também de configurar o proxy do seu local de trabalho caso seja necessário. 587 | 588 | \begin{figure}[h] 589 | \caption{\label{criandorep4}Criando repositório - 4ª etapa} 590 | \begin{center} 591 | \includegraphics[width=1\linewidth]{imagens/criandorep4} 592 | \end{center} 593 | \legend{Fonte: (Do autor)} 594 | \end{figure} 595 | 596 | \section{Realizando seu primeiro \textit{push}} 597 | 598 | O push (empurrar) é o ato de fazer o upload do seu projeto local para um repositório remoto. O \textit{push} só funcionará corretamente se o seu repositório local estiver conectado com o repositório remoto. Essa conexão é realizada com um comando do tipo \verb|git remote add origin ENDEREÇO_DO_REPOSITÓRIO_REMOTO|, esse endereço encontra-se na primeira etapa da figura \ref{criandorep3}. O \textit{origin} não faz parte do comando, ele é o nome padrão dados aos repositórios remotos, mas nada impede de você utlizar outro nome, o aconselhado pela comunidade é manter como \textit{origin}. 599 | 600 | Os principais comandos para realizar um push serão descritos a seguir: 601 | 602 | \begin{itemize} 603 | \item \verb|git push -u origin master|, sobe o \textit{branch master} para o repositório remoto, usei como exemplo o master, mas você pode usar qualquer outro \textit{branch} que tenha criado; 604 | \item \verb|git push -u origin cadastroDeUsuarios|, sobe o branch cadastro de usuários; 605 | \item \verb|git push -u origin --tags|, sobe as tags criadas (haverá uma seção apenas para tags). 606 | \end{itemize} 607 | 608 | \section{Realizando seu primeiro clone} 609 | 610 | Realizar um clone é necessário quando você precisa duplicar um repositório remoto para sua máquina. Por exemplo, quando você deleta seu repositório local, ou quando você encontra um projeto opensource e quer utilizá-lo, ou ainda mesmo quando alguém rouba sua máquina e seu projeto está nele(piada interna), mas nesse último caso só irá funcionar se você estiver usando o git corretamente. 611 | 612 | Para fazer um clone é necessário apenas duas condições, o endereço do repositório e obviamente permissão para fazer tal processo. Se o projeto for público você pode fazer o clone do repositório sem pedir a permissão ao dono. Abaixo segue os dois principais comandos para realizar um clone: 613 | 614 | \begin{itemize} 615 | \item \verb|git clone ENDEREÇO_DO_REPOSITÓRIO_REMOTO| 616 | \item \verb|git clone https://gitlab.com/.../meu-primeiro-repositorio.git|, irá fazer um clone e copiar seus arquivos para a pasta com o nome do repositório, nesse caso \textit{meu-primeiro-repositorio.git}; 617 | \item \verb|git clone https://gitlab.com/.../meu-primeiro-repositorio.git Test1|, irá fazer o mesmo que o comando anterior, porém irá adicionar os arquivos para a pasta \textit{Test1}. 618 | \end{itemize} 619 | 620 | \section{Criando um branch a partir do repositório remoto} 621 | 622 | Vocês já sabem criar um \textit{branch} a partir de um \textit{branch} local. Nessa seção vamos supor que você tenha criado um branch remotamente, como mostra na segunda etapa da figura \ref{criandorep3}. Por padrão o git cria um \textit{branch} baseado no seu \textit{branch} atual com o comando \verb|git checkout -b nomeDoBranch|, o comando para criar um branch local a partir de um branch remoto é muito semelhante, ele está descrito abaixo: 623 | 624 | \begin{itemize} 625 | \item \verb|git checkout -b test1 origin/test2|, cria um branch localmente com o nome \textit{test1} a partir do \textit{branch} remoto \textit{test2}, o comando para visualizar o nome do branch remoto foi descrito na seção \ref{criandobranch}. 626 | \end{itemize} 627 | 628 | \section{Realizando seu primeiro \textit{pull}} 629 | 630 | O \textit{pull} faz o trabalho inverso do \textit{push}, enquanto o \textit{push} sobe seu arquivos do repositório local para o repositório remoto, o \textit{pull} desce os arquivos que estão no repositório remoto para o repositório local. 631 | 632 | Os principais comandos para realizar um pull serão descritos a seguir: 633 | 634 | \begin{itemize} 635 | \item \verb|git pull origin master|, desce os arquivos do \textit{branch master} localizado remotamente para o \textit{branch} local atual; 636 | \item \verb|git pull|, esse comando é usado quando para atualizar a lista de branches, por exemplo, vamos supor que você tenha criado um \textit{branch} remotamente, esse novo \textit{branch} criado não será exibido na sua máquina local até você atualizar a lista (o comando para visualizar os branches está descrito na seção \ref{criandobranch}). 637 | \end{itemize} 638 | 639 | \section{Trabalhando com \textit{tags} \label{tags}} 640 | 641 | As tags são os rótulos dados para as versões. Geralmente esses rótulos são numéricos, 1.2.1 por exemplo, vocês provavelmente já viram algumas tags de pré-lançamento (pre-release) usando nomes de letras gregas, versão 1.0.0-alpha ou versão 1.0.0-beta. Para manter um nível de organização, iremos adotar as regras do versionamento semântico para a criação das tags, tais regras são adotadas pela maioria das empresas, comunidades e desenvolvedores. 642 | 643 | \subsection{Versionamento Semântico \label{semver}} 644 | 645 | O versionamento semântico consiste em um conjunto de 11 regras bem especificadas. Eu irei falar a essência do versionamênto semântico, e fica como pesquisa para vocês saberem mais na \hyperref{http://semver.org/lang/pt-BR/}{}{}{documentação} completa. 646 | 647 | Abaixo está descrito um resumo do que consiste o versionamento semântico. Dado um número da versão \texttt{MAJOR.MINOR.PATCH}: 648 | 649 | \begin{enumerate} 650 | \item versão Maior(\texttt{MAJOR}): quando fizer mudanças incompatíveis na API; 651 | \item versão Menor(\texttt{MINOR}): quando adicionar funcionalidades mantendo compatibilidade; 652 | \item versão de Correção(\texttt{PATCH}): quando corrigir falhas mantendo compatibilidade. 653 | \end{enumerate} 654 | 655 | A versão \texttt{MINOR} tem que garantir compatibilidade apenas com a versão \texttt{MAJOR}. A versão de correção (\texttt{PATCH}) tem que garantir compatibilidade com todas as versões acima dela. Se por exemplo, ocorrer quebra de compatibilidade quando a correção de um \textit{bug} for feita, deve ser criada uma nova versão \texttt{MINOR}. Esses e outros detalhes estão especificados na documentação. 656 | 657 | 658 | Rótulos adicionais para pré-lançamento(pre-release) e metadados de construção(build) estão disponíveis como extensão ao formato \texttt{MAJOR.MINOR.PATCH}. 659 | 660 | \subsection{Criando \textit{tags} com o \textit{git}} 661 | 662 | Para criar uma \textit{tag} usando o \textit{git} basta usar o comando $$\verb|git tag X.Y.Z|$$ onde as letras \texttt{X}, \texttt{Y} e \texttt{Z} devem ser substituídas pelo número da versão seguindo as regras do versionamento semântico visto na seção \ref{semver}. 663 | 664 | A seguir estão descritos outros comandos relacionados com as tags: 665 | 666 | \begin{itemize} 667 | \item \verb|git tag -l|, exibe as tags criadas; 668 | \item \verb|git tag|, outra maneira de exibir as tags criadas; 669 | \item \verb|git push --tags|, sobe as tags criadas para o repositório remoto. 670 | \end{itemize} 671 | 672 | \section{Resolvendo conflitos} 673 | 674 | Nem tudo são flores quando falamos do controle de versões. As vezes acontece de ter mais de um desenvolvedor editando o mesmo código, e quando é necessário fazer um merge, o sistema de controle de versão não tem como advinhar qual código deve ser mantido. Existem diversos cenários para falar sobre conflitos. 675 | 676 | Esse assunto é tão complexo que cada empresa tem uma maneira diferente de lidar. Para exemplificar isso, existem dois tipos de visões, uma é a visão pessimista, onde o código só pode ser editado por um desenvolvedor, e os outros podem apenas ler o arquivo, ou seja, não possuem permissão de escrita. A vantagem disso é que, nesse cenário não existe o risco de ocorrer tais conflitos. Já a visão otimista é aquela onde o código pode ser editado por diversos desenvolvedores e, quando chegar na hora de realizar o merge, o desenvolvedor irá comparar os códigos decidindo quais mudanças deverão permanecer. A vantagem nessa ótica otimista é que a evolução do projeto torna-se algo mais fluida. 677 | 678 | Vamos imaginar o seguinte cenário, existem dois branches idênticos, o \textit{branch exemplo0} e o \textit{branch exemplo1}, ambos com um arquivo em branco chamado \textit{wtf}. O desenvolvedor A tem acesso ao \textit{branch exemplo0} e o desenvolvedor B ao outro \textit{branch}. 679 | 680 | O desenvolvedor A adiciona ao arquivo wtf, o seguinte conteúdo e depois faz um commit: 681 | 682 | \begin{verbatim} 683 | Java é a melhor linguagem de todas, 684 | ela é super rápida, fácil de aprender e leve. 685 | JAVA É VIDA! O NOME DO MEU FILHO VAI SER JAVA! 686 | \end{verbatim} 687 | 688 | O outro desenvolvedor adiciona o seguinte conteúdo ao arquivo wtf e também faz um commit:$$ \verb|Python é legal.|$$ 689 | 690 | Agora existem dois \textit{branches} com o mesmo arquivo, mas com conteúdos diferentes (ver figura \ref{conflito1}) e, em \textit{commits} distintos. 691 | 692 | \begin{figure}[h] 693 | \caption{\label{conflito1}Resolvendo conflito - parte 1} 694 | \begin{center} 695 | \includegraphics[width=1\linewidth]{imagens/conflito1} 696 | \end{center} 697 | \legend{Fonte: (Do autor)} 698 | \end{figure} 699 | 700 | O desenvolvedor A resolve fazer um \textit{merge} do \textit{branch} do desenvolvedor B, e acaba se deparando com a seguinte mensagem (ver figura \ref{conflito2}): $$\verb|CONFLITO (adicionar/adicionar): conflito de mesclagem em wtf|$$ 701 | 702 | \begin{figure}[h] 703 | \caption{\label{conflito2}Resolvendo conflito - parte 2} 704 | \begin{center} 705 | \includegraphics[width=1\linewidth]{imagens/conflito2} 706 | \end{center} 707 | \legend{Fonte: (Do autor)} 708 | \end{figure} 709 | 710 | Se vocês observarem, o branch atual após o merge passou a ser \textit{exemplo0|MERGING}. Nessa branch o conteúdo do arquivo wtf (ver figura \ref{conflito3}), é a união dos dois conteúdos, e o desenvolvedor terá que decidir qual código irá permanecer. 711 | 712 | \begin{figure}[h] 713 | \caption{\label{conflito3}Resolvendo conflito - parte 3} 714 | \begin{center} 715 | \includegraphics[width=1\linewidth]{imagens/conflito3} 716 | \end{center} 717 | \legend{Fonte: (Do autor)} 718 | \end{figure} 719 | 720 | O desenvolvedor A então edita o arquivo wtf e mantém o conteúdo do desenvolvedor B. Após alterar o conteúdo ele faz um novo \textit{commit} e, todos os conflito são resolvidos, tanto do código, quanto o ``conflito'' do desenvolvedor A (piada muito boa, eu sei!), ver figura \ref{conflito4}. 721 | 722 | \begin{figure}[H] 723 | \caption{\label{conflito4}Resolvendo conflito - parte 4} 724 | \begin{center} 725 | \includegraphics[width=1\linewidth]{imagens/conflito4} 726 | \end{center} 727 | \legend{Fonte: (Do autor)} 728 | \end{figure} 729 | 730 | \chapter{Trabalhando com o Git-flow} 731 | 732 | Na seção \ref{git-flow} falei brevemente do git-flow. Nesse capítulo entraremos em mais detalhes nessa incrível ferramenta que nos ajudará no desenvolvimento baseado na estratégia de ramificação apresentada no capítulo \ref{estrategia}. 733 | 734 | Como já foi dito, o \textit{git-flow} é apenas uma ferramenta para facilitar nossas vidas, você não é obrigado a usá-la, desde que siga as boas práticas e, aplique a estratégia de ramificação proposta. 735 | 736 | Lembre-se também que o \textit{git} sempre estará presente, tarefas como fazer \textit{commits}, visualizar o \textit{status}, visualizar o \textit{log}, trocar de \textit{branch}, entre outras coisas, ainda serão realizadas apenas com o \textit{git}. Também nada impede você usar os outros comandos do git que existem no git-flow. 737 | 738 | Nas próximas seções irei descrever as mesmas funcionalidades que foram ensinas com o git, mas usando comandos do git-flow, sempre mostrando as suas vantagens. 739 | 740 | \section{Criando o repositório usando o \textit{git-flow}} 741 | 742 | O comando para criar um repositório usando o \textit{git-flow} é quase idêntico ao do \textit{git}. O comando $$\verb|git flow init|$$ iniciará o repositório, mas antes fará uma série de perguntas (ver figura \ref{initGitFlow}), por padrão iremos deixar como estão, apertando enter para cada pergunta. 743 | 744 | \begin{figure}[htb] 745 | \caption{\label{initGitFlow}Iniciando repositório com o \textit{Git-flow}} 746 | \begin{center} 747 | \includegraphics[width=1\linewidth]{imagens/initGitFlow} 748 | \end{center} 749 | \legend{Fonte: (Do autor)} 750 | \end{figure} 751 | 752 | \section{Criando features} 753 | 754 | Os \textit{branches features} serão criados sempre que uma nova funcionalidade precise ser desenvolvida. Elas sempre serão iniciadas do branch develop. O comando para iniciar uma nova feature é: 755 | 756 | \begin{itemize} 757 | \item \verb|git flow feature start nomeDaFuncionalidade|, esse comando irá criar um novo \textit{branch} chamado \textit{nomeDaFuncionalidade}; 758 | \item \verb|git flow feature start telaDeLogin|, cria o \textit{branch telaDeLogin}; 759 | \end{itemize} 760 | 761 | Diferente do \textit{git}, independente de qual \textit{branch} você esteja, o \textit{branch feature} sempre será iniciado do \textit{branch develop}. 762 | 763 | Para fazer um \textit{push} de um \textit{branch feature} você usará o seguinte comando: 764 | 765 | \begin{itemize} 766 | \item \verb|git flow feature publish nomeDaFuncionalidade|, esse comando irá fazer o \textit{push} do \textit{branch} chamado \textit{nomeDaFuncionalidade}; 767 | \item \verb|git flow feature publish telaDeLogin|, faz o \textit{push} do \textit{branch telaDeLogin}; 768 | \end{itemize} 769 | 770 | Para fazer o \textit{pull} aconselho usar o git de maneira usual. Mas pode ser feito usando o \textit{git-flow} com o comando: 771 | 772 | \begin{itemize} 773 | \item \verb|git flow feature pull origin nomeDaFuncionalidade|, esse comando irá fazer o \textit{pull} do \textit{branch} chamado \textit{nomeDaFuncionalidade}; 774 | \item \verb|git flow feature pull origin telaDeLogin|, faz o \textit{pull} do \textit{branch telaDeLogin}; 775 | \end{itemize} 776 | 777 | Após terminar a criação da funcionalidade \textit{telaDeLogin}, é necessário fazer um merge para o \textit{branch develop}, depois apagar o \textit{branch local} e o \textit{branch remoto}, já que você não vai mais precisar deles. Se fosse usar apenas o git você teria que fazer cada etapa dessas separadamente, mas o git-flow realiza todas essas tarefas com o seguinte comando:$$\verb|git flow feature finish telaDeLogin|$$ 778 | 779 | Perceba que as únicas coisas que mudaram nos comandos foram as partes centrais, \textit{start}, \textit{publish} e \textit{finish}. Esse padrão irá se repetir para os outros tipos de \textit{branches}. 780 | 781 | \section{Criando releases} 782 | 783 | O \textit{branch release} deve ser criado quando for necessário enviar a aplicação para a produção. Nesse branch serão realizados testes e, após sua finalização ele será mesclado com o \textit{branch master} e o \textit{develop}. 784 | 785 | Os comandos são semelhantes ao das features, a diferença está nos nomes dos branches, no caso das releases os nomes serão as tags discutidas na seção \ref{tags}: 786 | 787 | \begin{itemize} 788 | \item \verb|git flow release start X.Y.Z|, esse comando irá criar um novo \textit{branch} chamado \textit{X.Y.Z}; 789 | \item \verb|git flow release publish 1.3.1|, faz o \textit{push} do \textit{branch 1.3.1}; 790 | \item \verb|git flow release finish 1.3.1|, finaliza o \textit{branch 1.3.1}; 791 | \end{itemize} 792 | 793 | \section{Criando hotfixes} 794 | 795 | O \textit{branch hotfix} deve ser criado quando um \textit{bug} for encontrado no branch de produção, o \textit{master}. Esse \textit{branch} será iniciado no \textit{master} e finalizado no \textit{master} e no \textit{develop}, já que o \textit{branch develop} também precisa sofrer a correção. 796 | 797 | Os comandos para o \textit{branch hostfix} seguem os mesmos padrões dos \textit{releases}: 798 | 799 | \begin{itemize} 800 | \item \verb|git flow hotfix start X.Y.W|, esse comando irá criar um novo \textit{branch} chamado \textit{X.Y.W}; 801 | \item \verb|git flow hotfix publish 1.3.2|, faz o \textit{push} do \textit{branch 1.3.2}; 802 | \item \verb|git flow hotfix finish 1.3.2|, finaliza o \textit{branch 1.3.2}; 803 | \end{itemize} 804 | 805 | \section{Criando bugfixes} 806 | 807 | O \textit{branch bugfix} tem a mesma função do \textit{hotfix}, correção de \textit{bugs}. Ele deve ser criado quando um \textit{bug} for encontrado durante a fase de desenvolvimento, ou seja, no branch develop. O \textit{branch bugfix} inicia-se no \textit{develop} e é finalizado somente no \textit{develop}. 808 | 809 | Os comandos para o \textit{branch bugfix} seguem os mesmos padrões dos \textit{features}: 810 | 811 | \begin{itemize} 812 | \item \verb|git flow bugfix start erroCarrinhoCompras|, esse comando irá criar um novo \textit{branch} chamado \textit{X.Y.W}; 813 | \item \verb|git flow bugfix publish erroCarrinhoCompras|, faz o \textit{push} do \textit{branch 1.3.2}; 814 | \item \verb|git flow bugfix finish erroCarrinhoCompras|, finaliza o \textit{branch erroCarrinhoCompras}; 815 | \end{itemize} 816 | 817 | \section{Resumo dos comandos do \textit{git-flow}} 818 | 819 | A figura \ref{comandos} abrange quase todos os comandos do \textit{git-flow} de forma resumida, demonstrando a facilidade que é trabalhar com o \textit{git-flow}. 820 | 821 | \begin{figure}[htb] 822 | \caption{\label{comandos}Resumo dos comandos do \textit{Git-flow}} 823 | \begin{center} 824 | \includegraphics[width=1\linewidth]{imagens/comandos} 825 | \end{center} 826 | \legend{Fonte: (https://danielkummer.github.io/git-flow-cheatsheet/index.html)} 827 | \end{figure} 828 | 829 | 830 | 831 | \chapter*{Finalizando} 832 | \addcontentsline{toc}{chapter}{Finalizando} 833 | 834 | Essa apostila teve como objetivo plantar uma sementinha na mente de vocês sobre o controle de versão, suas vantagens e como ele tornará seu desenvolvimento mais ágil e seguro. 835 | 836 | 837 | Existem diversas outras questões a serem abordadas e outras ferramentas. Agora depende apenas de você, pesquisar mais sobre o assunto e praticar. 838 | 839 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 840 | % 841 | \nocite{book} 842 | \nocite{gitlab} 843 | \nocite{gitflow} 844 | \nocite{semver} 845 | \nocite{gitready} 846 | \nocite{stackoverflow} 847 | \nocite{atlassian} 848 | \nocite{ndpsoftware} 849 | \nocite{rogerdudler} 850 | \nocite{danielkummer} 851 | \nocite{nvie} 852 | \nocite{cgti} 853 | \nocite{moura} 854 | \nocite{wikiversity} 855 | \nocite{stackoverflow2} 856 | \nocite{tribo} 857 | \nocite{devmedia1} 858 | \nocite{devmedia2} 859 | \nocite{marklodato} 860 | 861 | \bibliography{biblio} 862 | 863 | \end{document} 864 | --------------------------------------------------------------------------------