Tutorial básico do GIT

por **JoséQuintas** » 27 Dez 2020 12:51

Mais um recurso interessante, pensava que já usava, mas não usava direito.

Tenho lá os projetos:

hmg
hmge
hwgui
oohg core
oohg samples
oohg distros
oohg doc
oohg shared
oohg fmt

agora criei um novo, sem nada, só com o gitflow.

em minha máquina
git submodule add hmg
git submodule add hmge
etc.

se tudo der certo, a partir do all gerencia todos, e vai dar pra acertar um gitflow pra compilar tudo de uma vez.
pra hmg criei um independente do original, porque o original tem harbour e mingw, mais de uma versão, e isso deixa o conteúdo pra baixar muito grande.

ao mesmo tempo, eles são independentes, e são juntos, depende de por onde baixar.
Para oohg, que são forks, posso continuar contribuindo com o original.

https://github.com/JoseQuintas/testall

por **JoséQuintas** » 27 Dez 2020 14:33

Estou comprovando tudo que venho falando faz tempo.
Esse testall contém tudo, mas.....
Pra cada projeto vinculado, está se referindo a uma posição exata do projeto.

Agora imaginem isso aplicado pra tudo.
Cada um poderia baixar o Harbour que interessa, as LIBs que interessam, tudo do mesmo lugar, mesmo que cada um baixe versão diferente.

O github faz todo trabalho.
Basta vincular máquina, sistema operacional, pacotes, comandos, etc. e ele já compila/linquedita/zipa e deixa pronto pra download.

E tanto faz se for Harbour ou XHarbour.

Agora só falta fazer a parte de compilar/linqueditar..... por isso juntei tudo num só, pra não precisar configurar cada um.

Só pra lembrar:
Como isso também funciona pra nossos aplicativos.....
Não precisaríamos nem mesmo computador pra compilar/linqueditar....
Só criar a conta particular que é grátis, e pronto, fica pra uso exclusivo.

por **JoséQuintas** » 27 Dez 2020 15:40

Convém deixar anotado:

git submodule add ../hmge hmge

é o path relativo ao "meu" projeto atual, e a pasta relativa de destino.

pra remover;

git submodule deinit hmge

caso não baixe usando o recurso de --recurse (recursivo)

git submodule init hmge

e tem outro interessante --depth 5
Baixa somente o histórico dos últimos 5 commits.

Pra baixar tudo de uma vez, com subprojetos, somente histórico com últimos 5 commits:

git clone endereco --recurse --depth 5

E pra trabalhar/atualizar, continua o de sempre, nada muda.
o projeto geral tá sempre apenas com indicação dos outros, e cada projeto com sua história separada.

Nota: vale para o Harbour também, assim baixa mais rápido. Se não precisar a vida toda desde o Harbour 0.0.... assim é melhor.

por **JoséQuintas** » 27 Dez 2020 19:16

Acrescentei o Harbour 3.4.

Importante:

o testall NÃO TEM NADA, apenas links para os outros projetos.
Só que se baixar recursivo, baixa todos os projetos de uma vez, organizados em pastas.

por **JoséQuintas** » 27 Dez 2020 19:21

d:\github\all>git status

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:   oohg (modified content)

no changes added to commit (use "git add" and/or "git commit -a")

Apenas está informando que está tudo ok no projeto, mas.... o subprojeto oohg contém alterações.

por **JoséQuintas** » 27 Dez 2020 22:03

Ficou meio esquisito, mas deu certo, foi a primeira vez.
Acabou virando 3 versões que se encerraram iguais.

Apesar de tudo, não preciso desse controle detalhado, então talvez faça isso sem salvar a "história do acerto".

linha do tempo 1: anterior + minhas alterações + diferença
linha do tempo 2: anterior + hwgui nova + minhas alterações
linha do tempo 3: anterior atualizada + diferença

Ao contrário do que pensávamos (pelo menos eu), isso não mostra o quanto está diferente, isso apenas mostra quais os "commits"/alterações foram aplicados.

