Bases de dados de projectos: Git. Compromisso. Puxar. Puxar e mais

Março 10, 2020 6 Tempo de leitura

Num post de blog anterior, introduzimo-lo ao Git (um sistema de controlo de versões) e ao Github (um serviço de alojamento baseado na nuvem) e como pode partilhar o seu código 4D com outros programadores. Neste post do blog, vamos um pouco mais longe, explorando alguns cenários que um programador pode encontrar, tais como clonagem de um repositório remoto, ignorando ficheiros já comprometidos, e resolução de conflitos de fusão.

Pré-requisitos

Antes de prosseguir, assumimos que sabe como criar uma base de dados de projectos ou converter uma base de dados binária num projecto. Ter Git instalado na sua máquina e uma conta no Github são obrigatórios. Se ainda não os tem, consulte este post no blogue para saber como proceder.

Clonar um repositório remoto

Chegou o momento de retomar o trabalho na nossa candidatura. Mas por alguma razão, não tem o projecto em que trabalhámos da última vez na sua máquina. O que fazer?

Uma vez que criámos um repositório no GitHub(post anterior no blog), ele existe como um repositório remoto. Agora precisamos de criar uma cópia local na nossa máquina e sincronizar entre os dois locais. Como proceder?

Ligue-se à sua conta no Github,
Navegue até à página principal do repositório,
Clique no botão“Clonar ou descarregar“, depois clique no ícone da prancheta (como mostrado na imagem abaixo):
Abra um terminal e indique o local onde pretende clonar o directório
Digite o clone do git e cole o URL que copiou no passo 3.

Parabéns! Criou uma cópia local na sua máquina.

gitignore

Não quero que o git rastreie um ficheiro ou pasta em particular

Por vezes, temos ficheiros ou directórios no nosso projecto que não queremos que sejam rastreados. É aí que um ficheiro .gitignore vem a calhar. Como o nome indica, indica a Git quais os ficheiros, directórios, ou padrões a ignorar no repositório.

No nosso caso, queremos que Git ignore a pasta Data (que contém o diário, preferências, .4dd, e a pasta DerivedData ).

Criar .gitignore

Configuração de ficheiros/pastas ignorados

.gitignore utiliza padrões de globbing para comparar nomes de ficheiros. Pode construir os seus padrões usando vários símbolos. Por exemplo, para ignorar uma pasta, anexamos uma barra no final do nome da pasta. Pode consultar este artigo para saber mais sobre padrões .gitignore.

Ignorar ficheiros que já tenham sido submetidos ao repositório

Tenha em mente que quando criar um novo repositório, deve também criar um ficheiro .gitignore para qualquer padrão de ficheiro que queira ignorar. No entanto, há alturas em que os ficheiros escapam que mais tarde queres ignorar.

Não entre em pânico! Em apenas alguns passos simples, podes limpar o teu repositório e certificares-te de que estes itens são ignorados:

Ficheiros de palco para remoção, mas deixe-os localmente: git rm -r –cached
Inspeccionar todo o directório de trabalho à procura de ficheiros novos, apagados ou modificados e adicioná-los ao índice: git add
Enviar os ficheiros na área de encenação para o repositório local: git commit -m “Clean up ignored files” (Limpar ficheiros ignorados)
Enviar as alterações para o repositório remoto: git push

Voilà! Pode verificar no repositório remoto e que os ficheiros não estão lá!

Nota importante: Os ficheiros ignorados permanecem no histórico do repositório. É por isso que ao criar novos repositórios, deve também criar ficheiros .gitignore indicando todos os ficheiros, pastas, ou padrões que quer ignorar. Caso contrário, se não quiser que certos ficheiros permaneçam no histórico, terá de apagar o repositório do Github e empurrá-lo novamente.

Como resolver conflitos de fusão

Antes de mais nada, STAY CALM!

Quando vários criadores trabalham dentro do mesmo sistema de controlo de versões, a gestão de eventuais conflitos torna-se uma tarefa diária. Há várias opções disponíveis. O conflito pode ser facilmente resolvido usando o editor 4D, mas como todos os ficheiros são agora baseados em texto, também se poderia usar um editor de texto para resolver manualmente os conflitos. Além disso, há muitas ferramentas de fusão disponíveis que podem ser integradas no GIT. No exemplo abaixo, estamos a utilizar o editor 4D para resolver os conflitos.

Vamos analisar um conflito usando um método 4D. Para o fazer, é necessário simular um repositório secundário utilizador / local de git, duplicando a pasta da base de dados e certificando-nos de que tem pelo menos um método de projecto. Agora há duas pastas de base de dados: my4DApplication e my4DApplication2. A seguir, abrir ambas as aplicações.

1. Abrir o método de projecto na primeira aplicação, e adicionar algum conteúdo (um comentário, por exemplo).
2. Se executar o estado de idiota, serão detectadas alterações no método. Comprometa e empurre as novas alterações.
3. Cenário: outra pessoa modifica o mesmo método, ao mesmo tempo . Vamos simular isto, abrindo o mesmo método na segunda aplicação e modificando-o com um comentário diferente.
4. Comprometer e empurrar as novas alterações. Como se pode ver, o empurrão é rejeitado e em vez disso sugere-se um puxão:
5. Executar o puxão sugerido não está a ajudar:

E agora?

Abrir o método com o conflito. A linha com a cabeça indica alterações locais e a linha a vermelho indica o número do compromisso feito pelo outro utilizador.

Resolver o conflito é fácil, basta seleccionar as partes correctas do código e pressionar as alterações. Neste caso, guardo ambas as mensagens ALERT com comentários diferentes:

Uma vez feito isto, o outro utilizador pode executar o git pull para obter as novas alterações. Ambos os utilizadores têm agora o mesmo conteúdo no método.

Para evitar conflitos em primeiro lugar

Não há uma forma segura de evitar conflitos a toda a hora, mas correr o git fetch pode poupar-lhe uma carga de dores de cabeça de fusão. Ele verifica se o repositório remoto tem novos commits. Não o fazer antes de tentar empurrar causou o erro [Rejeitado].

Para Concluir

Neste post, discutimos diferentes cenários que um programador é susceptível de encontrar quando trabalha com Git. Num próximo post, iremos afastar-nos da linha de comando e mostrar-lhe como utilizar um cliente GUI para trabalhar com Git.