Quem trabalha com Git conhece o incómodo: o código está num repositório, o site está no servidor, e entre os dois há sempre alguém a arrastar ficheiros por FTP e a esquecer-se de um. O cPanel tem uma ferramenta que fecha essa distância.
Chama-se Git Version Control e está na secção Files do painel. Neste servidor o Git instalado é a versão 2.48.2.
|
Isto não é um serviço de alojamento de código. Não substitui o GitHub, o GitLab, o Bitbucket nem o servidor de Git da sua empresa. Não há página para navegar no código, não há pedidos de integração, não há gestão de equipa. O repositório central continua a ser de outra gente; o que esta ferramenta faz é trazer de lá para aqui e publicar.
|
O que a ferramenta faz, em duas partes
| Parte |
O que acontece |
| O repositório |
Cria um repositório dentro da sua conta. Pode ser vazio, para começar do nada, ou clonado de um endereço que lhe dê. Depois de criado, pode pedir-lhe que vá buscar as alterações novas do repositório remoto. |
| A publicação |
Copia ficheiros do repositório para onde o site os lê, seguindo as instruções de um ficheiro chamado .cpanel.yml que você põe na raiz do repositório. Sem esse ficheiro, o repositório existe mas não publica nada. |
A divisão é importante: o repositório pode viver numa pasta fora do site, e só o que a publicação copiar é que fica visível na internet. É assim que se quer.
A ordem que funciona
| 1 |
Escolha onde vive o repositório, e não ponha isso dentro da pasta pública do site. Uma pasta ao lado, na pasta pessoal da conta. O porquê está no aviso mais abaixo, e vale a pena lê-lo antes de decidir.
|
|
| 2 |
Clone o repositório remoto, dando o endereço dele. Se o repositório for privado, o servidor precisa de credenciais para lá chegar, e isso não se resolve sozinho: ou o repositório é público, ou trata das chaves de acesso do lado de quem o aloja.
|
|
| 3 |
Escreva o ficheiro .cpanel.yml na raiz do repositório, com as linhas que dizem o que copiar e para onde. É um ficheiro de texto curto, entra no repositório como qualquer outro, e a documentação do cPanel mostra o formato exacto.
|
|
| 4 |
Traga as alterações do repositório remoto para o da conta, sempre que houver novidades.
|
|
| 5 |
Mande publicar, e confira o site. A ferramenta guarda o resultado da última publicação, que é onde se vê se correu bem ou onde parou.
|
|
|
Nunca deixe a pasta .git dentro do que o site serve. Se o repositório ficar dentro da pasta pública, qualquer pessoa pode transferir o histórico inteiro do seu código a partir do navegador, e com ele as palavras-passe que alguém gravou num ficheiro de configuração há dois anos e depois apagou. Apagado do ficheiro, continua no histórico. Se já está assim, tire-o de lá hoje e mude as palavras-passe que estiverem no histórico.
|
O que não deve entrar no repositório
| Não pôr |
Porquê |
| O ficheiro de configuração com a ligação à base de dados |
Traz utilizador e palavra-passe. Fica no histórico para sempre, e acompanha o repositório para toda a gente que o clonar. Guarde-o fora do repositório e deixe-o no servidor. |
| A pasta dos ficheiros enviados pelos visitantes |
Imagens, anexos, documentos. Não são código, crescem sozinhos, e uma publicação que os substitua apaga o que os utilizadores enviaram desde a última vez. |
| A base de dados |
O Git trata de ficheiros. A base de dados copia-se à parte: fazer e guardar a sua própria cópia. |
| Pastas de dependências descarregadas |
São enormes e reconstroem-se a partir do ficheiro que as lista. Pô-las no repositório torna cada operação lenta sem ganho nenhum. |
|
Experimente primeiro num sub-domínio. Uma publicação mal escrita copia por cima de ficheiros a sério. Crie um sub-domínio de ensaio (como adicionar outro domínio ou um sub-domínio), aponte lá a primeira publicação, e só depois mude para o site verdadeiro.
|
Quando isto vale a pena, e quando não vale
| Caso |
Vale? |
| Um site feito à mão, ou uma aplicação sua, com mais do que uma pessoa a mexer |
Vale muito. Acaba com o «quem é que substituiu isto» e com os ficheiros esquecidos no caminho. |
| Um WordPress normal, onde o conteúdo se escreve no painel |
Quase nunca. O que muda num WordPress são a base de dados e os ficheiros enviados, e nenhum dos dois é coisa para Git. Aí o caminho são as cópias de segurança e um site de ensaio. |
| Um tema ou plugin seu, feito por si |
Vale. Esse sim é código, e pode viver num repositório só dele. |
| Publicar um site estático gerado no seu computador |
Vale. É dos casos em que a publicação fica mais simples: o repositório traz a pasta pronta e a publicação copia-a. |
Se prefere continuar a enviar ficheiros à mão, nada disto é obrigatório: contas FTP e ligar com o FileZilla e o dia-a-dia no FileZilla continuam a servir.
Para o trabalho de linha de comandos que acompanha um repositório, o painel também tem Terminal, quando a conta o permite.
PRODUTO RECOMENDADO Alojamento de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 600,00 MT/mês Ver planos |
Português
English