por **JoséQuintas** » 30 Dez 2020 15:48

Mais outro, mas cuidado.
É pra reescrever todo histórico.

git rebase -i HEAD~15

Com esse comando, vai aparecer um arquivo txt pra ser editado, com a lista dos últimos 15 commits.
Todos tem a palavra "pick" que significa manter.
Pode ser alterada para:

drop - excluir
squash - juntar com o anterior
edit - editar
e outras

se limpar tudo, não faz nada.
Se alterar as palavras, é o que vai ser feito.

Por default, é criada uma linha do tempo paralela, que pode ser salva no github, ou com outros comandos, pode assumir o papel principal.
Ainda não me acertei nisso de substituir o histórico, mas pelo menos o resultado foi o que eu queria.

Eliminei todas as alterações que tinha feito pra teste na WVG, foi isso que eu fiz, para o histórico ficar só com a parte "útil".
Só não acertei na hora de salvar no github, então, ficou com as duas linhas do tempo.

Pensando bem.... acertei, porque não apareceram as inclusões/exclusões.
Agora ficou confuso porque mostra duas linhas do tempo, ou a forma em que aparecem.
Excluí 4 alterações, não ficou visível isso, dá a impressão de que excluí 6.

por **JoséQuintas** » 03 Jan 2021 01:04

Estou fazendo o teste agora por curiosidade.

Existe sempre uma origem e a cópia de trabalho.
Se a origem é GITHUB ou SEU SERVIDOR, ou a própria máquina, tanto faz.

No meu servidor:

git clone enderecogithub all

Isso cria uma cópia do github para meu servidor
Meu servidor vai atualizar o github, que é a origem

git clone enderecoMEUservidor all

isso cria uma cópia do meu servidor para minha máquina
Minha máquina vai atualizar MEU SERVIDOR, que é a origem

git clone pastaoriginal pastabackup

Isto vai criar uma cópia da pasta original pra backup.
a pasta backup vai atualizar a pasta original.
No final, o que chamei de backup acabaria sendo a cópia de trabalho.

É só curiosidade, isso poderia só complicar, porque teria que rodar atualização em todos, pra chegar no github.

Mas por outro lado, mostra como criar um servidor próprio, que poderia até atualizar por uma VPN.

NÃO existe software especial no servidor, apenas existe a pasta compartilhada.
Se quiser, pode instalar o git no servidor, pra comunicação entre servidor/github quando precisar, SE usar o github.

Não é complicado entender.

Você tem um lugar que é o salvamento de tudo, é o principal, pode ser com opção de mexer ou não.
Pode ser no github.
Aí pode fazer uma cópia para o seu servidor, seu servidor vai atualizar o github.

Na sua máquina, pode fazer uma cópia do github ou do seu servidor.
Se fizer uma cópia do github..... vai atualizar o github
Se fizer uma cópia do seu servidor... vai atualizar o seu servidor
Aqui, quando digo cópia, é usando git clone ....

O git não precisa do github, você pode criar o controle do zero, no seu servidor ou na sua máquina.
Criando no seu servidor, seu servidor seria seu github particular.

Já como eu mencionei no começo, cópia da cópia da cópia.....
o github é o servidor do seu servidor
seu servidor é o servidor da sua máquina
sua máquina seria o servidor da sua outra pasta

Nesse jeito exagerado, uma pasta sua atualizaria a outra.
A outra atualizaria seu servidor
e seu servidor atualizaria o github
Mas como é tudo manual e não automático, correria o risco de esquecer de algum deles.
Foi só exemplo, pra mostrar com possibilidades expandidas.

por **JoséQuintas** » 13 Jan 2021 20:34

Comentei sobre o recurso de reescrever o histórico.
Está aí uma boa utilidade pra ele.
Não vou querer esse monte de testes no histórico.

por **JoséQuintas** » 13 Jan 2021 20:43

git rebase -i HEAD~50

