6-git.tex
7.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
\chapter{Git}
\label{cap:git}
\section{O que é Git?}
O Git é uma ferramenta de controle de versão, assim como Subversion (SVN), Bazaar, Mercurial, entre outros. Essas ferramentas são utilizadas para registrar mudanças realizadas nos artefatos durante o projeto de software (documentos, código, entre outros). É possível também através dessas ferramentas realizar todo o controle das versões desses artefatos podendo até mesmo recuperar as versões anteriores dos arquivos a qualquer momento.
O Git possui suporte a todos os tipos de arquivos (java, php, rb, doc, etc). Usar um sistema de controle de versão, significa compartilhar as mudanças e contribuições realizadas entre um determinado time ou até mesmo pessoas que não se conhecem e descobrir quem foi a última pessoa a realizar a mudança nos arquivos, além disso, possibilitar a visualização das mudanças para todos os membros do time.
A grande vantagem de se utilizar um sistema de controle de versão é que caso você tenha feito alguma alteração não desejado em um arquivo ou no projeto inteiro, pode-se voltar ao passo anterior e recuperar o(s) arquivo(s)/projeto. Além disso, um sistema de controle de versões permite que o time trabalhe simultaneamente no mesmo projeto, sem a necessidade de preocupação caso estejam trabalhando em um mesmo arquivo.
\section{Diferenças entre o Git, SVN e outros}
As ferramentas de controle de versão podem ser divididas em três formas: Centralizada, Distribuída e Local
\textbf{Local} – Consiste em copiar os arquivos para um diretório local, dentro da própria máquina, contendo a última data de modificação. Não possui nenhum controle fazendo com que a pessoa perca o local onde ela guardou os arquivos. Existem algumas ferramentas que buscam realizar o controle sobre os arquivos gerando maior organização durante o controle de versão local. Contudo se duas pessoas quisessem trabalhar em um mesmo módulo de um mesmo projeto, não será possível, já que o arquivo será trabalhado utilizado simultaneamente por duas pessoas.
\textbf{Centralizada} – É baseado na arquitetura do tipo cliente-servidor, ou seja, existe um repositório central (servidor), sendo que a cópia de cada um desses repositórios são feitos para os computadores dos desenvolvedores (clientes). Os artefatos dos softwares são direcionados somente para o servidor, sendo assim, a comunicação do repositório do projeto é feito estritamente para o servidor. Um exemplo de sistema de controle de versão que utiliza esse padrão é o Subversion (SVN).
\textbf{Distribuída} – Utilizada no Git, essa forma é baseada na arquitetura P2P (peer-to-peer). Assim como na arquitetura centralizada, é realizada uma cópia do repositório do servidor para as máquinas de cada desenvolvedor. No entanto, nesse modelo os repositórios dos membros do projeto podem comunicar entre si ou através de um repositório "oficial", que está centralizado. No caso de queda do servidor, o projeto não é paralisado, já que é possível os membros realizarem as interações entre eles. mesmos.
\section{Configurando o Git na máquina}
Para realizar a instalação do git, é necessário ficar atento na plataforma do sistema operacional da máquina que está sendo utilizada. Após identificar o sistema, basta ir no site da página oficial do git (\url{https://git-scm.com/downloads}) e realizar o \textit{download} da versão específica do seu sistema operacional.
Após isso é necessário realizar o procedimento para gerar a chave SSH e realizar a configuração no Gitlab, explicado na seção \ref{sub}.
Logo depois da configuração das chaves SSH na ferramenta gitlab, é necessário configurar alguns parâmetros, para que as contribuições nos códigos sejam apresentadas corretamente na ferramenta gitlab. Para realizar essa configuração, é necessário realizar os seguintes comandos\footnote{No caso de utilização do Linux esses comandos podem ser feitos no próprio terminal, enquanto no Windows, existe uma ferramenta que faz o papel do console} (entre parenteses):
\begin{lstlisting}[caption={Configuração inicial do git}, label=cod:git_config]
git config --global user.name "Seu nome"
git config --global user.email "seuemail@email.com"
\end{lstlisting}
Após realização desses passos, o git já está configurado na sua máquina.
\section{Comandos Básicos do git}
O git possui um fluxo de trabalho, que é ilustrado pela Figura X.
IMAGEM FLUXO DE TRABALHO
\subsection{Init/Clone}
Para começar a trabalhar utilizando o git, pode ser feito de duas maneiras: \textit{(i)} através da criação e um novo projeto e consequentemente um novo repositório ou \textit{(ii)} clonando um repositório já existente.
Para criação de um novo repositório, basta executar o comando abaixo (\ref{cod:git_init}). Quando o comando é executado, ele cria uma pasta oculta chamada ".git", que contém os principais arquivos relacionados para gerenciamento do Git.
\begin{lstlisting}[caption={Iniciando um repositório git}, label=cod:git_init]
git init
\end{lstlisting}
É importante notar que a partir do momento que o projeto é criado na máquina, ele pode ser colocado no Gitlab. Para isso, basta o usuário criar um projeto (explicado na seção \ref{sub:gitlab_projeto}
Clonando um repositório existente
\begin{lstlisting}[caption={Clonando um repositório git já existente}, label=cod:git_clone]
git clone urldoprojeto
\end{lstlisting}
\subsection{Pull}
\begin{lstlisting}[caption={Configuração inicial do git}, label=cod:git_pull]
git pull
\end{lstlisting}
\subsection{Add}
\subsection{Commit}
\subsection{diff/status}
\subsection{Push}
\subsection{Branch}
No caso, o Git possui um sistema rapido de criação de Branches e bem como Merges das Branches, básicamente que é executado pelo comando “git branch nomedobranch” e depois você tem que realizar o “git checkout nomedobranch” e assim poderá realizar o trabalho na sua Branch de desenvolvimento especifica.
\subsection{Rebase}
\subsection{Log}
\subsection{Outros comandos}
\url{https://git-scm.com/docs}
\section{Utilizando conexão https}
O tutorial abaixo é dedicado à alguns casos especiais em que seja necessário efetuar o comando git push via protocolo HTTP. Siga os passos à seguir: (também disponível em: https://softwarepublico.gov.br/gitlab/softwarepublico/softwarepublico/wikis/git-push-http )
\begin{enumerate}
\item Faça login no PSPB
\item Acesse o menu "Código > Perfil"
\item Em sua página do perfil, clique na seção "Password"
\item Clique no link "Forgot your password?", localizado abaixo do campo "Current Password"
\item \textbf{FAÇA LOGOUT!} É importe que o usuário esteja deslogado do PSPB para o próximo passo!
\item Ao acessar do passo 4, o sistema lhe enviou um email com instruções de como criar uma nova senha no Gitlab. É imprescindível que seu endreço de email no PSPB seja válido! Caso o email não se encontre na caixa de mensagens principal, verifique se o mesmo não foi tratado como mensagem de SPAM pelo seu servidor de emails. Clique no link disponibilizado no email (Caso os campos de restauração de senha não apareçam, clique novamente no link do email).
\item Forneça a nova senha, de preferência a mesma usada no PSPB.
\item Fim! Sua senha está gravada no Gitlab, permitindo a submissão de código via HTTPS.
\item Há ainda o problema do certificado digital do portal, obrigando os usuários a 'Aceitarem os riscos' de confiar na conexão acessando via navegador. O mesmo deve ser feito para o git, passando a váriavel de configuração http.sslVerify=false.
\item Exemplo de comando push via HTTP: git -c http.sslVerify=false push http://softwarepublico.gov.br/gitlab/softwarepublico/colab.git Note que username e password serão requisitados. username se refere ao seu nome de usuário do PSPB e password se refere à senha criada no passo 7. Reforçamos que deve-se fornecer a mesma senha usada no PSPB.
\end{enumerate}
\section{Disponibilizando um projeto}