O Git (site oficial) é um sistema de controle de versão (em inglês: version control system - VCS) distribuído, rápido e escalável, usado principalmente para o controle de versão de software. Criado em 2005 por Linus Torvalds para o desenvolvimento do kernel Linux, logo a plataforma foi adotada por diversos outros projetos. É um software livre, distribuído sob os termos da versão 2 da GNU General Public License.
Essa documentação possui 2 tópicos principais:
Os projetos dos usuários com o plano FREE só podem utilizar o Git interno do Cronapp, não sendo possível exportá-los para repositórios Git externos, como o Github. Além disso, contam com uma versão mais básica dos recursos de versionamento.
A documentação Versionamento (plano FREE) apresenta mais detalhes dos recursos Git para o plano FREE.
O Git pode ser entendido como um serviço de gestão de arquivos definido por um protocolo, possui diversos recursos e dá suporte para que múltiplas pessoas trabalhem ao mesmo tempo no desenvolvimento de um projeto.
O Cronapp possui um terminal Linux onde os comandos Git podem ser executados, porém veremos mais adiante que é possível executar os principais recursos de forma visual. Para abrir o terminal, clique no menu sanduíche, no canto esquerdo da tela, e, em seguida, no ícone destacado na figura 1.1.
Figura 1.1 - Executando comandos Git via terminal
Cada desenvolvedor em um projeto no Git possui um ambiente local totalmente isolado, sendo necessário enviar e obter manualmente as atualizações. Se seu projeto estiver centralizado em um repositório remoto, cada participante deve criar um clone 'local' desse repositório.
Figura 1.2 - Interação entre repositórios
Ao usar o comando git init
dentro do diretório, o git prepara esse local para ser versionado, na prática, o git cria um subdiretório oculto com a estrutura de dados usado pelo git. Mas não se preocupe com isso, qualquer projeto criado no Cronapp já possui essa estrutura de versionamento.
$ git init |
Diferentemente do SVN, em que o comando git commit
envia as alterações para o repositório central, no Git, quem faz essa ação para o repositório de origem é o comando git push
. O git commit
tem a função de salvar localmente o estado atual (snapshot) dos arquivos alterados, dessa forma, é possível criar vários snapshots local antes de enviá-los para o repositório de origem.
O Git não cria uma cópia dos arquivos a cada nova versão, isso causaria uma enorme perda de espaço e lentidão. Ao invés disso, ele rastreia as alterações feitas e mantém o histórico de tudo.
O processo entre um commit e outro possui três estágios: Working Directory, Staging Area e Repository (Figura 1.3).
git
commit
, o Git considera o Working Directory "limpo", ou seja, todos os arquivos estão rastreados (Tracked). Porém, ao adicionar um novo arquivo ou editar um existente, o Git passa a vê-lo como não rastreável (Untracked), isso significa que o arquivo não existia ou não está mais igual snapshot anterior.Staging Area: antes de criar um novo commit, é necessário informar ao Git quais arquivos farão parte desse snapshot, assim podemos usar o comando git status
para ver o conteúdo não rastreado ou modificado e em seguida usar o comando git add <arquivos>
(ou git add *
para adicionar todos) que prepara o conteúdo informado, indexando para a próxima etapa.
git status git add * |
Repository: neste último estágio o Git passa a rastrear todas as alterações dos arquivos informadas no estágio anterior, salvando e criando um histórico local dessas modificações. Essa ação é feita usando o comando git commit
.
$ git commit -m "<mensagem de resumo para o commit>" |
O comando git status
permite visualizar o estado atual de cada arquivo alterado.
Figura 1.3 - Estágios e seus comandos
Por ser um sistema de controle de versão distribuído, o repositório remoto é apenas um link de comunicação entre dois repositórios, onde o seu repositório é o local e o repositório remoto pode estar em outro domínio, normalmente nomeado como origin.
Podemos usar o git clone
para obter uma cópia local de um repositório remoto.
$ git clone <endereço repositório remoto> |
Como podemos ver na figura 1.2, é possível estar conectado a mais de um repositório remoto. Isso permite que você possa ter acesso ao repositório local de um colega e contribuir antes dele enviar para o repositório central.
O comando abaixo adiciona um novo repositório remoto.
$ git remote add <nome> <endereço repositório remoto> |
As ramificações (branchs) permitem "separar" o projeto a partir de um determinado snapshot criando duas linhas do tempo, realizar diversas alterações e posteriormente unir (merge
) o seu conteúdo. Assim, cada desenvolvedor pode trabalhar em um ramo próprio para, por exemplo, corrigir bugs ou criar novas funcionalidades sem impactar o fluxo principal até que o código esteja suficientemente maduro.
O primeiro comando abaixo cria uma ramificação baseada no branch atual, já o segundo, lista todos os branchs locais e remotos.
$ git branch <nome branch> $ git branch -a |
Figura 1.4 - Processo de criação, implementação e mesclagem de uma branch
No Git, o ramo principal é conhecido como master e a partir dele que são geradas novos branchs. É possível trabalhar localmente com vários branchs, alternando entre eles de modo que um não interfira no outro até que será feito o merge. Use o comando abaixo para intercalar entre os branchs.
$ git checkout <nome branch> |
O git merge
faz o processo inverso ao git branch
, ou seja, unifica o conteúdo do ramo informado com o branch atual. Durante esse processo é feito um comparativo (git diff
) para verificar se existem diferenças entre as linhas de códigos, de modo geral essa mesclagem ocorre de forma automática, porém podem ocorrer conflito de conteúdo, onde é necessário ajustar manualmente.
$ git merge <ramo que será mesclado com o branch atual> |
Os dois principais modos de mesclagem usados pelo Git são:
Figura 1.5 - Situações que podem ocorrer durante o merge
O git possui dois comandos para obter novos conteúdos de um repositório:
O git pull
baixa as atualizações e em seguida mescla o conteúdo com o do repositório local automaticamente.
$ git pull <nome do repositório remoto> <nome branch> |
O git fetch
baixa o conteúdo sem mesclar, assim é possível analisar primeiro se as atualizações estão seguras e só em seguida aplicar o merge manualmente.
Abaixo os comandos para baixar e verificar as diferenças entre o conteúdo do branch atual e o baixado:
$ git fetch $ git diff master Origin/master |
Após finalizar e "commitar" uma atividade em seu repositório local, podemos usar o comando git push
para enviar o seu conteúdo para o repositório remoto. Porém, é recomendado que primeiro seja baixado o conteúdo atual do repositório remoto, resolver os possíveis conflito com a sua versão local e só então enviar.
$ git push |
Em seguida o Git solicitará o seu usuário e senha do repositório remoto.
Não é interessante que arquivos compilados, de cache e outros sejam enviados para os repositórios remotos, assim, podemos utilizar o arquivo .gitignore
para informar ao Git o que não deve ser rastreado. Esse arquivo costuma ficar na raiz do projeto, contemplando toda a estrutura do projeto.
Cada linha do .gitignore
especifica um padrão, então podemos configurar padrões como: todos os arquivos de um subdiretório, todos os arquivos com uma determinada extensão, todos os arquivos que iniciam com uma sequência determinada de caracteres e outros.
Para mais detalhes sobre os padrões, acesse a documentação do .gitignore.
Os projetos web e mobile possuem o diretório node_modules
, essa pasta é utilizada pelo Cronapp para armazenar diversas bibliotecas necessárias apenas durante o período de desenvolvimento do seu projeto. Por isso, não recomendamos realizar alterações manuais nesse diretório, pois essas alterações serão sobrescritas nas próximas atualização do Cronapp. Também não recomendamos versionar esse diretório em seu repositório remoto git, afim de melhorar o desempenho ao usar e recompilar o seu projeto e evitar manter conteúdos desnecessários em seu repositório remoto.
Em projetos criados após a versão 2.8 do Cronapp, esse diretório já vem listado no arquivo .gitignore
e qualquer atualização dentro do diretório node_modules
é automaticamente desconsiderada ao realizar as ações de commit e push do git.
Se o seu projeto for versionado, verifique se a pasta node_modules
já está sendo ignorada. Para isso, habilite a opção Modo Avançado, abra o arquivo .gitignore
na raiz do projeto (destaque 1 da figura 1.6) e verifique se possui o termo "node_modules" (2). Caso não possua o termo "node_modules", adicione-o na última linha (2) e salve em seguida (para mais detalhes sobre o gitignore, acesse a sua documentação). Após isso, faça um commit e push do seu projeto.
Figura 1.6 - Ignorando os diretórios node_modules nos projetos mobile e web
Após os passos acima, os diretórios node_modules
do projeto web (Endereço: src/main/webapp/
) e do projeto mobile (Endereço: src/main/mobileapp/www/
) serão exibidos em cinza (destaque 1 da Figura 1.7), informando que não serão mais rastreados pelo git.
Figura 1.7 - Diretório não rastreado pelo git
Caso já tenha enviado esses diretórios para o seu repositório remoto git, recomendamos excluir esses diretórios diretamente por lá.
Uma solicitação Pull é um mecanismo muito utilizadas em ambientes corporativos e normalmente já vem integrado em sistemas com interface, como o Github, GitLab, etc. Ao inicializar uma pull request, é possível indicar equipes ou pessoas para validar o conteúdo a ser mesclado, nesse processo podemos discutir e revisar as possíveis alterações com os colaboradores, adicionando novos commits antes que as alterações sofram merge no branch base.
Requisições Pull normalmente trabalham em conjunto com o GitFlow e geralmente ocorre o seguinte processo:
As tags no Git são utilizadas para referenciar um momento específico na linha do tempo do seu projeto, normalmente estão muito atreladas ao lançamento de versões (v1, v1.1, etc). É uma boa prática utilizar as tags no branch principal para marcar os pontos de versão, isso será muito útil para facilitar o rastreio do que foi lançado, aplicar correções, voltar versões etc. Hoje muitos sistemas utilizam as tags para controlar versões, como por exemplo o node. Acesse a documentação oficial para mais detalhes sobre as Tags.
Utilize o comando abaixo para criar um marcador e informe em "<nome da tag>" um identificador semântico, ex,: "v1.0.4" ou "v1.0.4-rc".
git tag -a <nome da tag> -m "<comentário sobre a versão>" |
O envio do marcador para o repositório remoto é feito a partir do comando:
git push origin <nome da tag> |
Para listar todos os marcadores já criados, use o comando abaixo:
git tag |
É possível consultar a qualquer momento, inclusive em tempo de desenvolvimento, as mudanças geradas no projeto por você ou outros desenvolvedores. O comando git log
possibilita visualizar as mudanças ocorrida em qualquer parte do projeto, contendo observações, datas, versões, histórias de usuários e autores responsáveis pelas alterações.
Abaixo segue alguns exemplos de uso. Acesse a documentação oficial para mais detalhes.
Para listar todos os commits com sua descrição, autor e data.
git log |
Figura 1.8 - Identificando as mudanças do projeto
Para listar as mudanças ocorridas em um arquivo específico.
git --no-pager log --stat -n<número de alterações> -- <endereço do arquivo> |
Figura 1.9 - Identificando as últimas mudanças em um arquivo específico
O Cronapp possui um ambiente preparado para facilitar o uso do Git em seus projetos. Mostraremos como executar os principais comandos Git de forma visual.
Ao abrir um projeto no Cronapp é possível visualizar algumas informações sobre o seu versionamento: o nome do branch ativo é exibido ao lado do nome do projeto na raiz de arquivos (destaque 2 da figura 2.1), a quantidade de versões locais não enviadas para o repositório remoto é exibido ao lado do branch (destaque 1 da figura 2.1) e os arquivos não rastreados pelo Git ficam com cores diferenciadas para informar sua situação atual:
Figura 2.1 - Árvore de arquivos e janela para realizar o commit e push ou só commit
Para clonar um projeto de um repositório Git para o Cronapp, crie um novo projeto e, na janela Novo Projeto (Figura 2.2), siga os passos abaixo.
Figura 2.2 - Importar projeto de um repositório Git
Anônimo?: marque essa opção para baixar repositórios públicos sem informar seu usuário e senha. Esses dados poderão ser requisitados ao fazer o push
.
Para exportar um projeto no Cronapp para o Git, é preciso primeiro criar um repositório em um serviço Git, como Github, GitLab, Bitbucket ou outro qualquer. Com o endereço do repositório, basta seguir os passos abaixo.
Ao criar um repositório em serviços de terceiros, normalmente é dada a opção de já incluir o arquivo README.md, que é usado para apresentar informações sobre o projeto. Recomendamos não incluir esse arquivo para evitar conflitos, pois os projetos criados no Cronapp já possuem esse arquivo. |
Figura 2.3 - Exportar projeto para um repositório Git
Ao final, clique em Finalizar. É possível que apareça uma janela de confirmação (Figura 2.4) caso tenha conteúdo, a branch master será sobrescrita. Clique em Sim para continuar e aguarde a mensagem "Operação efetuada com sucesso.".
Figura 2.4 - Janela de confirmação
Após versionar um projeto, todas as ações low-code do Git devem ser feitas através do menu Equipe (figura 2.5).
Figura 2.5 - Lista de ações do menu Equipe
Recursos disponíveis no menu Equipe:
Você encontrará ações reduzidas ao abrir o menu de contexto de um arquivo ou diretório.
Figura 2.5.1 - Menu de contexto de arquivos ou diretórios
As informações do repositório e usuário do Git podem ser visualizadas por meio da janela de Controle de versão (destaque 2 da figura 2.6). Essa janela está disponível a partir do menu do sistema Equipe ou na janela de Configurações do Projeto (destaque 1). Com exceção do campo URL do Repositório, todos os outros campos podem ser atualizados.
Figura 2.6 - Acessando o Controle de versão
Caso as ações merge ou pull apresentem conflito em pelo menos um dos arquivos, uma janela aparecerá informando o problema e os nomes desses arquivos (figura 2.7), será necessário que você resolva esse conflito antes de tentar executar a ação novamente.
Após fechar a mensagem de conflito, os arquivos com problema aparecerão destacados em vermelho, dê um duplo clique para abrir a janela de revisão de conflitos.
Figura 2.7 - Detalhes da janela de revisões dos conflitos
A janela de commit permite adicionar uma mensagem, selecionar os arquivos que serão adicionados na próxima versão e dá a opção para apenas commit ou "commitar" e enviar o conteúdo para o servidor remoto.
Figura 2.8 - Janela usada para criar versões
Ao dar um duplo clique sobre um dos arquivos que já foram rastreados anteriormente pelo Git, é possível abrir a janela de revisão com o conteúdo antigo e o novo. Acesse o tópico sobre a janela de revisão para mais detalhes.
Figura 2.9 - Janela de revisão usada pra analisar as alterações do arquivo
A ação Push with Local Tags será realizada apenas se a tag for criada no repositório local e não tiver sido enviada para o repositório remoto. Essa funcionalidade é útil, por exemplo, ao criar uma tag utilizando o terminal. No entanto, ao utilizar a ferramenta de tags do Cronapp, o push será feito automaticamente.
As tags exibidas na imagem abaixo (Figura 2.10) foram criadas localmente via terminal. Para fazer o push de uma ou mais tags, você deve abrir a janela de Push with Local Tags e selecionar a tag que deseja enviar para o repositório remoto, em seguida clique no botão Push.
Figura 2.10 - Janela de push de tags locais
Para aplicar o merge, você deve estar no branch que deseja atualizar e selecionar o branch que deseja obter o novo conteúdo. Se não houver conflitos, será exibido uma janela com os arquivos atualizados, caso contrário, aparecerá uma janela de erro com os arquivos em conflito. Após clicar em OK, os arquivos em conflito estarão em vermelho, dê um duplo clique para abrir a janela de revisão e resolver o conflito.
Figura 2.11 - Mensagem de conflito durante o merge
A janela Tags exibe a lista de tags do projeto e permite criar ou gerar um branch a partir de uma tag.
Figura 2.12 - Janela com a lista dos branchs
A opção Outros no submenu Trocar Branch abre uma janela onde é possível realizar algumas ações em branchs locais, remotas e até tags.
Figura 2.13 - Janela com a lista dos branchs
Ao selecionar essa opção, uma janela será aberta permitindo definir um nome para o novo branch e algumas ações.
Figura 2.14 - Criando novo ramo
O Github possui uma política de autenticação diferente da maioria dos repositórios Git. Ao invés de utilizar seu usuário e senha do Github para permitir que o Cronapp, ou outra aplicação, acesse seu repositório remoto, agora é necessário autorizar quais aplicativos poderão ter acesso. Após permitir, um token OAuth exclusivo é gerado e o aplicativo terá acesso ao repositório remoto.
Esse procedimento é necessário apenas na primeira vez ou após revogar a autorização do Cronapp. Após isso, todos os projetos que você criar no Cronapp terá a mesma permissão.
Todos os usuários do Cronapp com projetos já criados e versionados no Github precisarão fazer a mudança das credenciais. Para fazer isso, acesse Projeto > Configurações e vá na aba Controle de Versão e siga os passos abaixo. |
Os passos a seguir podem ser executados em todas as janelas de autenticação do Git dentro do Cronapp:
Figura 3.1 - Janela de autenticação do Git ao exportar projeto
Ao informar um endereço com o domínio do "github.com
" no campo URL do Repositório (destaque 1), o Cronapp exibirá o botão Autorizar GitHub (destaque 2). Clicando nele, uma nova aba em seu browser será aberta para logar com sua conta no GitHub (Figura 3.2).
Não é necessário informar os campos Usuário e Senha (destaque 3), esses campos serão preenchidos automaticamente após autorizar o Cronapp no Github. Porém, caso possua um token pessoal, é possível informar seu usuário e token pessoal e, em seguida, Finalizar, sem precisar gerar um token em Autorizar GitHub. |
Figura 3.2 - Logue com sua conta no GitHub
Após logar, você será direcionado para a página onde poderá autorizar o Cronapp. Clique no botão Authorize CronApp (destaque 1 da figura 3.3). Observe que, se você for membro de mais de uma organização, você terá que clicar no botão GRANT de cada uma para permitir manipular/criar repositórios nelas.
Acesse a documentação do Github para mais detalhes sobre autorização de aplicativos OAuth. |
Figura 3.3 - Autorize o Cronapp
Aplicada a autorização, a aba do navegador em que estava aberto o GitHub será fechada e você retornará para a aba do Cronapp. O campo Usuário será automaticamente preenchido com o seu usuário do GitHub e a Senha, com o token gerado (destaque 1 da figura 3.4). Por fim, clique no botão Finalizar.
Figura 3.4 - Os campos Usuário e Senha são preenchidos automaticamente após autorizar o Cronapp em seu GitHub
Se o repositório pertence a uma organização GitHub, será necessário que o administrador dessa organização autorize o Cronapp. Para isso, acesse as configurações da organização no GitHub, clique em Trird-party access (destaque 1 da figura 3.5) e em seguida, clique no ícone de edição da aplicação Cronapp IDE Low Code (2). Na tela seguinte, clique no botão "Grant access" para mudar o status de "Denied" para "Approved".
Uma vez autorizado, os usuários poderão acessar os dados da organização através do Cronapp.
Figura 3.5 - Autorizar o Cronapp dentro da Organização GitHub
Acesse a documentação do GitHub para mais detalhes sobre restrições de acesso aos dados da organização. |
Os passos a seguir mostram como revogar a autorização dada ao Cronapp em seu GitHub.
Logue em sua conta do GitHub e no menu do usuário (destaque 1 da figura 3.6) clique em Settings (2).
Figura 3.6 - Acesso as configurações da sua conta no GitHub
Na próxima tela, clique em Application (destaque 1 da figura 3.7) no menu lateral e depois na aba Authorized OAuth Apps (2). Na lista de aplicativos, clique no ícone "..." (3) do aplicativo "Cronapp IDE Low Code" e depois em Revoke para abrir um pop-up confirmando a ação, por fim, clique no botão I understand, revoke access para revogar a autorização.
Figura 3.7 - Revogando a autorização do Cronapp ao seu GitHub
O Bitbucket mudou a sua política de autenticação via API. Agora, ao invés de utilizar seu usuário e senha do Bitbucket para permitir que o Cronapp, ou outra aplicação, acesse seu repositório remoto, é necessário criar uma senha do aplicativo e definir as restrições dessa senha.
Esse procedimento é necessário apenas na primeira vez ou após revogar a senha criada. Após criar a senha, todos os projetos que você utilizar essa senha terão as mesmas restrições em relação ao repositório (veja mais detalhes na documentação oficial).
Todos os usuários do Cronapp com projetos já criados e versionados no Bitbucket precisarão fazer a mudança das credenciais. Essa atualização pode ser feita na janela de Controle de versão (Figura 4). |
Os passos a seguir são necessários para todas as janelas de autenticação do Git dentro do Cronapp:
Figura 4 - Janela de autenticação do Git ao exportar projeto
Para realizar esse procedimento, é necessário logar com seu usuário e senha da conta no Bitbucket. Após logar, acesse o menu da conta (destaque 1 da figura 4.1) e em seguida clique em Personal settings (destaque 2).
Figura 4.1 - Acesso as configurações do usuário
Na área das configurações pessoais, clique em App passwords (destaque 1 da figura 4.2) e depois no botão Create app password (destaque 2 da figura 4.2).
Figura 4.2 - Acesso a área de criação de novas senhas
Informe um nome para essa senha (destaque 1 da figura 4.3) e as permissões de acesso (2). Ao final, clique no botão Create (3).
Dependendo do nível de restrição que configurar nesta área, alguns recursos podem não ter permissão no Cronapp. |
Figura 4.3 - Configurando as permissões da senha
Após confirmar a criação (destaque 3 da figura 4.3), o Bitbucket irá gerar uma senha com as restrições definidas na sua criação (destaque 1 da figura 4.4).
Anote essa senha com cuidado, pois não será possível visualizá-la novamente. Caso esqueça, será necessário gerar uma nova (veja mais detalhes na documentação oficial). |
Figura 4.4 - App password gerado pelo Bitbucket
Caso queira excluir a senha, basta clicar em Revoke (destaque 2 da figura 4.4). Todos os projetos que possuam essa senha cadastrada perderão o acesso ao repositório.