me abriu a lista pra dizer o que fazer.
pick=mantem
squash=agrupa
drop=apaga

pedi pra agrupar, e aí fecho o editor de textos e ele trabalha

agora me pediu pra escolher o nome do commit, vém tudo, deixo só o que vai ficar.

fechou o editor de textos, pronto.
Até parece que consegui logo de primeira.... rs
Mas é porque com tudo aquilo de histórico, fica uma zona pra encontrar alguma coisa, melhor assim.

confere isso com muita atenção, porque depois não vai ter volta....
o passo final é git push -f
o -f é pra FORÇAR a atualização, senão o github nem deixa salvar, porque não bate com o que ele tem.

por **JoséQuintas** » 07 Fev 2021 14:39

Deixar anotado aqui.
CUIDADO com esses comandos.

É pra reescrever todo histórico, fazendo modificações.

git filter-branch --tree-filter "rm -rf FONTES" --prune-empty

O comando acima é pra remover a pasta FONTES de todo histórico.
Ainda em andamento, vai mais uns 20 minutos até terminar, pra ver se deu certo.

git filter-branch --force --tree-filter "mv FONTES/INTEGRA integra || true"

O comando acima é pra mover a pasta FONTES/INTEGRA pra integra.
O true a mais é para os casos aonde der erro, pra considerar que deu certo mesmo assim.
É que se mover mas não existir dá erro e aborta tudo, com o true continua mesmo se não existir.
Mesmo caso, ainda em andamento, talvez mais 20 minutos pra terminar, pra ver se deu certo.

--tree-filter
--index-filter

Vi que tem essas duas opções, que são interessantes, dependendo do caso.
--index-filter faz pelos "commits", pelo histórico, acaba usando pasta temporária
--tree-filter faz na pasta oficial.

No caso de conflito, aparece lá pra resolver, e fica tudo com o conteúdo "da época".

Conflitos, depende do caso, pra ser fácil resolver ou não.

Tem o rebase que já mencionei antes também, que também pode ter conflitos.

Vamos a alguns casos:

- No manual: você remove uma pasta ou um fonte.
Todas as próximas atualizações que mexeram com essa pasta/esse fonte, vão acusar conflito, porque elas não vão poder mexer no que foi apagado.
Nesse caso é só acrescentar que continua excluído desse commit.
Cuidado ao fazer isso com 3.500 atualizações, porque teria que corrigir um por um, até terminar, caso seja uma pasta muito atualizada.
Para esses casos, o filter-branch será uma melhor opção, porque faria automático com todos.

- sub-projetos
Temporariamente estou removendo isso.
O lado bom é ficar vinculado ao ponto exato do sub-projeto.
O lado ruim, é que ao reescrever histórico, esses pontos não podem ser alterados, o que causa aqueles desvios como uma versão paralela.
Continua tudo bem controlado, mas .... pode causar muita confusão ao olhar histórico.
Isso também acontece com forks... é uma coisa comum, e por isso não pode perder o controle, e precisam existir as "versões paralelas".

A prioridade no git/github é não perder fontes.
As versões paralelas são justamente pra não perder nada, até mesmo se alterar todo histórico e todas as alterações.
É bom lembrar disso, porque às vezes vai parecer que seu histórico está ficando doido, mas é porque na prática é você quem dá a palavra final sobre como manter o histórico após uma alteração: pode manter o controle paralelo ou pode sumir com ele de vez.

Não sei como funciona a cobrança do github num caso desses, pra conta particular, mas parece que o tamanho do controle não importa.
Parece que a cobrança é sobre resultados, e não sobre o projeto, por exemplo gerar e guardar pacotes prontos do projeto (o aplicativo gerado, por exemplo).

Mas fica aí, sobre o que pesquisar: filter-branch
pra quando quiser mudar toda a sua história de fontes/alterações.

por **microvolution** » 07 Fev 2021 16:42

JoséQuintas escreveu:CUIDADO com esses comandos.

nem me atrevo... coisa só pra nerds rsrsrrs

Quem está online