Histórico da Página
Precisa de ajuda?
Livesearch | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Section | ||
---|---|---|
|
...
|
...
|
...
| ||||||||||||
Aviso | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Deck of Cards | ||||||||||||
| ||||||||||||
Card | ||||||||||||
| ||||||||||||
Deck of Cards | ||||||||||||
| ||||||||||||
Card | ||||||||||||
|
Aviso |
---|
A branch Master sempre reflete o que está na produção do cliente, ou seja, se houver um commit de artefatos nesta branch, automaticamente entenderemos que precisamos promovê-las para a PRODUÇÃO. Portanto, utilize com muita "sabedoria" esta branch. A branch Hotfix será gerada todas as vezes que forem encontrados erros críticos em produção. Sempre que ocorrer a criação desta branch, devemos "mergear" as correções na branch Master e na branch Develop sempre que concluir o desenvolvimento. Se esquecer de realizar este merge, você poderá perder as personalizações em produção ou em desenvolvimento. A Develop é a branch que contém todos os novos desenvolvimentos solicitados pelo cliente. Todos os commits realizadas nesta branch, serão promovidas para o ambiente de Develop do cliente, podendo assim, ser homologado pelo cliente. As Features são branchs locais de desenvolvimento para que o Dev possa construir seus códigos e testar em tempo de desenvolvimento, sem a necessidade de concorrência com outros Devs. Estas features geraram um ambiente espelho da produção para homologação do desenvolvedor. Atualmente, temos disponíveis até 5 features branchs dentro do ambiente do cliente. |
id | C01 |
---|---|
label | Instalando o GIT |
Instalação
O Git pode ser instalado tanto via linha de comando como por meio de download, para obter o Git em sua máquina confira o passo a passo neste link: https://git-scm.com/book/pt-br/v1/Primeiros-passos-Instalando-Git
Configurando o usuário Git
Nesta etapa vamos configurar o nome de usuário e e-mail que o Git irá utilizar sempre que realizarmos uma alteração em um arquivo de código fonte, estes dados serão importantes no futuro, pois dentro do processo de submeter um código fonte para aprovação e aplicação em um ambiente, o responsável por esta avaliação irá checar estas informações.
Para concluir esta etapa de configuração, basta executar dois comandos cujo objetivo é informar ao Git qual o nome de usuário da pessoa que está utilizando a ferramenta e qual seu e-mail.
Os comandos devem ser executados em um terminal, caso você esteja utilizando Windows, ao instalar o Git será instalado uma ferramenta de terminal chamada Git Bash.
- Para abrir o Git Bash, execute o Windows Explorer.
- Acesse uma pasta de sua preferência, clique com o botão direito e escolha a opção Git Bash Here.
Com o terminal Git aberto, digite:
Bloco de código |
---|
$ git config --global user.name "Seu usuário"
$ git config --global user.email "Seu e-mail" |
Estas configurações ficam alocadas no arquivo ~/.gitconfig, onde: o ~ é o diretório home.
No Windows, ficam em c:\Usuarios\<username>\.gitconfig.
id | C02 |
---|---|
label | Iniciando um projeto |
Baixando um Repositório
Após configurar seu usuário e e-mail podermos baixar uma cópia local do repositório no qual iremos trabalha.
O primeiro passo será obter suas credências e a URL para obtenção dos arquivos.
Todos os Repositórios para customização do SmartERP Protheus são protegidos e sua cópia somente pode ocorrer mediante ao usuário possuir um par de chaves (credencial + senha) que serão utilizados sempre que desejar realizar enviar suas alterações para o servidor.
Atenção!
Não distribua seu par de chaves, caso perca ou suspeite que a segurança foi comprometida, solicite um novo par imediatamente.
Em posse de seu par de chaves e da url utilize o comando git clone:
Bloco de código |
---|
git clone git.totvs.com/v1/repos/smartprotheus-XXXXXXX-repository |
(Este link você poderá coletar diretamente em seu painel de serviços TCLOUD)
Ao executar o git clone, o projeto é "baixado" para a máquina e uma pasta com o nome do projeto é criada.
Comandos iniciais do Git
Com o repositório na máquina, verificaremos quatro comandos iniciais importantíssimos:
Bloco de código |
---|
$ git add <arquivos...> |
Este comando adiciona o(s) arquivo(s) em um lugar que chamamos de INDEX, que funciona como uma área do Git, no qual os arquivos possam ser enviados ao Repositório ERP. É importante saber que ADD não está adicionando um arquivo novo ao repositório, mas sim dizendo que o arquivo (novo ou não) está sendo preparado para entrar na próxima revisão do repositório.
Bloco de código |
---|
$ git commit -m "comentário qualquer" |
Este comando realiza o que chamamos de commit, que significa pegar todos os arquivos que foram adicionados pelo comando add, no INDEX e criar uma revisão com um número e um comentário, que será vista por todos.
Bloco de código |
---|
$ git push |
Push (empurrar) é usado para publicar todos os commits para o repositório ERP. Neste momento, é solicitada a pedido a senha.Push (empurrar) é usado para publicar todos os commits para o repositório ERP. Neste momento, é solicitada a pedido a senha.
Bloco de código |
---|
$ git status |
Exibe o status do repositório atual.
Errei a mensagem do commit, como conserto?
Imagine que você tenha errado a mensagem que escreveu no commit ou simplesmente queira melhorar a descrição do seu trabalho.
Se você já "comitou" a mensagem, mas ainda não fez o "push" das suas modificações para o servidor, pode usar a flag --amend:
Bloco de código |
---|
$ git commit --amend |
O git commit --amend modifica a mensagem do commit mais recente, ou seja, o último commit.
Além de mudar a mensagem do commit, também é possível adicionar ou retirar arquivos.
O git cria um commit totalmente novo e corrigido.
Card | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Trabalhando com branchesNo Git, o conceito de branch é muito simples e fácil de usar. Quando é necessário criar uma branch? Imagine que o código esteja pronto, tudo funcionando perfeitamente, mas surge a necessidade de alterar algumas partes dele como forma de melhorá-lo. Além disso, é necessário manter estas alterações tanto no computador pessoal quanto do trabalho. Por exemplo: Se você começa a alterar os arquivos em casa, pára na metade da implementação e precisa terminar no trabalho, como você iria "comitar" tudo pela metade e deixar as personalizações incompletas? Para isso existe o conceito de branch, que é justamente ramificar o seu projeto em dois, como se cada um deles fosse um repositório, e depois juntá-lo novamente. Em projetos que usam Git, é possível ter branches locais, presentes apenas na máquina do programador e branches remotas, que apontam para outras máquinas. Por padrão, a branch principal é chamada master, tanto no repositório local quanto no remoto. Idealmente, a master é uma branch estável, isto é, o código nessa branch estará testado e pronto para ser entregue. Para listar as branches existentes no repositório Git, basta executar:
Criando uma branchUma prática comum é ter no repositório, branches novas para o desenvolvimento de funcionalidades que ainda estão em andamento, contendo os commits do que já foi feito até então. Para criar uma branch nova, de nome especifico a partir do último commit da master, execute:
Ao criar uma nova branch, ainda não estamos automaticamente nela. Para selecioná-la, execute:
Criando e selecionando uma branchÉ possível criar e selecionar uma branch com apenas um comando:
Para visualizar o histórico de commits de todas as branches, execute:
Para uma representação gráfica baseada em texto do histórico, há a opção:
|
Card | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
Juntando commits de outra branchComo liberar as melhorias e novas funcionalidades? É preciso mesclar o código de uma branch com a branch master. Em geral, os sistemas de controle de versão têm um comando chamado merge, que permite fazer a junção de uma branch em outra, de maneira automática. Vamos dizer que temos o seguinte cenário: a master tem os commits A e B. Então:
Se estivermos na branch master, podemos fazer o merge das alterações que estão na branch especifica da seguinte maneira:
Ao realizar o merge, as alterações da branch especifica são colocadas na branch master e é criado um commit M, apenas para o merge. O git,até mesmo abre um editor de texto para que seja possível definir a mensagem desse commit de merge. Os comandos git log --graph ou gitk exibem o gráfico de commits da master:
Para normalizarmos os nomes das branches, convencionaremos a utilização da seguinte sintaxe:
|
id | C05 |
---|---|
label | Aplicando na prática |
Processo de Inovação no ambiente SmartERP
Para iniciar um processo de personalização dentro do ambiente do cliente, deve-se primeiramente, criar uma referência do projeto do cliente na máquina local do desenvolvedor. Para isto, clona-se o repositório com o seguinte comando:
Bloco de código |
---|
$ git clone https://repositorio_do_cliente.totvs.com.br (este link será fornecido pelo cliente no início do projeto) |
Após, será solicitado o usuário e senha do repositório, que devem ser fornecidos pelo cliente.
Feita a clonagem do repositório do cliente, deve-se criar uma nova branch de trabalho, para isto devemos utilizar os seguintes comandos:
Bloco de código |
---|
$ git checkout -b feature/minha-inovacao |
O nome da branch deve seguir o conceito do projeto que será executado dentro do cliente. Recomendamos separar o projeto por frente de trabalho, em ciclos pequenos de desenvolvimento. Desta forma, a promoção das personalizações fica mais simples.
A partir deste ponto, o desenvolvedor irá codificar as personalizações solicitadas pelo cliente em máquina local.
Como o desenvolvimento poderá demorar, é recomendável que de tempos em tempos seja feita a gravação dos dados dentro da branch criada, pois assim, garantimos que não ocorram inconvenientes como perda de informações e/ou retrabalho.
Para isto, utilizamos os seguintes comandos:
Bloco de código |
---|
$ git add --all
$ git commit -m "Descricao da alteracao"
$ git push origin feature/minha-inovacao |
Estes comandos servem para "empurrar os artefatos para dentro da branch" e, com isto, o robô de análise de código entrará em ação para avisar sobre qualquer ocorrência fora do padrão de desenvolvimento TOTVS.
Neste momento, provisionaremos um ambiente de desenvolvimento para a branch criada, para que o desenvolvedor realize a homologação das personalizações realizadas.
Ao término do processo de desenvolvimento, o desenvolvedor deverá "empurrar os artefatos gravados dentro da branch" para a MASTER. Este processo chama-se pull request.
Acesse a página do repositório e pressione o botão New pull request, ao lado esquerdo da página.
É possível modificar a branch na próxima tela. Em qualquer site, selecione o repositório, no menu suspenso, e a branch apropriados.
Depois de ter escolhido, por exemplo, a branch master do repositório original, no lado esquerdo, e a nova branch, do fork no lado direito, aparecerá a seguinte uma tela:
O repositório vai alertar de que é possível mesclar as duas branches, porque não há código concorrente. Adicione um título, um comentário e, em seguida, pressione o botão Create pull request.
Neste ponto, os mantenedores do repositório original decidirão se aceitam ou não o pull request. Eles podem solicitar que você edite ou revise o código antes de aceitar o pull request.
Conclusão do desenvolvimento
Ao término do processo, um pull request deve ter sido criado, para o repositório do cliente.
Depois disso, certifique-se de atualizar e fazer um rebase do código, enquanto espera que ele seja revisado.
O robô de qualidade e/ou o responsável pelo projeto poderá pedir que você refaça o código. Então, esteja preparado!
id | 03 |
---|---|
label | Personalizando seu dicionário de dados |
id | 04 |
---|---|
label | Promovendo as alterações para o seu ambiente |
- Tire as suas dúvidas acessando às FAQs do produto.
...
|
...
HTML |
---|
<script> function linksToBlank(){ var links = document.getElementsByTagName("a"); var l = 0; for (var i = 0, l = links.length; i < l; i++) { links[i].target = "_blank"; } } window.onload = linksToBlank; </script> |