Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
  • devel
  • issue#56
  • issue#67
  • master
  • week01
  • week02
  • week03
  • week04
  • week05
  • week06
  • week07
  • week08
12 results

Target

Select target project
  • pet-estatistica/apostila-git
  • brunaw/git-tutorial
2 results
Select Git revision
  • devel
  • master
2 results
Show changes
Commits on Source (299)
199 additional commits have been omitted to prevent performance issues.
Expand all Show whitespace changes
Inline Side-by-side
Showing
with 7531 additions and 3184 deletions
.RData 0 → 100644
View file @ ba5e4e29
File added
.gitignore
View file @ ba5e4e29
......@@ -9,4 +9,12 @@
*.Rout
meu1repo
meu1repo/*
downloads/*
*.html
*.orig
apostila-git.Rproj
/apostila_git.toc
/apostila_git.lol
cap*.md
cap*.pdf
cap*.tex
CONTRIBUTING.md 0 → 100644
View file @ ba5e4e29
Guia de contribuição
====================
Esse é um projeto público do PET Estatística aberto a
colaboradores. Para que a colaboração seja bem sucedida, seguem algumas
instruções e recomendações.
## O funcionamento
O núcleo do tutorial é o arquivo `git_tuto.Rmd`. O arquivo `Rmd` é
marcado por ser escrito com sintaxe [markdown][] com fragmentos de
código R. Os fragmentos de código R são interpretados durante a
compilação feita com a função `render` do pacote [rmarkdown][]. Por ser
escrito em markdown, o tutorial pode ser compilado em formatos como markdown (`.md`), html e PDF.
Apesar de `Rmd` normalmente ter fragmentos de código R, nesse tutorial
predominam fragmentos de código shell, em outras palavras, são
fragmentos de código executados do terminal do Linux. Para ter um
fragmento de código shell que seja interpretado na compilação, tem-se
que fazê-lo conforme abaixo.
```{r, engine="sh"}
comando shell
```
A compilação desse documento cria sempre um projeto Git do zero. Com
instruções do shell ao longo do documento, no instante da compilação,
arquivos são criados, adicionados (`git add`), commitados (`git
commit`), modificados, etc. Esse documento é, portanto, um documento
reproduzível.
Para compilar o documento você deve abrir uma sessão R onde o diretório
de trabalho é o que contém o arquivo `git_tuto.Rmd` e rodar uma chamada
da função render. Usuários do RStudio podem fazer isso diretamente pelo
botão de compilar, presente na barra de ferramentas.
```{r, engine="sh"}
library(rmarkdown)
render("git_tuto.Rmd")
```
Os diretórios criados durante a compilação são sempre apagados, para que ao
compilar novamente, tudo seja reproduzido. O projeto deve recriar tudo e
é essa a intenção, apesar do custo. Se os diretórios não fossem
deletados antes de uma nova compilação, iria-se receber erros de
compilação.
Esse documento usa instruções no terminal que podem ser particulares do
Linux, como o comando `tree` e `sed`. Portando, a reprodutibilidade da
compilação pode não acontecer em outros sistemas operacionais.
## O fluxo de trabalho
Esse projeto terá dois ramos persistentes:
* `devel`: que irá receber imediatamente a contribuição dos
membros e será submetido a teste (no caso compilação). Se bem
sucedido, a contribuição é movida para o ramo `master`.
* `master`: que recebe a versão estável do projeto.
Os membros devem criar ramos de demanda para adicionarem suas
contribuições. Por exemplo, se existe a demanda (*issue*) de acrescentar uma
sessão sobre o uso do programa `meld` para resolver conflitos de merge,
deve-se criar um ramo para isso, adicionar as contribuições e subir esse
ramo para o repositório remoto. Os *issues* criados no GitLab são
automaticamente numerados. Para nosso benefício, vamos usar o mesmo
número ao criar os *branches* para atender as correspondentes
demandas. Vamos usar o padrão `issue#?` em que `?` representa o número
do *issue*.
```sh
git branch -b issue#3
... trabalha, git add, git commit ...
... trabalha, git add, git commit ...
... trabalha, git add, git commit ...
git push origin issue#3
```
Assim que der o `git push`, a próxima etapa é fazer uma requisição de
*merge*. Isso se faz pela interface do GitLab clicando em
[merge request][] no menu da esquerda, dentro da página do projeto, e
depois no botão *New Merge Request*. Lá é onde se designa o responsável
por avaliar e aplicar o *merge* e quais os *branches* envolvidos
(doador/receptor).
Existe apenas uma regra que jamais deve ser quebrada:
> Nunca dê `push` para os ramos `devel` e `master`.
Esses ramos se receberão conteúdo provenientes de *merge* dos ramos de
demanda (*issue*).
## Mensagens de commit
É extremamente recomendado, por questões de organização e produtividade,
que as mensagens de commit sejam apropriadas. Não use mensagens vagas ou
óbvias do tipo *Modificações feitas*, *Arquivos incluídos*. Procure algo
como *Incluí arquivo de estilo CSS*, *Modifica preâmbulo*, *Troca
'require' por 'library'* ([5 dicas para melhores commits][]).
Exitem formas especiais de escrever um *commit* que tenha ações do
repositório remoto como fechar um *issue* ou fazer uma referência a
outro *commit* ([ações nas mensagens de commit][]). As palavras
especiais são: `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`,
`resolve`, `resolves`, `resolved`. Depois das palavras vem uma
identificação de *issue* ou *sha1*.
```sh
git commit -m "Close #4. Bug devido ao encoding."
```
Visite para mais dicas de como escrever um *commit*:
[como-escrever-boas-mensagens-de-commit][]
## Escrita do código
Recomenda-se fortemente que ao escrever o código, não se ultrapasse 72
caracteres por linha. Isso torna o texto/código mais legível nos
arquivos fontes. Linhas longas são difíceis de ler nos monitores atuais,
que possuem uma tela grande.
Editores de texto (de verdade) geralmente possuem formas de auto quebrar
linhas, auto indentar/acomodar ou sinalizar a margem direita. O Emacs
tem [auto break lines][] e [refluxo de texto][]. Outros editores
permitem exibir uma linha vertical para indicar o limite, como o RStudio
(> Tools > Global Options > Code > Display > Margin column).
[markdown]: http://br-mac.org/2013/09/o-que-e-markdown.html
[rmarkdown]: http://rmarkdown.rstudio.com/
[merge request]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/merge_requests
[ações nas mensagens de commit]: https://help.github.com/articles/closing-issues-via-commit-messages/
[5 dicas para melhores commits]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
[auto break lines]: http://emacswiki.org/emacs/LineWrap
[refluxo de texto]: http://www.emacswiki.org/emacs/FillParagraph
[como-escrever-boas-mensagens-de-commit]: http://blog.diovani.com/post/101092814586/como-escrever-boas-mensagens-de-commit
README.md 0 → 100644
View file @ ba5e4e29
Apostila Git
============
PET Estatística UFPR
O [Git][] é um sistema de controle de versão distribuído cuja finalidade
é permitir que muitas pessoas colaborem no mesmo projeto facilmente
"juntando" as contribuições dos membros e incorporando ao projeto com o
mínimo de esforço possível.
Esse projeto tem a finalidade de aprofundar o conhecimento do sistema de
controle de versões Git e documentar o aprendizado em uma apostila que
seja útil tanto para iniciantes quanto para usuários intermediários.
O projeto é desenvolvido no serviço [GitLab do C3SL] e também na
organização [PET Estatística no GitHub]. Todas as contribuições ao
projeto são bem vindas, tanto por meio de [issue][] quando por *fork* em
qualquer um das plataformas (GitLab ou GitHub).
Os autores na primeira edição da apostila (*tag* [week08]) foram:
* [Alcides Conte Neto](https://gitlab.c3sl.ufpr.br/u/13) -
colaborador;
* [Alessandra Zeizer Dimas](https://gitlab.c3sl.ufpr.br/u/pazd11);
* [Ângela Luiza Cunha Legey](https://gitlab.c3sl.ufpr.br/u/alcl12);
* [Daniel Ikenaga](https://gitlab.c3sl.ufpr.br/u/di12);
* [Eduardo Elias Ribeiro Junior](https://gitlab.c3sl.ufpr.br/u/eerj12);
* [Gabriel Sartori Klostermann](https://gitlab.c3sl.ufpr.br/u/gsk12);
* [Jhenifer Caetano Veloso](https://gitlab.c3sl.ufpr.br/u/jcv13);
* [Walmes Marques Zeviani](https://gitlab.c3sl.ufpr.br/u/walmes) -
tutor.
[Git]: https://git-scm.com/book/pt-br/v1/Primeiros-passos-No%C3%A7%C3%B5es-B%C3%A1sicas-de-Git
[issue]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/issues
[GitLab do C3SL]: https://gitlab.c3sl.ufpr.br/pet-estatistica/apostila-git
[PET Estatística no GitHub]: https://github.com/pet-estatistica
[week08]: https://gitlab.c3sl.ufpr.br/pet-estatistica/apostila-git/commits/week08
apostila_git.pdf 0 → 100644
View file @ ba5e4e29
File added
apostila_git.tex 0 → 100644
View file @ ba5e4e29
\documentclass[
% a5paper,
a4paper,
% pagesize,
9pt,
% bibtotoc,
pointlessnumbers,
normalheadings,
% DIV=9,
twoside=false
]{book}
\usepackage[brazil]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[sc]{mathpazo}
% \usepackage{palatino}
% \linespread{1.05}
\usepackage[scaled=0.85]{beramono}
%-----------------------------------------------------------------------
\usepackage{amssymb, amsmath}
\usepackage{ifxetex, ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\else % if luatex or xelatex
\ifxetex
\usepackage{mathspec}
\usepackage{xltxtra,xunicode}
\else
\usepackage{fontspec}
\fi
\defaultfontfeatures{Mapping=tex-text,Scale=MatchLowercase}
\newcommand{\euro}{€}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
%-----------------------------------------------------------------------
% knitr quando faz render em Rmd para gerar tex.
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
% Add ',fontsize=\small' for more characters per line
\usepackage{framed}
\definecolor{shadecolor}{RGB}{248,248,248}
\newenvironment{Shaded}{\begin{snugshade}}{\end{snugshade}}
\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.13,0.29,0.53}{\textbf{{#1}}}}
\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.13,0.29,0.53}{{#1}}}
\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.00,0.00,0.81}{{#1}}}
\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.00,0.00,0.81}{{#1}}}
\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.00,0.00,0.81}{{#1}}}
\newcommand{\CharTok}[1]{\textcolor[rgb]{0.31,0.60,0.02}{{#1}}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.31,0.60,0.02}{{#1}}}
\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.56,0.35,0.01}{\textit{{#1}}}}
\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.56,0.35,0.01}{{#1}}}
\newcommand{\AlertTok}[1]{\textcolor[rgb]{0.94,0.16,0.16}{{#1}}}
\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.00,0.00,0.00}{{#1}}}
\newcommand{\RegionMarkerTok}[1]{{#1}}
\newcommand{\ErrorTok}[1]{\textbf{{#1}}}
\newcommand{\NormalTok}[1]{{#1}}
%-----------------------------------------------------------------------
% knitr quando faz knit em Rnw para gerar tex
% \usepackage[]{graphicx}\usepackage[]{color}
% \makeatletter
% \def\maxwidth{ %
% \ifdim\Gin@nat@width>\linewidth
% \linewidth
% \else
% \Gin@nat@width
% \fi
% }
% \makeatother
\definecolor{fgcolor}{rgb}{0.345, 0.345, 0.345}
\newcommand{\hlnum}[1]{\textcolor[rgb]{0.686,0.059,0.569}{#1}}%
\newcommand{\hlstr}[1]{\textcolor[rgb]{0.192,0.494,0.8}{#1}}%
\newcommand{\hlcom}[1]{\textcolor[rgb]{0.678,0.584,0.686}{\textit{#1}}}%
\newcommand{\hlopt}[1]{\textcolor[rgb]{0,0,0}{#1}}%
\newcommand{\hlstd}[1]{\textcolor[rgb]{0.345,0.345,0.345}{#1}}%
\newcommand{\hlkwa}[1]{\textcolor[rgb]{0.161,0.373,0.58}{\textbf{#1}}}%
\newcommand{\hlkwb}[1]{\textcolor[rgb]{0.69,0.353,0.396}{#1}}%
\newcommand{\hlkwc}[1]{\textcolor[rgb]{0.333,0.667,0.333}{#1}}%
\newcommand{\hlkwd}[1]{\textcolor[rgb]{0.737,0.353,0.396}{\textbf{#1}}}%
\usepackage{framed}
\makeatletter
\newenvironment{kframe}{%
\def\at@end@of@kframe{}%
\ifinner\ifhmode%
\def\at@end@of@kframe{\end{minipage}}%
\begin{minipage}{\columnwidth}%
\fi\fi%
\def\FrameCommand##1{\hskip\@totalleftmargin \hskip-\fboxsep
\colorbox{shadecolor}{##1}\hskip-\fboxsep
% There is no \\@totalrightmargin, so:
\hskip-\linewidth \hskip-\@totalleftmargin \hskip\columnwidth}%
\MakeFramed {\advance\hsize-\width
\@totalleftmargin\z@ \linewidth\hsize
\@setminipage}}%
{\par\unskip\endMakeFramed%
\at@end@of@kframe}
\makeatother
\definecolor{shadecolor}{rgb}{.97, .97, .97}
\definecolor{messagecolor}{rgb}{0, 0, 0}
\definecolor{warningcolor}{rgb}{1, 0, 1}
\definecolor{errorcolor}{rgb}{1, 0, 0}
\newenvironment{knitrout}{}{} % an empty environment to be redefined in TeX
\usepackage{alltt}
%-----------------------------------------------------------------------
\usepackage{graphicx}
\makeatletter
\def\maxwidth{
\ifdim\Gin@nat@width>\linewidth\linewidth
\else
\Gin@nat@width\fi}
\def\maxheight{
\ifdim\Gin@nat@height>\textheight\textheight
\else
\Gin@nat@height\fi}
\makeatother
% Scale images if necessary, so that they will not overflow the page
% margins by default, and it is still possible to overwrite the defaults
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
\ifxetex
\usepackage[setpagesize=false, % page size defined by xetex
unicode=false, % unicode breaks when used with xetex
xetex]{hyperref}
\else
\usepackage[unicode=true]{hyperref}
\fi
\hypersetup{breaklinks=true,
bookmarks=true,
pdfauthor={},
pdftitle={},
colorlinks=true,
citecolor=blue,
urlcolor=blue,
linkcolor=magenta,
pdfborder={0 0 0}}
\urlstyle{same} % don't use monospace font for urls
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
\setlength{\emergencystretch}{3em} % prevent overfull lines
\setcounter{secnumdepth}{5}
%%% Use protect on footnotes to avoid problems with footnotes in titles
\let\rmarkdownfootnote\footnote%
\def\footnote{\protect\rmarkdownfootnote}
%%% Change title format to be more compact
\usepackage{titling}
% Create subtitle command for use in maketitle
\newcommand{\subtitle}[1]{
\posttitle{
\begin{center}\large#1\end{center}
}
}
\setlength{\droptitle}{-2em}
%-----------------------------------------------------------------------
\title{Apostila Git}
\pretitle{\vspace{\droptitle}}
\posttitle{}
\author{PET Estatística UFPR}
\preauthor{}\postauthor{}
\date{2015}
\predate{}\postdate{}
\usepackage{tikz}
% Color used in the title page.
\definecolor[named]{color01}{rgb}{.2,.4,.6}
\usepackage{wrapfig}
\usepackage{wallpaper}
\usepackage{menukeys}
\usepackage{pdflscape}
\usepackage{multicol}
\usepackage{cleveref}
\usepackage[labelsep=colon]{caption}
%-----------------------------------------------------------------------
% Define ambiente para os Exemplos de Rotina.
\usepackage{float} % Controla e define objetos flutuantes.
\usepackage{tocloft} % Controla lista de objetos flutuantes.
% Nome dessa lista.
\newcommand{\listofprogramname}{Rotinas}
% Configura os arquivos auxiliares para fazer a lista.
\newlistof{program}{lol}{\listofprogramname}
\makeatletter
\newcommand\floatc@simple[2]{{\@fs@cfont #1 #2}\par}
\newcommand\fs@simple{
\def\@fs@cfont{}\let\@fs@capt\floatc@simple
\def\@fs@pre{}%
\def\@fs@post{}%
\def\@fs@mid{\kern8pt}%
\let\@fs@iftopcapt\iftrue
}
\makeatother
\floatstyle{simple}
\newfloat{program}{thp}{lol}[chapter] % Define ambiente
\floatname{program}{Rotina} % Rótulo na legenda.
%% Aparencia do sumário de rotinas
\renewcommand*\cftprogrampresnum{Rotina~}
\settowidth{\cftprogramnumwidth}{\cftprogrampresnum}
\setlength{\cftprogramindent}{0cm}
\renewcommand{\cftprogramaftersnumb}{\qquad}
\renewcommand{\cftprogramaftersnum}{:}
%-----------------------------------------------------------------------
\begin{document}
% \maketitle
%-----------------------------------------------------------------------
% Capa.
\begin{titlepage}
% \centering{{\fontsize{40}{48}\selectfont \thetitle}}\\
%
% \vspace{10mm}
% \centering{\Large{\theauthor}}\\
% \vspace{\fill} \centering \large{\thedate}
% Ideia de capa baseada em:
% http://www.latextemplates.com/template/ebook
% https://www.overleaf.com/3861001pgjtwv#/11122365/
\thispagestyle{empty}
\ThisCenterWallPaper{0.9}{./images/apostila_capa.pdf}
% Add the background image, the first argument is the scaling - adjust
% this as necessary so the image fits the entire page.
% \begin{tikzpicture}[remember picture, overlay]
% \node [rectangle, rounded corners, fill=white, opacity=0.75,
% anchor=south west, minimum width=5cm, minimum height=4cm]
% (box) at (-0.5,-10) (box){};
% % White rectangle - "minimum width/height" adjust the width and height
% % of the box; "(-0.5,-10)" adjusts the position on the page.
%
% \node[anchor=west,
% color01,
% font=\sffamily\bfseries\scshape\Large,
% xshift=-1.5cm, yshift=-1cm, text width=4cm]
% at (box.north){\thetitle};
% % "Text width" adjusts the wrapping width, "xshift/yshift" adjust the
% % position relative to the white rectangle.
%
% \node[anchor=west,
% color01,
% font=\sffamily\bfseries,
% xshift=-1.5cm, yshift=-2.5cm, text width=4cm]
% at (box.north){\theauthor};
% % "Text width" adjusts the wrapping width, "xshift/yshift" adjust the
% % position relative to the white rectangle.
% \end{tikzpicture}
$\phantom{0}$
\end{titlepage}
%-----------------------------------------------------------------------
% Dedicatórias.
\clearpage
$\phantom{0}$
\thispagestyle{empty}
\pagebreak
% \newpage
\thispagestyle{empty}
\vspace*{2cm}
\begin{center}
\Large{
\parbox{10cm}{
\begin{raggedright}
{\Large
\textit{Não é a vontade de vencer que ganha o jogo, e sim a
vontade de se preparar para vencê-lo.}
}
\vspace{.5cm}\hfill{---Paul ``Bear'' Bryant}
\end{raggedright}
}
}
\end{center}
\clearpage
$\phantom{0}$
\thispagestyle{empty}
\pagebreak
%-----------------------------------------------------------------------
% Agradecimentos.
%-----------------------------------------------------------------------
% Tabela de conteúdo.
\hypersetup{linkcolor=black}
\setcounter{tocdepth}{2}
\tableofcontents
%-----------------------------------------------------------------------
% Capítulos.
\chapter{Sistemas de controle de versão}
\input{cap01.tex}
\chapter{Instalação e Configuração}
\input{cap02.tex}
\chapter{Repositórios Locais}
\input{cap03.tex}
\chapter{Projetos Remotos}
\input{cap04.tex}
\chapter{Serviços Web para Projetos Git}
\input{cap05.tex}
\chapter{Ferramentas gráficas}
\input{cap06.tex}
\chapter{Trabalhando em equipe}
\input{cap07.tex}
% \input{cap08.tex}
% \input{cap09.tex}
\addcontentsline{toc}{chapter}{Apêndice}
\input{./cap08/cap08_er.tex}
\chapter{Dicionário de termos}
\input{./cap08/cap08_dt.tex}
\end{document}
%-----------------------------------------------------------------------
\ No newline at end of file
cap01.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Tutorial de Git"
author: "PET Estatística UFPR"
output:
pdf_document:
template:
highlight: default
toc: true
toc_depth: 2
keep_tex: true
number_sections: true
---
Inicialmente, podemos dizer que Git é um Sistema de Controle de Versão
que permite ao programador armazenar diversas cópias de versão do seu
trabalho, restaurar versões anteriores, sincronizar entre diversos
computadores de trabalho e trabalhar colaborativamente com outros
programadores. Só essas possibilidades fazem do Git uma ferramenta
muito útil a quem programa. Mas o Git é muito mais! É possível utilizar
o Git através do Shell (linha de comando) ou através de diversas
interfaces gráficas e até mesmo dentro do Rstudio. Você pode integrar
seu projeto com o Github ou Gitlab e disponibilizar os arquivos na web.
Assim, você pode acessá-los e até editar seus arquivos via navegador.
Pode deixar os arquivos públicos e disponibilizar seu código à
comunidade de programadores. Outras pessoas podem até vir a colaborar
nos seus projetos. Neste conceito, você pode fazer uso ou colaborar com
projetos de outros programadores. Acompanhar o desenvolvimento de
projetos que sequer foram lançados, fazer sugestões, tirar dúvidas e
entrar em contato direto com equipes e desenvolvedores. Isso transforma
o Github e Gitlab numa rede social de programadores.
O Git não é o único sistema de controle de versão. Nem foi o primeiro.
Os primeiros sistemas de controle de versão foram lançados na década
de 70. Há sistemas abertos e proprietários. E também, sistemas que
trabalham somente de forma local, cliente-servidor ou sistema
distribuído. Dentre os sistemas abertos, os mais conhecidos são o Apache
Subversion (SVN), Mercurial, Git, Veracity e Bazzar. Mas, por que tantos
sistemas foram desenvolvidos? Cada sistema foi desenvolvido buscando
resolver os mesmos problemas de diferentes formas. A comunidade
desenvolvedora do kernel (núcleo) do Linux utilizava o BitKeeper, um
software proprietário que decidiu revogar a licença gratuita. Linus
Torvalds, desenvolvedor do primeiro kernel, estudou os diversos
softwares de controle de versão para ser o substituto do BitKeeper. Mas
nenhum software atendia as necessidades, principalmente na performance
de um projeto tão grande. Então, ele iniciou o desenvolvimento do
software que ele chamou de Git e em menos de dois meses todo o
gerenciamento do kernel já estava transferido para o novo sistema.
Então, utilizar o Git é a garantia de um sistema robusto de controle de
versionamento. Um sistema aberto e muito utilizado por programadores,
estatísticos e cientistas de dados.
Seja você mais um desenvolvedor a resolver os seus problemas e
participar desta comunidade.
cap02.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Instalação e Configuração"
author: "PET Estatística UFPR"
date: "29/10/2015"
graphics: yes
output:
pdf_document:
template:
highlight: default
toc: true
toc_depth: 2
keep_tex: true
number_sections: true
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```
Agora, devidamente apresentados ao sistema de versionamento Git vamos
utilizá-lo. Porém, antes de começarmos a entender os comandos Git, é
necessária sua instalação e configuração. Neste capítulo veremos
primeiramente como instalar o programa Git em diferentes sistemas
operacionais e posteriormente como configurar algumas opções para
viabilizar e facilitar seu uso.
# Instalação
## Windows
Usuários do Windows devem visitar Git for
Windows\footnote{\url{https://git-for-windows.github.io/}}, clicar em
"Download" e baixar o arquivo ".exe".
Após o download, execute o arquivo e você terá a tela conforme figura
\ref{fig:inst01}:
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst01.png}
\end{center}
\caption{\textit{Printscreen} do passo 1}
\label{fig:inst01}
\end{figure}
Em seguida, clique em "Next". Para dar continuidade a instalação
aceite a licença do Git.
O diretório apresentado na figura \ref{fig:inst02} vem como'default',
porém é possível alterar a instalação para um diretório de sua
preferência. Depois de selecionado o caminho da instalação, clique em
"Next" para prosseguir.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst02.png}
\end{center}
\caption{\textit{Printscreen} do passo 2}
\label{fig:inst02}
\end{figure}
Na tela de componentes (figura \ref{fig:inst03}) podemos definir
atalhos, integração ao menu de contexto do Windows Explorer, associação
de arquivos e uso de font TrueType. O Git Bash é o prompt de comandos
próprio, que além dos comandos Git também fornece alguns comandos Unix
que podem ser bem úteis. Já o Git GUI é uma interface gráfica para
trabalhar com Git. É recomendável a seleção de ambos os itens.
Depois de selecionado os componentes de sua preferência, clique em
"Next" para dar continuidade.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst03.png}
\end{center}
\caption{\textit{Printscreen} do passo 3}
\label{fig:inst03}
\end{figure}
No passo 4, representado pela figura \ref{fig:inst04}, o instalador nos
oferece a oportunidade de mudar o nome da pasta no menu iniciar,
recomenda-se deixar o padrão para fácil localização posteriormente.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst04.png}
\end{center}
\caption{\textit{Printscreen} do passo 4}
\label{fig:inst04}
\end{figure}
Na tela de configuração "PATH environment",conforme a figura
\ref{fig:inst05}, podemos escolher as formas de integração do Git com o
sistema. A primeira opção nos permite usar o Git apenas pelo "Git Bash"
(é o prompt de comando do Git), a segunda opção nos possibilita executar
os comandos no "Git Bash" e no prompt de comando do Windows (cmd.exe), e
a terceira opção é a junção das duas de cima, porém alguns comandos do
Windows serão substituídos por comandos Unix com mesmo nome. Essa
última opção não é recomendada, a primeira opção é a desejável.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst05.png}
\end{center}
\caption{\textit{Printscreen} do passo 5}
\label{fig:inst05}
\end{figure}
Na figura \ref{fig:inst06}, temos a configuração de quebra de linha.
Windows e sistemas Unix (Linux, Mac) possuem formatos diferentes de
quebra de linha em arquivos de texto. Se você escreve um código com
quebras de linha no formato Windows, outra pessoa pode ter problemas ao
abrir o mesmo arquivo em um Linux, e vice-versa. Este passo, portanto,
permite normalizar isso. A primeira opção converte automaticamente os
arquivos para padrão Windows quando receber algum arquivo e converterá
para padrão Unix quando “comitar” (enviar alterações) ao repositório. A
segunda opção, não faz nenhuma conversão ao receber arquivos, mas
convertem para padrão Unix ao “comitar”. Já a terceira opção, o Git não
fará nenhuma conversão. Recomenda-se a seleção da opção "Checkout
Windows-style, commit Unix-Style line endings".
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst06.png}
\end{center}
\caption{\textit{Printscreen} do passo 6}
\label{fig:inst06}
\end{figure}
No passo da figura \ref{fig:inst07}, temos a configuração do emulador de
terminal para usar com o Git Bash. A primeira opção utiliza o terminal
MSys2 (Shell), que permite utilizar comandos Unix no Windows. Já a
segunda opção, utiliza o terminal padrão do Windows. Recomendamos a
primeira opção. Feito isso, dê continuidade à instalação.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst07.png}
\end{center}
\caption{\textit{Printscreen} do passo 7}
\label{fig:inst07}
\end{figure}
E por último, a figura \ref{fig:inst08}, que configura ajustes de
performance. Essa opção é para habilitar o sistema de cache de arquivo.
\begin{figure}
\begin{center}
\includegraphics [width=8cm]{./images/inst08.png}
\end{center}
\caption{\textit{Printscreen} do passo 8}
\label{fig:inst08}
\end{figure}
Feito isso, "Next", "Finish" e o Git está instalado.
## Linux
Em qualquer sistema Linux, pode-se utilizar o gerenciador de pacotes da
respectiva distribuição para instalar o Git. Basta executar o código de
instalação de sua respectiva distribuição.
**Debian**
Em uma sessão de terminal Linux de distribuições Debian (Ubuntu, Mint),
execute o código abaixo. Adicione o ppa para obter a versão mais
recente do Git.
```{r, engine="bash", eval=FALSE}
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
```
Agora, execute o comando abaixo para instalação do Git. Siga as
instruções do prompt de comando, primeiro confirmando a instalação dos
pacotes e suas dependências, depois confirmando a instalação do pacote
git-core.
```{r, engine="bash", eval=FALSE}
sudo apt-get install git git-core git-man git-gui git-doc \
ssh openssh-server openssh-client
git --version
```
Para adicionar ferramentas complementares, execute:
```{r, engine="bash", eval=FALSE}
sudo apt-get install gitk meld
```
**Arch**
```{r, engine="bash", eval=FALSE}
pacman -S git openssh meld
git --version
```
**Fedora**
```{r, engine="bash", eval=FALSE}
yum install git
git --version
```
Usuários de outra versão do Linux podem visitar Download for
Linux\footnote{\url{https://git-scm.com/download/linux}}.
## MacOS
Existem duas maneiras de instalar o Git no Mac, uma pelo instalador e
outra através do MacPorts.
**Utiizando o Instalador**
O usuário deverá acessar Download for
Mac\footnote{\url{http://git-scm.com/downloads}}, clicar em "Download" e
baixar o arquivo ".dmg".
Após o download, é necessário clicar duas vezes para ter acesso ao
pacote de instalação. Dentro do arquivo ".dmg", execute o arquivo ".pkg"
para iniciar a instalação. Siga os passos até concluir a instalação. É
recomendável utilizar a instalação padrão.
Para testar a instalação, abra o terminal e digite o comando "git". A
saída deverá ser similar a figura \ref{fig:inst09}:
\begin{figure}
\begin{center}
\includegraphics[width=9cm]{./images/inst09.png}
\end{center}
\caption{\textit{Printscreen} do passo 9}
\label{fig:inst09}
\end{figure}
**Utiizando o MacPorts**
A maneira mais fácil de instalar Git no Mac é via
MacPorts\footnote{\url{http://www.macports.org}}, para isso basta
executar o seguinte comando:
```{r, engine="bash", eval=FALSE}
sudo port install git-core
```
# Configurando Perfil
As configurações vão determinar algumas opções globais do Git, sendo
necessário fazê-las apenas uma vez.
## Usuário
Os comandos abaixo vão configurar o nome de usuário e endereço de
e-mail. Esta informação é importante pois é anexada aos commits que
você realiza, ou seja, as configurações ficarão associadas ao trabalho
em desenvolvimento, permitindo que os colaboradores/gestores do projeto
identifiquem suas contribuições. Caso o projeto seja individual, a
importância de configurar usuário e e-mail se mantém. Uma vez que se
trabalha com duas ou mais máquinas, a maneira de identificar a pessoa
que está desenvolvendo o trabalho é pelo nome de usuário.
Em um terminal Bash, execute o código abaixo:
```{r, engine="bash", eval=FALSE}
git config --global user.name "Knight Rider"
git config --global user.email "batman@justiceleague.org"
```
A opção `--global` usará essa informação para todo projeto Git da
máquina.
É possível fazer definições para cada projeto, ou seja, não globais.
Para isso é necessário executar o comando a seguir sem a opção
`--global`.
```{r, engine="bash", eval=FALSE}
git config user.name "Knight Rider"
git config user.email "batman@justiceleague.org"
```
Uma vez configurado o perfil, o Git está pronto para uso.
## Atalhos
Os atalhos no Git são chamados de *Alias*. Com ele podemos mapear
comandos que repetidamente usamos para algumas poucas teclas. Estes
atalhos podem ser criados de dois modos: através do comando no terminal
ou editando diretamente no arquivo `/.gitconfig`.
**Pelo terminal:**
Execute o comando abaixo com o atalho de sua preferência e o nome
completo do comando o qual deseja criar o alias.
```{r, engine="bash", eval=FALSE}
git config --global alias.nome_do_alias "comando inteiro"
```
Um exemplo bem simples é o seguinte:
```{r, engine="bash", eval=FALSE}
git config --global alias.st "status"
```
Assim, ao executar git st é o mesmo que executar git status.
Pelo método citado acima, o alias é adicionado automaticamente no seu
arquivo `/.gitconfig`.
**Pelo arquivo `/.gitconfig`:**
Pode-se criar atalhos através de um bloco no seu arquivo de
configuração. Para isso, é necessário localizar o diretório do Git e
adicionar a lista de comandos desejada, como no exemplo:
```{r, engine="bash", eval=FALSE}
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
```
Assim que adicionar este bloco com os comandos de sua escolha, ele irá
funcionar imediatamente.
Seguem abaixo os caminhos para encontrar o arquivo `/.gitconfig` nos
sistemas operacionais:
+ Windows:
1. `C:\\Pasta_do_seu_projeto\\.git\\config`
2. `C:\\Documents and Settings\\Seu_usuario\\.gitconfig`
3. `C:\\Arquivos de programas\\Git\\etc\\gitconfig`
+ Mac:
1. `/Pasta_do_seu_projeto/.git/config`
2. `/Users/Seu_usuario/.gitconfig`
3. `/usr/local/git/etc/gitconfig`
+ Linux:
1. Crie um arquivo como _sudo_ dentro da pasta etc/ com nome de
gitconfig e coloque os atalhos de sua escolha.
Obs: Os arquivos de configuração do Git não têm extensão.
Não importa o método que você utilize, suas configurações sempre ficarão
salvas no arquivo `/.gitconfig`.
## Ignorar Arquivos
Usando o arquivo `.gitignore` podemos ignorar arquivos que não desejamos
versionar no repositório. Isso pode ser feito por projeto e/ou por usuário.
Configurar um arquivo `.gitignore` antes de começar a trabalhar, é
importante, pois evita commits acidentais de arquivos que não deveriam
ir para o seu repositório Git.
**Ignorar Arquivos por Projeto:**
Em todos os projetos que necessitam de um controle de versão há sempre
casos em que arquivos não precisam ser versionados. Para isso é preciso
criar um arquivo `.gitignore` no diretório raiz do projeto, o qual
contém padrões (pattern) que serão ignorados. Cada padrão fica em uma
linha como no exemplo:
```{r, engine="bash", eval=FALSE}
$ cat .gitignore
*.[oa]
*~
```
A primeira linha fala para o Git ignorar qualquer arquivo finalizado em
**.o** ou **.a** e a segunda linha ignora todos os arquivos que terminam
com um til **(~)**. Esses padrões podem ser feitos de acordo com a
necessidade de cada projeto.
**Ignorar Arquivos por Usuário (Globalmente):**
Para não precisar criar uma lista de comandos para serem ignorados em
cada projeto, é possível ignorar arquivos em todos os repositórios. Para
isso, basta criar um arquivo `.gitignore` em seu diretório _home_
contendo os padrões que deseja ignorar e executar o comando abaixo
no terminal a partir da pasta onde está localizado o arquivo
`.gitignore`:
```{r, engine="bash", eval=FALSE}
git config --global core.excludesfile ~/.gitignore
```
A partir disso, todos os arquivos que estão na lista serão ignorados
pelo usuário.
Finalmente, com a instalação, configuração essencial (usuário e e-mail) e
configurações adicionais concluídas, podemos começar a utilizar o Git
para versionar nossos projetos.
git_tuto.Rmd → cap03.Rmd
View file @ ba5e4e29
This diff is collapsed.
cap04.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Projetos Remotos"
author: "PET Estatística UFPR"
graphics: yes
header-includes:
\usepackage{menukeys}
output:
pdf_document:
template:
highlight: default
toc: true
toc_depth: 2
keep_tex: true
number_sections: true
---
Nos capítulos anteriores descrevemos como instalar o Git e ter projetos
versionados. No entanto, o uso do Git até então foi apenas local. Os
arquivos eram mantidos na sua máquina de trabalho e disponíveis só para
você.
Os recursos do Git, como o desenvolvimento em *branches*, permitem que
vários segmentos sejam conduzidos de forma independente e no futuro,
quando apropriado, reunidos em um único *branch*. Isso é exatamente o
que precisamos para trabalhar em equipe, certo? Se cada colaborador
pudesse ter um ramo separado do projeto para trabalhar, todos poderiam
trabalhar simultaneamente. Quando oportuno, bastaria fazer *merges* para
reunir o trabalho. A questão é: como deixar o projeto disponível para os
colaboradores?
A resposta é simples: mantenha o projeto em um servidor onde os
colaboradores tenham acesso. Isso inclusive vai permitir que você acesse
o projeto de várias outras máquinas, como o *notebook* de casa e o
desktop do *escritório*.
# Repositório remoto pessoal
O repositório remoto serve de centro do seu repositório Git. Como ele
está em um servidor que você tem acesso, você pode compartilhar o
repositório com outras máquinas, clonando de lá. Ele serve como *backup*
do repositório.
Aqui não se trabalha em colaboração mas o processo permite acessar o
repositório, transferir arquivos de várias máquinas suas.
```{r, engine="bash", eval=FALSE}
## Autenticar no servidor (logar).
ssh eu@servidor
## Verificar se a máquina tem o Git, se não instalar.
git --version
## Criar um diretório para conter o projeto.
mkdir -p ~/meusProjetos/meu1repo
cd ~/meusProjetos/meu1repo
## Começar um projeto Git remoto. Note a opção --bare.
git --bare init
```
Apenas isso precisa ser feito no servidor. Você não cria nenhum arquivo
pelo servidor. Inclusive, muitos dos comandos Git, como `git status` não
funcionam para repositório iniciados com a opção `git --bare init`.
Caso queira, você também pode usar `git init`. A diferença entre eles é
só onde ficam os arquivos do versionamento. Com `git init`, um diretório
oculto `.git/` é o repositório Git e os arquivos de trabalho, como o
`README.md`, ficam ao lado dele na estrutura de diretório. Com `git
--bare init` o conteúdo do repositório Git fica na raiz. Essa última
opção é justamente para criar repositórios remotos que vão justamente
manter a parte repositório e não os arquivos.
\begin{verbatim}
git init git --bare init
. .
|-- .git |-- branches
| |-- branches |-- config
| |-- config |-- description
| |-- description |-- HEAD
| |-- HEAD |-- hooks
| |-- hooks |-- info
| |-- info |-- objects
| |-- objects +-- refs
| +-- refs
+-- README.md
\end{verbatim}
Uma vez iniciado o repositório no servidor, todo trabalho passa a ser
local. É a vez de adicionar o endereço do diretório no servidor e
transferir arquivos.
```{r, engine="bash", eval=FALSE}
## Agora na sua máquina local, adicione o endereço do remoto.
git remote add eu@server:~/meusProjetos/meu1repo
## Exibir os endereços remotos.
git remote -v
```
Esse endereço pode ter IP, porque na realidade, todo servidor tem um
IP. Por exemplo, o servidor do `github.com` tem o IP
192.30.252.129. Para saber o IP é só dar um *ping* no endereço.
```{r, engine="bash", eval=FALSE}
ping github.com
ping gitlab.com
ping google.com
ping cran.r-project.org
```
Normalmente, servidores de escritório não têm um endereço nominal,
apenas o IP (numérico). É necessário registrar domínio para ter
nominal.
```{r, engine="bash", eval=FALSE}
## Agora na sua máquina local, adicione o endereço do remoto.
git remote add eu@111.22.333.44:~/meusProjetos/meu1repo
```
Nesse processo, toda transferência de arquivos vai pedir senha do seu
usuário no servidor. Para facilitar, pode-se trabalhar com chaves
públicas.
O arquivo `id_rsa.pub` é a sua chave pública. O `id_rsa` é o seu
par. RSA é o tipo de encriptação. O nome e caminho do arquivo e a
encriptação podem ser outros, depende do que você escolher ao gerar o
par de chaves. Normalmente usa-se RSA e as chaves são criadas no
diretório `~/.ssh`.
```{r, engine="bash", eval=FALSE}
## Exibir chaves públicas.
cat ~/.ssh/id_rsa.pub
## Caso não tenha, gerar.
ssh-keygen -t rsa -C "eu@dominio.com"
```
No servidor, o arquivo `authorized_keys2` contém as chaves públicas das
máquinas com acesso permitido sem senha. Esse arquivo nada mais é que
uma coleção de chaves. O conteúdo dele são as chaves das suas máquinas,
ou das máquinas de outros usuários, conteúdo do `id_rsa.pub`, uma
embaixo da outra, conforme o exemplo abaixo\footnote{O Flash foi o
primeiro a transferir as chaves para o servidor porque ele é mais
rápido}.
```{r, engine="bash", eval=FALSE}
## `authorized_keys` do servidor da Liga da Justiça.
ssh-rsa IyBUrjvUdSMY... flash@justiceleague.org
ssh-rsa AAAAB3NzaC1y... batman@justiceleague.org
ssh-rsa Mdju17IdXhSd... superman@justiceleague.org
```
```{r, engine="bash", eval=FALSE}
## Logar no servidor
ssh eu@111.22.333.44
## Criar o diretório/arquivo para as chaves públicas.
mkdir ~/.ssh
> authorized_keys2
```
Agora é preciso transferir o conteúdo do seu arquivo local `id_rsa.pub`
para o `authorized_keys2` que fica no servidor. O jeito mais simples de
fazer isso é com transferência *scp* mas a instrução *ssh* abaixo também
resolve.
```{r, engine="bash", eval=FALSE}
## Transfere arquivo para diretório temporário.
scp ~/.ssh/id_rsa.pub eu@111.22.333.44:/tmp
## Cola o conteúdo do *.pub no final do authorized_keys.
ssh eu@111.22.333.44\
"cat /tmp/id_rsa.pub ~/.ssh/authorized_keys"
## Faz os dois passos anteriores de uma vez só.
ssh eu@111.22.333.44\
"cat >> ~/.ssh/authorized_keys2" < ~/.ssh/id_rsa.pub
```
# Repositório remoto coletivo
Recomenda-se criar um novo usuário e
adicionar as chaves públicas de todos os membros. Evite adicionar chaves
públicas para usuários na sua conta porque isso expõe seus documentos,
alguma operação desastrosa por parte de alguém pode comprometê-los. Por
isso, crie um usuário, por exemplo `gitusers`, para nesta conta manter o
repositório remoto.
Solicite que os colaboradores gerem as chaves públicas e te enviem o
arquivo `id_rsa.pub`. Depois você adiciona cada chave ao
`authorized_keys` de conta `gitusers`. Com chaves autorizadas, os
colaboradores podem transferir arquivos, podem logar no servidor mas não
podem instalar nada, a menos que você passe a senha do usuário
`gitusers`. Para criar usuários no servidor, você precisa de privilégios
de *admin*.
```{r, engine="bash", eval=FALSE}
## Logar na servidora.
ssh eu@servidor
## No servidor, criar uma conta para o projeto.
sudo adduser gitusers
```
Vamos assumir que você tem os arquivos `*.pub` dos colaboradores no
diretório `/chaves` devidamente identificados pelo nome deles. O comando
abaixo acrescenta as chaves deles uma embaixo da outra no
`authorized_keys`.
```{r, engine="bash", eval=FALSE}
## Entra no diretório com os arquivos *.pub.
## Existem várias: angela.pub, jhenifer.pub, ...
cd chaves
## Juntar as chaves em um único arquivo.
cat *.pub > todos.pub
## Copiar o conteúdo do arquivo pro authorized_keys2.
ssh gitusers@111.22.333.44\
"cat >> ~/.ssh/authorized_keys2" < todos.pub
```
# Fluxo de trabalho com repositório remoto, do clone ao push
## Git clone
Este comando é usado para clonar um repositório do servidor remoto para
um servidor local, caso você queira copiar um repositório que já existe
para realizar colaborações em um projeto que queira participar. Você
terá acesso a todos os arquivos e poderá verificar as diferentes versões
destes. Supondo que sua equipe de trabalho possui uma biblioteca Git
**Teste Clone**, onde são armazenados todos os arquivos. Você pode
clonar estes arquivos para o seu diretório de trabalho e assim
modificá-los conforme deseja.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git
```
Desta forma você terá um diretório `TesteClone` em seu computador, onde
estarão todos os arquivos do projeto nele.
Você também terá a opção de clonar o repositório `TesteClone` em um
diretório diferente do padrão Git, que no próximo exemplo denominaremos
de `DirTeste`:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git DirTeste
```
## Git Push
Após clonar e realizar contribuições ao projeto, você pode enviá-los
para o repositório remoto. Estes arquivos, após o `Git push`, estarão
prontos para serem integrados ao projeto com o `merge`, usado para
transferência de arquivos entre repositório local e o servidor
remoto. Como o nome já diz, o comando empurra os arquivos para o
servidor remoto. No exemplo abaixo enviaremos a ramificação `Branch
Master` para o servidor chamado `origin`:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git push origin master
```
É importante ressaltar que se dois usuários clonarem ao mesmo tempo,
realizarem modificações e enviarem os arquivos atualizados ao
repositório utilizando o `Git push`, as modificações do usuário que
realizou o push por último serão desconsideradas.
## Git Pull
Para obter todos os arquivos presentes no projeto, você pode importar os
arquivos do branch `master`. Toda vez que você utilizar o `Git pull` a
última versão de todos os arquivos estarão no seu diretório. Também
usado para transferência de arquivos, o comando puxa os arquivos do
servidor remoto para o repositório local e faz o merge do mesmo,
fundindo a última versão com a versão atualizada.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git pull origin master
```
## Git fetch
Assim como o comando `Git pull`, o `Git fetch` transfere arquivos do
repositório remoto para o local, porém ele não realiza automaticamente o
merge dos arquivos transferidos, o usuário deve fazer o merge
manualmente.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git fetch origin master
```
Para verificar as modificações realizadas entre versões de um arquivo
basta utilizar o comando `git diff`:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git diff master origin/master
```
# Listar branches locais/remotos
O comando `git remote` é usado para verificar quais repositórios estão
configurados.
**Exemplo:** para retornar a lista de repositórios:
```{r, engine="bash", eval=FALSE}
git remote
```
No comando acima é possível visualizar o remoto padrão **origin** (URL
SSH para onde será possível enviar os seus arquivos).
**Exemplo:** para retornar o nome dos repositórios com a URL onde foram
armazenados:
```{r, engine="bash", echo=TRUE, eval=FALSE}
git remote -v
```
# Adicionar, renomear, deletar remote
## Adicionando repositórios remotos
O comando `git remote add` adiciona um repositório remoto. No exemplo a
seguir será adicionado um repositório chamado **MeuRepo** ao qual será
vinculado à URL
`git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git`. Usaremos
como exemplo o projeto **Apostila-git**.
**Exemplo:**
```{r, engine="bash", echo=TRUE, eval=FALSE}
git remote add MeuRepo \
git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
## A lista de repositórios agora é:
git remote -v
```
Para acessar localmente o branch master do projeto **Apostila-git** será
usado `MeuRepo/master`.
## Obtendo informações de um Remoto
Você pode acessar as informações de qualquer repositório remoto com o
comando `git remote show`, que retornará a URL e os `branches`.
**Exemplo:**
```{r, engine="bash", echo=TRUE, eval=FALSE}
git remote show origin
```
## Renomeando Remotos
O comando `git remote rename` pode modificar o nome de um repositório
remoto. A seguir o repositório `MeuRepo` será renomeado para
`RenameRepo`.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git remote rename MeuRepo RenameRepo
```
## Removendo Remotos
Para remover remotos é utilizado o comando `git remote rm`. Com isso, será
removido o repositório renomeado anteriormente `RenameRepo`.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git remote rm RenameRepo
```
## Deletar ramos no servidor
Quando houver um branch que não está sendo utilizado ou está concluído,
há a opção de excluí-lo do servidor. Se for necessário apagar branches
remotos, podemos utilizar o comando a seguir:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git push origin --delete <branch>
```
## Clonar apenas um *branch*, *commit* ou *tag*.
É possível clonar apenas um branch e não o repositório Git
completo. Supondo que no repositório há um branch chamado `MeuBranch`
dentro do repositório `MeuRepo`, clonaremos o branch.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git clone -b MeuBranch --single-branch git://sub.domain.com/MeuRepo.git
```
O Git ainda permite clonar um commit ou tag.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
## Para uma tag:
git -e: //git.myproject.org/MyProject.git@v1.0#egg=MyProject
## Para um commit:
git -e: //git.myproject.org/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=MyProject
```
# Criando um Repositório Git #
Primeiramente é necessário ter acesso a um servidor Linux com chave SSH,
no qual você poderá ter seus repositórios. É definido um diretório no
qual será armazenado o repositório remoto. No próximo exemplo é preciso
criar um repositório remoto chamado `MeuRepo` e o armazenar em um
diretório `~/git`:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
# Para criar um diretório git na sua home:
mkdir ~/git
# Para criar um repositório git:
mkdir MeuRepo.git
# Para definir MeuRepo como um repositório remoto:
git --bare init
```
As configurações do servidor estão completas. A partir de agora você
pode realizar os primeiros comandos para iniciar o repositório criado.
# Git no servidor #
Primeiramente, para configurar o Git no Servidor e configurar os
protocolos, clonaremos o repositório existente em um repositório limpo.
**Observação:** você poderá colocar um repositório no Servidor se este
não contém um diretório de trabalho.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
git clone --bare MeuRepo MeuRepo.git
```
Acima foi criado um repositório limpo `MeuRepo.git`, no qual está
armazenada a cópia de todos os arquivos do diretório Git.
Após este primeiro passo o repositório limpo será colocado no Servidor e
configurados os protocolos. No exemplo abaixo, supondo que você tem
configurado um servidor `git.servidor.com` e um diretório `/dir/git` no
qual você queira armazenar seus repositórios. Ao copiar o seu repositório
limpo, você pode configurar seu novo repositório.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
scp -r MeuRepo.git usuario@git.example.com:/dir/git
```
Agora o repositório pode ser clonado por outros usuários, que podem ter
acesso de escrita e de envio de arquivos `push` no diretório.
```{r, engine="bash", eval=FALSE}
git clone usuario@git.example.com:/dir/git/MeuRepo.git
```
# Configuração de Conexão SSH com Servidor #
O Git possibilita ao usuário realizar uma chave SSH que fará uma conexão
segura da sua máquina com o servidor. Para isso começamos com o seguinte
comando no terminal:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
## Gerando uma chave ssh
ssh-keygen -t rsa -C "usuario@email.com"
```
A partir deste comando, será possível alterar o diretório onde será
salva a chave SSH. O usuário tem a opção de permanecer com o diretório
padrão, para isso basta apertar Enter. A partir disso, são criados dois
arquivos no diretório, o `id_rsa` e o `id_rsa.pub`. Após escolher o
diretório onde serão salvos os arquivos, você terá a opção de digitar
uma senha ou deixar o espaço em branco.
Para visualizar a chave basta digitar o seguinte comando:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
cat ~/.ssh/id_rsa.pub
```
A chave está no arquivo `id_rsa.pub`. O usuário deve copiar o texto
deste arquivo na íntegra. Para gerar a conexão ssh com o servidor, deve
visitar o site
[https://gitlab.c3sl.ufpr.br/profile/keys](https://gitlab.c3sl.ufpr.br/profile/keys)
e clicar em
[Add SSH Key](https://gitlab.c3sl.ufpr.br/profile/keys/new). É
necessário escrever um título para a sua nova chave, no campo `key`,
colar o texto copiado do arquivo `id_rsa.pub` e adicionar sua nova
chave.
Para checar a configuração da sua máquina com o servidor basta realizar o
seguinte comando:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
ssh -T git@gitlab.c3sl.ufpr.br
```
**Configurando o servidor**
Agora será abordado como configurar o acesso SSH do ponto de vista do
servidor. Você precisa criar um usuário Git e um diretório `.ssh` para
este usuário.
**Exemplo:** criar usuário e diretório.
```{r, engine="bash", eval=FALSE}
sudo adduser git
su git
cd
mkdir .ssh
```
Agora, você terá um arquivo chamado `authorized_keys` onde será
adicionada uma chave pública de algum desenvolvedor. Após obter chaves
de alguns usuários, você pode salvá-las no arquivo `authorized_keys`,
como no exemplo a seguir.
**Exemplo:**
```{r, engine="bash", eval=FALSE}
## Chave do primeiro usuário.
cat /tmp/id_rsa1.pub >> ~/.ssh/authorized_keys
## Chave do segundo usuário.
cat /tmp/id_rsa2.pub >> ~/.ssh/authorized_keys
...
```
Depois de armazenar as chaves dos usuários, basta criar um repositório
limpo (sem um diretório de trabalho) para eles. Como visto
anteriormente:
**Exemplo:**
```{r, engine="bash", eval=FALSE}
cd/dir/git
mkdir NovoProjeto.git
cd NovoProjeto.git
git -bare init
```
Agora, os usuários, cujas chaves foram salvas no arquivo
`authorized_keys` podem compartilhar arquivos no repositório com os
comando `git init`, `git add`, `git commit`, `git remote add` e `git
push origin master`.
cap05.Rmd 0 → 100644
View file @ ba5e4e29
This diff is collapsed.
cap06.Rmd 0 → 100644
View file @ ba5e4e29
This diff is collapsed.
cap07.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Trabalhando em equipe"
author: "PET-Estatística UFPR"
graphics: yes
header-includes:
\usepackage{wrapfig}
output:
pdf_document:
template:
highlight: default
toc: true
toc_depth: 2
keep_tex: true
number_sections: true
---
```{r, include=FALSE}
library(knitr)
opts_chunk$set(comment=NA)
```
O Git é uma ferramenta que aliada a outros serviços web, como GitLab ou
GitHub, oferece funcionalidade e autonomia para se trabalhar. Contudo,
com tantos recursos disponíveis, só serão bem aplicados quando todos os
membros do grupo, além de conhecê-los, trabalham em harmonia.
# Boas práticas de colaboração
Repositório é onde são armazenados os arquivos de um projeto. Existem
três níveis de acesso permitidos:
- **Private**: é o repositório fechado, onde apenas o criador (Owner)
tem permissão de leitura e escrita. Se um repositório privado for
criado dentro de um grupo, todos do grupo terão permissão de leitura
e escrita.
- **Internal** repositório fechado para usuários externos ao grupo,
mas qualquer usuário cadastrado no grupo terá permissão de leitura e
escrita no repositório.
- **Public**: repositório aberto, visível para qualquer pessoa
(usuário do grupo ou não). Usuários do grupo tem permissão de
leitura e escrita no repositório. Usuários sem conta no grupo podem
clonar o repositório, mas não tem permissão para alterar o
repositório (enviar merge requests por exemplo).
É possível adicionar usuários para colaborar em um repositório. Cada
usuário pode ter um nível de acesso diferente: **Guest**, **Reporter**,
**Developer**, **Master**. Em permissões
\footnote{\url{https://gitlab.c3sl.ufpr.br/help/permissions/permissions}}
é possível visualizar as habilidades concedidas para cada nível.
Logo após criar um novo repositório, é recomendável que se crie um
arquivo `README.md`. Independente da forma como o repositório foi
configurado, é sempre fundamental que ele contenha o arquivo
`README.md`. Este arquivo é sempre o primeiro a ser mostrado na página
inicial de todo repositório. Por esse motivo, é importante que o
`README.md` contenha no mínimo:
- Uma descrição geral do projeto;
- Os nomes dos autores do projeto;
- Instruções de instalação, no caso de softwares;
- A licença do projeto (especialmente para projetos públicos), ou uma
orientação sobre o uso do projeto (permissão, citação, entre
outros). Opcionalmente pode-se criar um arquivo *LICENSE* com a
licença. Esse arquivo ficará disponível também em uma aba na página
inicial do projeto.
- (**Opcional**): um guia de contribuição, se o (Owner) do projeto
pretende que usuários externos colaborem, é possível apresentar
algumas orientações básicas sobre como colaborar. Criando um arquivo
`CONTRIBUTING.md` com este guia, ele será automaticamente colocado
em uma aba na página inicial do projeto.
- (**Opcional**): um *changelog* para que sejam registradas as
modificações realizadas entre uma versão e outra (principalmente
para softwares). Criando esse arquivo com estas informações, ele
aparecerá automaticamente em uma aba na página inicial do projeto.
Outra parte fundamental do Git, são os **commits**. Além de salvarem as
alterações realizadas nos arquivos, também são responsáveis por
documentar as alterações feitas por qualquer usuário e em qualquer
arquivo. Os commits agilizam o processo de revisão do projeto, e poderá
ajudar futuros mantenedores do projeto a desvendar o motivo de algum
acréscimo ou modificação no código. Por causa dessas importâncias, uma
mensagem bem escrita é a melhor forma de se comunicar a alteração para
os demais membros do grupo e para você mesmo. Essas mensagens também
aparecerão no `git log` do projeto,por isso é essencial que sejam bem
escritas, de forma clara e sigam um padrão.
Algumas **regras de ouro**, que são convenções gerais, para que um
projeto versionado com Git seja bem sucedido são:
- **Faça commits regularmente**: isso faz com que as mudanças de
código entre um commit e outro sejam menores, tornando mais fácil
para todos acompanhar as alterações;
- **Não faça commits de trabalhos pela metade**: faça um commit apenas
quando tiver finalizado o que estava propondo. Isso irá forçar você
a deixar o trabalho em pedaços menores, e por consequência realizar
commits regularmente;
- **Teste antes de fazer um commit**: resista à tentação de fazer um
commit que você pensa que está completo. Teste toda a sua realização
para ter certeza de que não causará um efeito colateral no projeto;
- **Escreva boas mensagens de commit**: seja claro e objetivo ao
escrever as mensagens de commit. No entanto, tome cuidado para não
ser vago, ou escrever apenas `mudança`, `mais mudanças`, etc. Se uma
mensagem curta for suficiente, use `git commit -m 'Mensagem'`, mas
lembre-se de ser informativo sobre a alteração realizada, para ser
útil para todos do projeto.
Existem outras convenções estabelecidas sobre como escrever mensagens de
commit contextualizadas, baseadas nas mensagens geradas por mensagens de
funções do próprio Git. Estas convenções podem resumidas nas 7 regras
que são convenções globais:
1. **Separe o título do corpo do texto com uma linha em branco**: por
padrão, a primeira linha é o título do commit, e deve ser uma
mensagem curta. Ao deixar uma linha em branco, é permitido
escrever uma mensagem de qualquer tamanho, detalhando melhor as
modificações feitas. Dessa forma, quando `git log` for executado,
toda a mensagem de commit aparecerá, enquanto que `git log
--oneline` mostrará apenas o título do commit.
2. **Limite a linha de título em 50 caracteres**: isso faz com que o
colaborador pense mais para escrever uma mensagem mais informativa.
Se a mensagem for uma única linha (`git commit -m`), então esse
limite pode se estender para 72 caracteres.
3. **Capitalize a mensagem**: em todas as mensagens de commit comece
com letra maiúscula, tanto se for título, corpo da mensagem, ou
apenas uma mensagem de uma única linha.
4. **Não termine os commits com ponto**: principalmente se for o
título de uma mensagem de commit mais longa. Espaço é valioso
quando dispomos apenas de 50 ou 72 caracteres.
5. **Use o modo imperativo**: no título de commits longos ou em
mensagens de commits únicas. O modo imperativo significa escrever
como se estivesse dando um comando a alguém. Seja direto e
objetivo, e escreva no presente. Exemplos de mensagens no
imperativo:
- Adiciona versão final
- Altera parágrafo da introdução
- Remove funções precipitadas
Algumas mensagens no modo **não** imperativo são:
- Corrigindo o erro
- Mudando a função
- Mais correções para mais funções
6. **Limite o corpo da mensagem em 72 caracteres**: ao escrever uma
mensagem de commit mais longa, devemos manter o corpo da mensagem
com no máximo 72 caracteres.
7. **Use o corpo da mensagem para explicar "o que" e "porque", e não
"como"**: contextualize o que você fez e o motivo. Na maioria dos
casos você pode deixar de fora como você fez as modificações, pois
o código alterado será auto-explicativo.
# Modelos de fluxos de trabalho #
A escolha do *workflow* (fluxo de trabalho) depende de cada projeto e
das preferências pessoais. Podemos utilizar as informações sobre cada
*workflow*, e decidir qual é mais adequado para cada projeto. Existem
quatro maneiras principais de trabalhar em colaboração com o Git e o
GitLab:
## Centralized workflow ##
Recomendado para projetos pequenos, e/ou que não necessitam de muitas
alterações. Nesse workflow, o repositório possui apenas um branch
(`master`) e as alterações são feitas nesse branch. As revisões só
poderão ser realizadas depois que tudo foi enviado para o servidor
remoto. Com isso, há uma grande chance de ocorrerem conflitos.
**Exemplo**
Após iniciar um repositório central, os colaboradores devem clonar o
repositório.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-central-1.png}
\end{center}
\caption{Colaboradores clonando o repositório central.}
\end{wrapfigure}
Depois de um colaborador terminar seu trabalho remotamente, ele publica
as modificações para o repositório central, para que os demais membros
possam ter acesso.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-central-2.png}
\end{center}
\caption{Colaborador publicando as modificações no repositório
central.}
\end{wrapfigure}
Outro membro também termina seu trabalho e resolve publicar no
repositório central, porém não conseguirá. O repositório central está
diferente do seu repositório local.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-central-3.png}
\end{center}
\caption{Colaborador não conseguindo publicar as modificações no
repositório central.}
\end{wrapfigure}
Para conseguir enviar as modificações realizadas, o colaborador precisa
puxar as atualizações feitas para o seu repositório, integrá-los com as
suas alterações locais, e em seguida, tentar novamente.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-central-4.png}
\end{center}
\caption{Colaborador puxando as modificações do repositório central.}
\end{wrapfigure}
Após feito isso, será possível o colaborador fazer as modificações.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-central-5.png}
\end{center}
\caption{Colaborador publica modificações do repositório central.}
\end{wrapfigure}
## Feature branch workflow ##
Recomendado para projetos pequenos e grandes, que envolvam mais de um
colaborador. O projeto principal é mantido no branch master. Se um
membro quiser realizar alguma alteração, deverá criar um novo branch
`feature`, e fazer as alterações nesse branch e sugerir um `merge
request`. Com isso, os demais colaboradores poderão revisar as
alterações sugeridas e discutir as modificações, até que uma pessoa
habilitada faça o merge desse branch `freature` para o branch `master`.
Dessa forma, evita-se os possíveis conflitos e garante que tais
alterações não causaram algum problema. Esse workflow é altamente
recomendado por ser simples de gerenciar, evitar grandes conflitos, e
ser relativamente fácil para usuários novos do Git.
**Exemplo**
Antes de começar a desenvolver um recurso, é preciso criar um ramo
isolado para trabalhar.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-feature-1.png}
\end{center}
\caption{Criando um novo ramo para o trabalho.}
\end{wrapfigure}
Com isso, o membro poderá iniciar o seu trabalho, e realizar o que for
necessário nesse ramo (branch). O colaborador, após finalizar o projeto,
irá requirir um `merge request` para que as alterações feitas nesse
branch, sejam incorporadas no `master`. Os demais membros, poderão
avaliar se tais modificações são pertinentes para o projeto.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-feature-2.png}
\end{center}
\caption{Colaborador solicita merge, e aguarda revisão dos
colaboradores.}
\end{wrapfigure}
Quando as alterações sugeridas para o colaborador forem incorporadas o
branch poderá ser movido para o `master`.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=3cm]{./images/traba-feature-3.png}
\end{center}
\caption{Movendo ramo para o master.}
\end{wrapfigure}
## Gitflow workflow ##
Indicado para projetos maiores e/ou com um grande número de
colaboradores. Esse workflow envolve a criação de alguns branches com
funções específicas. Todo o desenvolvimento é realizado no branch
`develop`. Quando uma versão está pronta, ela é movida para o branch
`release`, onde é testada e finalmente incorporada ao ramo master, que
contém apenas versões finais (estáveis). É extremamente recomendado esse
workflow para desenvolvimento de softwares, porém exige de mais
familiaridade com o Git. Permite, por exemplo, que os usuários de um
software, instalem tanto uma versão estável (do branch `master`) quanto
uma versão em desenvolvimento (do branch `develop`).
**Exemplo**
São criados branches com funções específicas, como no exemplo `Hotfix`,
`Release` e `Develop`.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=5.5cm]{./images/traba-git-1.png}
\end{center}
\caption{Ilustração dos branches específicos.}
\end{wrapfigure}
*Develop* é semelhante ao master do feature branch workflow. *Release*
serve para "lançar" possíveis bugs gerados no código. *Hotfix* contém as
correções dos bugs do release que não podem aguardar o lançamento do
mesmo.
## Forking workflow ##
Recomendado para projetos abertos, onde se espera que usuários externos
façam contribuições. Esse workflow consiste em um repositório oficial,
de onde os colaboradores fazem um `fork` desse repositório, e passam a
desenvolver o projeto de maneira independente. Assim, cada colaborador
poderá adotar o workflow de preferência, e não precisará ter acesso ao
repositório oficial, apenas colaborar enviando `merge`.
**Exemplo**
Criado o repositório central, os colaboradores fazem um `fork`poderão
trabalhar de maneira independente.
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=5cm]{./images/traba-forking-1.png}
\end{center}
\caption{Ilustração dos forks de um projeto.}
\end{wrapfigure}
Independente da escolha do workflow para cada projeto é importante
sempre informar o método que está sendo utilizado para seus
colaboradores, para que eles possam seguir o mesmo padrão.
Essas informações poderão ser descritas em `README.md` ou no
`CONTRIBUTING.md`.
# Fluxo de trabalho PET no GitLab #
O PET-Estatística UFPR possui um grupo no Git para o desenvolvimento de
projetos. Utilizaremos a seguinte ilustração para entender o fluxo do
trabalho do PET.
\newpage
\begin{wrapfigure}{r}{0.4\textwidth}
\begin{center}
\includegraphics[width=5cm]{./images/workflowpet.png}
\end{center}
\caption{Ilustração do fluxo de trabalho do PET.}
\end{wrapfigure}
Conforme a demanda de projetos, é criado o repositório para armazená-lo.
Após isso, são criados as `milestones` - marcadores de classificação dos
arquivos. Esses passos são feitos no `Owner`.
Indo para o `master`, temos os seguintes passos:
- Conforme a demanda do projeto, é criado um `issue` para adição de
contribuições;
- Atualiza o ramo `devel`;
- Após isso, é necessário criar um `branch` (ramo) para incluir as
contribuições;
Entrando no `developer`, teremos o ciclo de trabalho em que adiciona as
modificações (`git add`), registra as mesmas (`git commit`) e após
realizar todo o trabalho, é feito o `git push` enviando ao servidor
remoto.
A próxima etapa é a requisição de `merge`. Com esse `merge`, é feita as
discussões a respeito da contribuição, assim podendo retornar ao ciclo
do `developer` para as devidas correções e sugestões. Após a certeza
dessa contribuição, é movida para o ramo `devel` e fechado o `issue`
referente ao trabalho feito.
Depois de terminar todas etapas do projeto, completa-se as `milestones`,
realiza o `merge` do `devel` no `master`, e cria a tag de versão.
cap08/cap08_cs.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Cheat Sheet"
output: html_document
---
### Iniciando um Git
#### $ git init
Configura o diretório atual para um projeto Git
#### $ git config --global user.name "Seu nome"
Configura o nome que será visualizado nos commit
#### $ git config --global user.email "Seu email"
Configura o e-mail que será associado ao seu nome
#### $ git clone git://github.com/usuario/projeto.git
Clona um projeto Git já existente
### Atividades Locais
#### $ git status
Informa a situação do projeto
#### $ git add [arquivo]
Adiciona o arquivo a receber commit
#### $ git stage [arquivo]
O mesmo que git add
#### $ git commit - m "mensagem"
Grava a cópia atual dos arquivos no histórico de versão
#### $ git log
Lista o histórico de versão do branch atual
#### $ git log --follow [arquivo]
Lista o histórico de versão de um arquivo específico
#### $ git diff [branch 1] [branch 2]
Mostra a diferença entre dois branchs
#### $ git blame [arquivo]
Mostra quem editou cada linha de um arquivo específico
#### $ git show
Mostra as mudanças do último commit ou do especificado
#### $ git rm
Renomeia um arquivo sem perder o histórico
#### $ git mv
Move um arquivo sem perder o histórico
#### $ git ls-files
Lista todos os arquivos do branch atual
### Atividades Remotas
#### $ git pull
Copia as atualizações do servidor remoto para o local
#### $ git push
Copia as atualizações do computador local para o servidor
#### $ git remote [operação]
Executa as operações no servidor
#### $ git fetch
Atualiza as referências remotas
#### $ git ls-remote
Lista as referências remotas
### Branch (ramificação)
#### $ git branch
Lista todos os branchs no repositório local
#### $ git branch [novo branch]
Cria um novo branchs no repositório local
#### $ git checkout [branch]
Muda de branch
### Merge (mesclar arquivos)
#### $ git merge [branch]
Mescla o branch especificado ao atual
### Comandos Avançado
#### $ git stash
Armazena temporariamente as modificações dos arquivos
#### $ git rebase
Permite modificar todo o histórico dos commits
#### $ git reset
Desfaz todos os commit a partir do commit especificado
#### $ git revert
Reverte para um commit especificado
#### $ git submodule
Cria, atualiza ou inspeciona um submódulo (sub branch)
cap08/cap08_dt.Rmd 0 → 100644
View file @ ba5e4e29
This diff is collapsed.
cap08/cap08_er.Rnw 0 → 100644
View file @ ba5e4e29
This diff is collapsed.
cap09.Rmd 0 → 100644
View file @ ba5e4e29
---
title: "Rstudio"
output: html_document
---
Introdução
Interface overview
Configurações iniciais
sshkey
config
Criando Projeto
Clone
Novo git
Interface
Commit
Pull
Push
Branch
Problemas Comuns
git_tuto.md deleted 100644 → 0
View file @ 990726f9
This diff is collapsed.
images/GitMug.svg 0 → 100644
View file @ ba5e4e29
This diff is collapsed.
images/apostila_capa.pdf 0 → 100644
View file @ ba5e4e29
File added