Wanneer is een bepaald bestand in mijn project veranderd?

Ik wil weten wanneer ik de laatste keer het bestand Libraries.txt heb aangepast, omdat ik het niet terugvind in Changes.txt (log van versienummers en veranderingen). Ik ben nu aan versie 0.6.9.

git log -p Libraries.txt

Bovenste deel van het antwoord:

commit 3acf9773661770233e444600....
Author: cybrarian
Date: Fri Feb 21 00:49:20 2025 +0100
'
0.6.2 gridinfo 3j columns
'
diff --git a/Libraries.txt b/Libraries.txt
index e353c0e..e8a4df3 100644
--- a/Libraries.txt
+++ b/Libraries.txt
@@ -1 +1 @@
-myprojectlib 0.6.4
+myprojectlib 0.6.6
.
commit a45dd20dd2bd279017....
Author: cybrarian
Date: Thu Feb 13 19:47:52 2025 +0100
...
...


Het antwoord: bij versie 0.6.2 is de inhoud gewijzigd van 0.6.4 naar 0.6.6.

git checkout HEAD -- naamvanbestand

Als ik op mijn huidige systeem git diff doe, wordt het antwoord getoond in een soort tekstverwerker waarin ik handig kan scrollen, zoeken enz, en die ik verlaat met “q”.
Maar helaas, als ik daarna een andere aktie wil doen, bv een commit waarin ik als commentaar iets schrijf wat ik uit die diff haal, zie ik die niet meer.

Ik wil dus de uitvoer van diff op het scherm houden, bv voor het bestand Changes.txt:

git --no-pager diff Changes.txt

Er is ergens een stomme bug veroorzaakt, waarschijnlijk lang geleden, en de oorzaak is onduidelijk; is het met een aanpassing aan de code gebeurd, of per vergissing door even in de editor in een verkeerd bestand iets te doen bij te snelle toetsaanslagen tijdens het werk?

Hoe kan git mij helpen dat moment terug te vinden?

Log path:

git log --path

bv:
git log -- Trypo/.src/TrypoForms/FDayReq.class

Daarmee kan je al zien wanneer daar de laatste aanpassingen gedaan zijn. Maar welke?

Bv de bug bevondt zich op regel 889 en betrof missende () bij een bewerking.

Log line:

git log -L(from),(to):(path)

bv:

git log -L887,891:Trypo/.src/TrypoForms/FDayReq.class

Dit geeft me de – en + regels, en hiermee kan ik snel vinden wat er juist gebeurd is.

De online versie van de master en mijn eigen lokale versie zijn uiteengelopen.

git checkout master
Switched to branch 'master'
Your branch and 'origin/master' have diverged,
and have 11 and 1 different commits each, respectively.


Ik kan het niet eenvoudig oplossen met push of pull:


git status
On branch master
Your branch is ahead of 'origin/master' by 11 commits.
(use "git push" to publish your local commits)
'
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: .project
'
no changes added to commit (use "git add" and/or "git commit -a")
linuxuser@copyleft:~/Git/MyProject> git push
To gitlab.com:dev/myproject.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'gitlab.com:dev/myproject.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
linuxuser@copyleft:~/Git/MyProject> git pull
error: cannot pull with rebase: You have unstaged changes.
error: please commit or stash them.


Ik haalde de main af in een test directory en met Kompare bekeek ik de verschillen om te checken wat er aan de hand was. Conclusie: mijn locale versie moet de nieuwe main/master worden.

Ik beveilig eerst mijn locale wijzigingen in een nieuwe branch:
(Als het over een kleine wijziging ging zou ik misschien git stash en git stash pop gebruiken)

git branch backup-mainlocal

Daarna even checken:

git status
On branch master
Your branch and 'origin/master' have diverged,
and have 12 and 1 different commits each, respectively. (...)

Ik zit nog in mijn master; gelijkzetten met de online versie:

git reset --hard origin/master
HEAD is now at efde303 Update ReadMe.txt with sourceforge tar.gz link

Ik zie de laatste wijziging daar in mijn ReadMe bestand.
Nu zijn beide versies terug gelijk:

git status
On branch master
Your branch is up to date with 'origin/master'.

en kan ik de wijzigingen toepassen uit mijn backup:

git merge backup-mainlocal
Merge made by the 'ort' strategy.
.component | 4 ++++
.gitignore | 19 +++++++++++++++++
.project | 3 ++-
.src/FMain.class | 54 +++++++++++++++++++++++++++++++++++++++++-------
.src/FMain.form | 4 ++--
...
Changes.txt | 15 ++++++++++++++
Help.txt | 2 +-
10 files changed, 441 insertions(+), 29 deletions(-)
create mode 100644 .component
create mode 100644 .gitignore

En online brengen:

linuxuser@copyleft:~/Git/MyProject/> git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 627 bytes | 627.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0
To gitlab.com:dev/myproject.git
efde303..c950ea5 master -> master

Ok nu zijn ze terug synchroon.

Ik moet een oud project oppikken dat ooit een aparte branch had waarin ik wil gaan werken, en ik moet de code up to date maken met de huidige stand.

git reset --hard origin/master

Als antwoord krijg ik:

HEAD is now at 01d4e38 fix conflicts

Ik vraag me af welke conflicts er dan zijn, want er worden er geen opgesomd. Normaal, als er conflicten zijn, wordt de aktie niet uitgevoerd, maar hier heb ik wel de bevestiging van “Head is now at ..”.

Bij nader inzien bleek “fix conflicts” de commit message te zijn van de laatse commit waar head nu op zit ….

Eén enkele branch afhalen van een git repository

Ik heb in een “dev” map een project “myproject” met ontwikkeling in Gambas3 op een pc met Kde-desktop.

Er is één tak van het project, branch “compat-lxde”, die ik ontwikkel op een ander toestel (Raspberry Pi) met een LXDE desktop; om de applicatie daar compatibel met die desktop te houden. Hierin neem ik bijna alles over van de “main”, behalve de dingen die niet werken in een LXDE desktop, die laat ik weg of pas ik aan.

De branches main en compat-lxde lopen dus grotendeels parrallel.

Soms wijzig ik iets op di Pi aan de lxde versie dat ook nuttig is voor main, en om dat binnen te halen wil ik ook de lxde code op mijn KDE-pc, maar op zo’n manier dat ik mij niet vergis met mijn gewone development, ik moet vermijden dat ik mijn gewone development aan het doen ben in de lxde versie bv.

Ik wil dus op mijn pc op een andere plek één bepaalde tak van mijn ontwikkeling apart bijhouden om die daar enkel te raadplegen.
Ik wil hier niet alle andere branches in hebben want die heb ik in mijn dev map, en daar werk ik ook aan.

Algemeen:
git clone -b --single-branch

Bv: als branch compat-lxde bestaat in het project:
git clone -b compat-lxde --single-branch https://gitlab.com/project/myproject.git

Ook op de Raspberry Pi kan het nuttig zijn om niet alle code binnen te halen, maar enkel de branch “compat-lxde” en bv “main” of “test”.

Nu kan ik op de pc in mijn dev directory de branches gebruiken om in te werken, bv in “feat-abc”, dan naar test, tot binnenhalen in main.

Ik ga naar de pi, integreer daar alles van main in de lxde branch. Ik doe terloops ook nog een kleine correctie (die terug naar test/main moet).

Ik ga op de pc naar de map met de lxde, haal de wijzigingen af (pull), kan die openen en knippen/plakken naar het project dat in de ontwikkelomgeving open staat in dev directory.

Normaal zit in de dev directory ook de lxde branch, en kan je daar diff’s met test/main doen en zo.

Om een enkele tak lokaal toe te voegen, doe:

git remote set-branches –add origin [remote-branch]
git fetch origin [remote-branch]:[local-branch]

Doel: een “Developer” mogelijkheid geven om de main te updaten.

De leden van een project kunnen hun rol hebben gekregen doordat ze lid zijn va een “group”, en die kan dan niet apart ingesteld worden voor een subproject van die group, bv devcopyleft/clTools
Rollen zijn in stijgende volgorde : Guest - Reporter - Developer - Maintainer - Owner

Ga naar de hoofdpagina van de group, bv devcopyleft.
Daar bij “Manage”, zie je de “Group Members”.
Als je de nodige rechten hebt (oprichter van de group: “owner”) kan je in de kolom “Role” klikken op de rol en die veranderen, bv naar “Maintainer”.
Nu kan hij “push” naar “main” doen.

Access denied

git clone https://gitlab.com/devgroep/myprojectterminal.git
Cloning into ‘myprojectterminal’…
Username for ‘https://gitlab.com’: mijngebruiker
Password for ‘https://mijngebruiker@gitlab.com’:
remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See https://gitlab.com/help/topics/git/troubleshooting_git#error-on-git-fetch-http-basic-access-denied
fatal: Authentication failed for ‘https://gitlab.com/devgroep/myprojectterminal.git/’

Gebruik SSH keys
De site van gitlab legt dat goed uit;

https://docs.gitlab.com/ee/user/ssh.html

Kijk eerst of je al ssh sleutels hebt:

cd ~
cd .ssh/
Als je nog geen .ssh directory hebt, moet je checken of ssh geînstalleerd is, en/of genereer de ssh keys:

ssh-keygen -t ed25519 -C "mijngitlabaccountnaam"

Bij de vraag waar de key bewaren kan je normaal bevestigen:

Enter file in which to save the key (/home/user/.ssh/id_ed25519):

Als de .ssh map nog niet bestond, zal die nu gemaakt worden (geeft melding).

Nog wat bevestigen, en daarna vind je twee (nieuwe) bestanden, waarvan 1 de publieke sleutel is (die eindigt op .pub); en je kreeg ook wat randomart te zien…

The key’s randomart image is:

De inhoud van het pub bestand, inclusief opmerking, kopieren in de gitlab site bij je avatar, “edit profile, linkse kolom ssh keys”.. Add new key ..

De geldigheid kan je instellen als je wil.

Je ziet daarna dat de key is toegevoegd in je lijstje op https://gitlab.com/-/user_settings/ssh_keys

Nu vraagt git nog altijd mijn username en wachtwoord, maar nadien werkt bv het clonen wel.

Clean?
Een “cleane worktree” is je worktree na een commit/push of na een clone of pull.
Je ziet dat aan git status.

Dirty?
Vanaf je iets gewijzigd hebt, is het een “dirty worktree”, de toestand is “bezoedeld” door wijzigingen die nog nergens geregistreerd zijn.

Multiple?
Werken aan twee branches TEGELIJK.
(normaal schakel je om met git checkout branch1, hackhackhack, get stash, git checkout branch2, hackhackhack, git commit+push, git checkout branch1 ….)

Als je aan twee branches tegelijk wil werken kan je in een andere directory terug een clone doen van het project. Dan zit je met veel dubbele code, en moet je telkens beiden syncen. Je kan het Git zelf laten doen met git worktree, dan heb je minder ruimte nodig op de harde schijf, en verloopt het synchroon houden ook automatisch:
Bv: op een Raspberry Pi een “legacy” versie van software vergelijken met de huidige universele (die evolueert).

git worktree list
git worktree add MijnNieuweWerkboom *
en als je er mee klaar bent:
git worktree remove MijnNieuweWerkboom

Goede uitleg van het principe op https://tecadmin.net/git-worktrees-parallel-development-guide/
https://devdynamics.ai/blog/understanding-git-worktree-to-fast-track-software-development-process/

Eens die worktree gemaakt, zie je in je projectmap een map met de naam van de nieuwe worktree. En daarin staan terug dezelfde files als je al had in de directory erboven. Oei, dat was niet de bedoeling, die map hier in mijn projectcode te hebben.
(*) Belangrijk is om de directory op te geven waar die nieuwe worktree moet gezet worden bij git worktree add:

git worktree add ./../MijnNieuweWerkboom
of
git worktree add /home/username/directoryEtc

Terug verwijderen:
git worktree remove MijnNieuweWerkboom
git prune

git worktree add ./../MijnNieuweWerkboom
dan met
cd ..
cd MijnNieuweWerkboom
git status
git worktree list

Ik heb twee situaties gehad, de eerste was:
-1 In die directory zie ik een branch met de naam MijnNieuweWerkboom, terwijl ik die niet expliciet heb aangemaakt.

Normaal geef je als parameter een bestaande branch op (denk ik).

git worktree add ./../MijnNieuweWerkboom bestaandeBranch
(branch die ik daar wil om parrallel in te werken)
of
git worktree add /home/username/directoryEtc bestaandeBranch

-2 ik kreeg een foutmelding “invalid reference: bestaandeBranch”; misschien bestond die niet of had ik hem verkeerd geschreven.

-3: fatal: “.. is already checkout out at ..”
Dat is eigenlijk wel zo… Ik kon dit oplossen door eerst een andere branch aktief te maken:
git checkout otherbranch
git worktree add ../MijnNieuweWerkboom bestaandeBranch

.. preparing …
HEAD is now at .. (shows comment of commit)

Bij geval 1: In Gambas is de naam van de map ook de naam van het project, dus dat is nu plots ook veranderd.

Hmm, nog niet goed? Je kan bij het maken van een worktree (blijkbaar/soms) ook de naam van de nieuwe branch meegeven, verschillend van eender welke bestaande.

In mijn geval is het nu niet zo erg, je moet eventueel een nieuw configuratiebestand aanmaken, of het bestaande kopieren. Hierdoor kan je ze ook uit elkaar houden (bv voor de executable; handig dat de naam anders is).

---

Stash
git stash kan heel interessant zijn: je bewaart alleen je huidige veranderingen.

VRAAG: Dus als je twee gelijkaardige projecten hebt die enkel een beetje verschillen, maar die verschillen moeten blijven bestaan, dan kan je met stash je nieuwe werk bewaren (dat dan niet over die specifieke verschillen mag gaan), en die “toepassen” op eender welke andere branch, of je eigen branch als je dat nog niet gedaan had en toch was uitgecheckt.

hackhackhack
git stash wijzigingen op de LIFO
git stash show
git stash apply —-> this you can do on another commit; how?
git stash drop (laatste verwijderen)
git stash pop = apply + drop
git stash list
git stash clear (leegmaken)

git stash pop, ofwel git pop 0 (voor de laatste) git pop 1=voorlaatste enz. past de laatste stash to op de huidige worktree, en gooit hem daarna weg.

om “een stash” te verwijderen uit de “git stash list” doe je git stash drop i

Nu nog uitzoeken hoe ik een stash toepas op .. bv een ander worktree?

---

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – git worktree – GitLab vb – SourceForge vb – git en gambas)

In principe ga je in de ontvangende tak staan (git checkout achtergeblevenbranch)
En merge je een andere naar je toe (git merge voorlopendebranch)

Eenvoudige merges, samenvoegen van iets dat verder voorop is en eenvoudig toegevoegd wordt aan een achtergebleven tak, is gemakkelijk te begrijpen, maar soms is het ingewikkelder.

git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit]
[–no-verify] [-s ] [-X ] [-S[]]
[–[no-]allow-unrelated-histories]
[–[no-]rerere-autoupdate] [-m ] [-F ]
[–into-name ] […​]
git merge (–continue | –abort | –quit)

merge strategiën
De verschillende merge “strategies” zijn recursive, resolve, octopus, ours, subtree

Je kan zelf de merge strategy opgeven met een parameter:
(ook bij git pull trouwens)

git merge -s recursive tak1 tak2

git merge -s resolve tak1 tak2

git merge -s octopus tak1 tak2 tak3 .. takn

git merge -s ours tak1 tak2 .. takn

git merge -s subtree takA takB

Type van strategie

– Expliciet
Dit is de standaard merge methode. Het betekent dat er een nieuwe “merge commit” gemaakt wordt. Dit toont waar de merge werd gedaan in de merge geschiedenis, en dat is niet altijd gewenst (omdat het de aandacht afleidt, ruis dus). Als je deze details niet in je merge history wil, zal je misschien explicit merge vermijden.

– Impliciet
Impliciete merge via rebase of fast-forward merge

– Squash
Squash on merge, meestal zonder expliciete merge

Recursive merge strategy options

ours, theirs, patience, diff-algorithim, ignore, renormalize (no-normalize, no-renames), find-renames=n, subtree

Er zijn veel mogelijkheden, en hoe moet je kiezen wat te gebruiken alvorens je ze doorgrondt?

Een merge van twee branches (dev-hq en roadie) gedaan die verkeerd afloopt, bv omdat de versies meer verschilden dan je dacht (op beide was een stukje ontwikkeling gedaan ipv op één van beiden)? Je kan correcties gaan doen in de broncode, die door git voorzien is van merktekens als

< <<<< HEAD
======
>>>>>>> roadie

.. met daartussen brokken tekst van de verschillende versies.
Soms is het duidelijk, een klein verschil kan een eenvoudige correctie zijn, of een uitbreiding van een string of een commentaar. Dan kan je die onmiddellijk verbeteren met een .txt editor (zelfs buiten de normale programmeeromgeving).

Maar als de verschillen te groot zijn en/of je er niet aanuit kan, wil je misschien de “merge” operatie herstellen naar de toestand voordien.

Zolang je het conflict niet opgelost hebt, en niets kon pushen, niet gecomit hebt, kan je nog altijd terug met :

git merge --abort

Je kan info krijgen van git:

git reflog

Als je terug wil gaan naar de laatste gemeenschappelijke toestand, kan je die vinden met:

$ git merge-base dev-hq roadie
806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Dan kan je terug naar die toestand met

git reset 806f8ac3c61b1e55cdd5b53a0205b51d1d31387a

Unstaged changes after reset:
M .src/FConfigure.class
M .src/FConfigure.form

Om hem online te krijgen volstaat een gewone git push niet:

git push
To gitlab.com:stockpi/stockpiapp.git
! [rejected] dev-hq -> dev-hq (non-fast-forward)
error: failed to push some refs to ‘gitlab.com:stockpi/stockpiapp.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.

git push --force

git push –force
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for dev-hq, visit:
remote: https://gitlab.com/stockpi/stockpiapp/-/merge_requests/new?merge_request%5Bsource_branch%5D=dev-hq
remote:
To gitlab.com:stockpi/stockpiapp.git
+ 8a060eb…806f8ac dev-hq -> dev-hq (forced update)

(zie bv https://www.atlassian.com/git/tutorials/undoing-changes/git-reset)
Julia Evans: “git rebase: what can go wrong?”

Binnen een branch kan je kijken met git log, maar als je een overzicht wil over alle branches…

Lijst van alle branches met laatste commit bericht:
git branch -v

Gesorteerd op datum (maar zonder die weer te geven)

git branch -v --sort=committerdate

Alle, inclusief remote:
git branch -v --sort=committerdate

git for-each-ref --sort='-committerdate:iso8601' --format='%(committerdate:relative)|%(refname:short)|%(committername)' refs/remotes/ | column -s '|' -t


2 months ago           origin/HEAD               matty
2 months ago           origin/master             matty
2 months ago           origin/test               matty
3 months ago           origin/feat-Day           matty
6 months ago           origin/integrate-lib      matty
3 years, 7 months ago  origin/feat-Fact       cybrarian

git for-each-ref --sort=-committerdate refs/heads/ --format='%(committerdate:short) %(authorname) %(refname:short)'

2022-02-11 cyb master
2022-02-11 cyb test
2022-02-09 cyb feat-DayAdd
2021-12-08 cyb fixMissingDayTypeDispl

git for-each-ref --sort=committerdate refs/heads/ --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(color:red)%(objectname:short)%(color:reset) - %(contents:subject) - %(authorname) (%(color:green)%(committerdate:relative)%(color:reset))'

 fixMissingDayTypeDispl - a493cbe - FDayReq: fix missing daytype display - mat.ara (2 months ago)
* feat-DayAdd - dea7f5e - gitignore err - cyb (9 days ago)
  test - a94611e - merge test ie FMain.class - cyb (7 days ago)
  master - 33ac1e2 - fix Changes.txt  - cyb (7 days ago)

Met de datum ervoor:

git for-each-ref --sort=-committerdate refs/heads/ --format='%(authordate:short) %(color:red)%(objectname:short) %(color:yellow)%(refname:short)%(color:reset) (%(color:green)%(committerdate:relative)%(color:reset))'

Deze is ook mooi:

git branch -vv --color=always | while read; do echo -e $(git log -1 --format=%ci $(echo "_$REPLY" | awk '{print $2}' | perl -pe 's/\e\[?.*?[\@-~]//g') 2> /dev/null || git log -1 --format=%ci)" $REPLY"; done | sort -r | cut -d ' ' -f -1,4-

2022-02-11   master                 33ac1e2 [origin/master] fix Changes.txt for merge
2022-02-11   test                   a94611e [origin/test] fix merge test FMain.class
2022-02-09 * feat-DayAdd            dea7f5e [origin/feat-DayAdd] gitignore 
2021-12-08   fixMissingDayTypeDispl a493cbe FDayReq: fix missing daytype display

Of maak een alias…

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – stash – GitLab vb – SourceForge vb – git en gambas)

Undo
Wijzigingen niet bewaren (die niet toegevoegd waren – ‘not staged’) en terugkeren naar de laatste goede toestand van de bestanden in je directory:

– git reset --hard
Alle wijzigingen weggooien en terug beginnen met de vorige toestand van je ontwikkeltak.

– git checkout -- vuilbestand
Eén bestand terugdraaien naar de laatste normale toestand van voor je (klad)werk.
Een typisch voorbeeld is een .settings bestand dat kan reageren op het starten van een programma; bv omdat het een teller bevat, of de laatste toestand van schermen of geopende documenten bijhoudt of zo.

– git stash
Dit laat je toe de wijzigingen niet op te nemen in je programmeervoortgang, maar toch ook niet helemaal definitief weg te gooien; je zet ze opzij om voort te kunnen met je normale ontwikkeling.
Daarbij hoort nog:
git stash list : lijst van stash-items in tijdelijke editor (q=quit).
git stash show : diff
git stash apply : toepassen van deze stash op huidig werk.
git stash pop: toepassen van deze stash op huidig werk en uit stash halen.

Zie ook stash

Ik zit ijverig te werken en nadien zie ik dat ik in de master branch bezig ben ipv de dev branch.
Ik heb nog geen git add of commit gedaan.
(in git status zie ik modified: BestandWaaraanIkBezigWas.class )
Ik kan natuurlijk alles weggooien en de master terugzetten op een vorig punt.

Maar ik wil de wijzigingen wel bijhouden, en ik wil die in de dev krijgen.

De aanbevelingen die ik lees gaan ongeveer zo:
– maak een nieuwe branch vanuit die master die je gewijzigd hebt (maar nog niet ge-commit), geef hem een tijdelijk naam bv tempdev.
git checkout -b tempdev
Switched to a new branch ‘tempdev’

– voeg eventueel nieuwe bestanden toe (niet nodig als je alleen “modified” hebt), en commit al je werk:
git add .
git commit -m "some new work"

Als ik nu terug ga (git checkout master) en daar git status vraag, geeft die geen modified bestanden meer.

– check of je de dev branch hebt:
git branch -l
master
* tempdev

Als je de dev branch niet hebt, kijken of hij er remote wel is:
git branch -lr (opgelet dit kan een vertekend beeld geven als die recent is bijgemaakt en je niet hebt bijgewerkt met fetch…)

origin/HEAD -> origin/master
origin/master

Of git branch -a om beiden te zien.

Dus eerst synchroniseren met online:
git fetch

remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 16 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
From git://git.code.sf.net/p/myproject/code
* [new branch] dev -> origin/dev
0c4e870..b8c15dc master -> origin/master

git branch -rl
origin/HEAD -> origin/master
origin/dev
origin/master
Beter!
– schakel naar dev branch en merge die met devtemp (importeert de devtemp wijzigingen).
git checkout dev
git merge tempdev
– commit en push zodat de (online) “remote” dev branch is bijgewerkt.
– schakel naar die je master en reset hem naar de laatste versie (van remote halen dus? Nee gebeurt lokaal): git reset --hard HEAD.

Stash
Misschien korter/handiger: gebruik “stash”, dat de wijzigingen lokaal even opzij zet (om ze al dan niet nadien toe te passen):

git stash
git checkout dev
git stash apply

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(in de reeks Git…)

Zien
Online (in de web interface) zie ik de branches:

• master
• test
• issue1

Maar lokaal zie ik alleen mijn eigen master (sic!):

git branch -l
* master

Ook na een git fetch blijft dat zo.

Git fetch heeft een standaardgedrag of volgt instellingen, maar je kan meer specifiek git fetch origin doen:

~/Git/TrypoPrj/TrypoPrj> git fetch origin
~/Git/TrypoPrj/TrypoPrj> git branch -l
* master

Bovendien moet je eigenlijk –list gebruiken (-l dient om een reflog aan te maken), en toont git branch –list enkel de lokale branches. Maar

git branch -r

origin/HEAD -> origin/master
origin/feat-01
origin/master
origin/test


toont de remote, of wil je alles:

git branch -a

* master
remotes/origin/HEAD -> origin/master
remotes/origin/feat-01
remotes/origin/master
remotes/origin/test

met extra info als laatste commit message:

git branch -v -a

* master 8ab6216 [ahead 1] remove .directory from tracked files
remotes/origin/HEAD -> origin/master
remotes/origin/feat01 2bbd368 Complete changes.txt with done work
remotes/origin/master de381ad Resolve merge conflict by combine and reorder lines in changes.txt

Afhalen
Als je een branch van remote wil halen kan je die opgeven

git fetch origin
of
git fetch origin branch-naam
Daarna bv merge in je eigen (bv master) en commit:

git merge origin/branch-naam
git commit ...

Of:
– check met git branch -la
– indien ok, git checkout WantedBranch
(gewoon met de naam, paar letters en gebruik TAB om aan te vullen)
Reaktie:

Branch WantedBranch set up to track remote branch WantedBranch from origin.
Switched to a new branch 'WantedBranch'

upd 2020-11-18

Een lokale branch ook remote maken

Situatie: ik heb een lokale “develop” branch en wil iemand mee laten ontwikkelen (of zelf vanop een andere plaats/toestel).

Er is een master branch, en de andere gebruiker ziet die:
De andere gebruiker heeft alleen de master:

git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
.
git pull
Already up to date.


Ik heb die ook, plus een develop, waarin ik aktief ben.

cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git status
On branch develop
nothing to commit, working tree clean
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git push
fatal: The current branch develop has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin develop
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git branch -r --list
origin/master
cybrarian@copylefthost:~/Gb3Prj/MyProject/ControlPanel> git push --set-upstream origin develop
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for develop, visit:
remote: https://gitlab.com/cybrarian.copyleft/ControlPanel/-/merge_requests/new?merge_request%5Bsource_branch%5D=develop
remote:
To gitlab.com:cybrarian.copyleft/ControlPanel.git
* [new branch] develop -> develop
Branch develop set up to track remote branch develop from origin.

Nu kan de andere gebruiker:
.
git pull
From gitlab.com:cybrarian.copyleft/ControlPanel
* [new branch] develop -> origin/develop
Already up to date.

De andere gebruiker kan nu ook mee aan de slag…
(mits hij de juiste rechten heeft – bv gitlab “maintainer”)

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – branch zoeken/datum – stash – GitLab vb – SourceForge vb – git en gambas)

(in de reeks Git…)

Hoewel ik .settings heb toegevoegd tot gitignore, blijft het af en toe opduiken als gewijzigd bestand, klaar om mee te committen. Ik begrijp niet of het komt door merge met andere medewerkers die misschien een andere instelling hebben (hoewel ik dacht dat die lokaal was).

Oorzaak is bv dat het bestand oorspronkelijk niet in gitignore zat, en er pas later is aan toegevoeg, toen het al getracked werd. En .gitignore werkt alleen voor “untracked” files (voor nieuwe bestanden dus).

Er is een extraatje nodig (how to make git forget..):

git update-index --assume-unchanged

git update-index --assume-unchanged .settings

Je krijgt geen feedback na dit commando.

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – GitLab vb – SourceForge vb – git en gambas)

SourceForge (https://sourceforge.net/) was in de open source en free softwarewereld zowat de eerste, grootste en bekendste website voor het online houden van een open source of free software project. Je kon de broncode gewoon uploaden als .tar.gz bestanden, of het Code Versioning System gebruiken (cvs), naast de vele project-tools voor opvolging van bugs, communicatie enz. (zie 2009)

SourceForge heeft achtergrond in VA Software (denk ook aan VA Linux, Geeknet, enz), ondertussen horen ze bij Slashdot media.
Het traject van de zoektocht naar rendabiliteit en de overnames deed Sourceforge geen goed en zaaide twijfel bij developers.
Heel wat nieuwe projecten gingen naar GitHub, (en meer recent GitLab), die specifiek gericht waren op het ondertussen in de FOSS wereld populaire geworden git-broncodebeheersysteem.

Maar ondertussen biedt SourceForge ook Git aan. Sinds januari 2018 promoten ze het aktief met een importeer-tool om GitHub projecten over te zetten naar SourceForge.
https://sourceforge.net/blog/introducing-the-new-sourceforge/

Wie al op Sourceforge zit kan zijn project beginnen beheren met git: https://sourceforge.net/p/forge/documentation/Git/

Om gemakkelijk te communiceren met de sourceforge repository is het best om een public key/private key communicatie op te zetten. Daarvoor moet je een “key” hebben, die je maakt met ssh-keygen.
Daarna moet je de projectdirectory initialiseren voor gebruik met git. En dan moet je je startcode “uploaden”, in git-terminologie comit-en en push-en.

1. Keys

1.1 keys maken:

De handleiding van sourceforge zegt:

ssh-keygen -t ed25519 -C “gebruikersnaam@shell.sf.net”

De plaats waar je dit doet is eender (bv kan je al in de projectdirectory staan).
De gebruikersnaam is die van je login, niet de weergegeven naam!
Na het commando krijg je de vraag in welk bestand de key bewaard mag worden, je kan het voorstel gewoon bevestigen.
Daarna kan je een wachtwoord ingeven (veiliger), wat je moet heringeven om te bevestigen.
Het eindigt met de plaatsen waar je identificatie en je public key bewaard werden*, en met je fingerprint.
Daaronder komt een beetje “ascii-art” met je randomart image.
* Je kan je instellingen checken in de bestanden:
private key: /home/usernaam/.ssh/id_ed25519 (deze moet je geheim houden!)
public key: /home/usernaam/.ssh/id_ed25519.pub (deze moet je meedelen)

1.2 keys registreren

Log in op SF en ga naar:
https://sourceforge.net/auth/shell_services
Daar plak je de inhoud van je .pub bestand.

2. Projectdirectory

De directory die je wil opnemen in het git beheer moet je initialiseren voor git gebruik.
Ga in de directory staan (cd projectdir), en check git:

git status
Als je … krijgt is er al een git repository van gemaakt!
Als er nog geen git initialisatie gebeurd is op deze directory krijg je een melding als:

fatal: Not a git repository

…(enz)

Tik het initialisatiecommando dat de nodige subdirectories en bestanden maakt:
init git

Initialised empty Git repository in …

Opgelet! Nu zijn er een aantal (onzichtbare) directories/bestanden bijgekomen voor git, gebruik deze projectdirectory niet meer om op een andere manier te kopiëren als project sourcecode, want hij is “vervuild” met git.

3. Stel de bron in

Als de broncode nog niet in de directory staat, kopieer je die ernaartoe. Ze vormen de verzameling van alle onderdelen die je nodig hebt om een programma te kunnen compileren.
Met git status toont git wat het daar ziet.

Je stelt ook de bestanden in die NIET naar de git-server moeten, omdat ze enkel lokaal nut of belang hebben (bv lokale instellingen van de programmeeromgeving), of omdat ze prive-informatie bevatten.
Maak daarvoor een bestand .gitignore in de projectdirectory.

git rm --chached (file) om iets wat er per vergissing toch is terechtgekomen; check met git status.

git commit -am ‘initial commit at version 0.1.5’

Je krijgt de melding dat een ‘standaard’ e-mail adres gebruikt is; je kan het instellen met:

git config --global --edit

pas aan, bewaar (standaard met ESC :w en :q), en daarna fix de identiteit die gebruikt werd met:

git commit --amend --reset-author

Je krijgt dan een tekst te zien (waarin je bv het e-mail adres kan verbeteren, dacht ik, maar dat blijkt achteraf niet met git log**); ook weer ESC :wq om te bewaren en verlaten.

4. Stel de server in

Nu moet je een verbinding instellen met de server, waar de broncode naartoe moet.

git remote add origin ssh://login@git.code.sf.net/p/gitin/code

(met je eigen login natuurlijk; de username).

En dan de eigenlijke “upload”:

git push -u origin master
Er wordt een bevestiging gevraagd van de git.code.sf.net server (met ip)
Die wordt dan toegevoegd aan de “known hosts”.
Daarna moet je je wachtwoord ingeven (dat van de ssh key).

Met wat geluk eindigt alles met:

Branch master set up to track remote branch master from origin.

Nu kan je via de website het resultaat zien onder het tabblad “code”:
https://sourceforge.net/p/projectname/code/

De projectdirectory is volledig te “browsen”!
Onderaan verschijnt de inhoud van het readme.txt bestand.

Zeer handig is de kolom “Commit”, want daar verschijnt de commit message, en je kan daarmee snel zien wat de laatste verandering is in een directory of bestand.

---

**)
Je moet eerst expliciet de gegevens instellen, bv het e-mail adres wordt afgeleid uit je username en je hostname, dus je krijgt username@host, en dat kan bv de lokale hostname van je pc zijn.

Je moet dan eerst expliciet de username of het e-mail adres instellen:

git config --global user.name "gebruikersnaam"
git config --global user.email "user@domein.abc"

5. Gebruik.

– Code

git commit -am 'initial commit at v.0.1.3'

Nadat van een project de originele code naar de server geladen is, wordt ze zichtbaar in de “code” tab van de Sourceforge website, bv als:

Tree[987456] master/

Op die pagina krijg je ook de commando’s aangeboden die je nodig hebt om ssh/https/RO (read-only) toegang te krijgen.

– Clone

RO is genoeg om het project af te halen:

git clone git://git.code.sf.net/p/projectnaam/code projectnaam-code

Dit maakt een lokale directory projectnaam-code, verwijzend naar de structuur op de server (beetje verschillend van GitLab).

Om ook schrijftoegang te hebben moeten eventueel de rechten aangepast worden door de admin van het project, en moet je één van de voorgestelde read/write commando’s geven.

git branch --list toont: “* master”

fatal: remote error: access denied or repository not exported…

Als je oorspronkelijk enkel read-access hebt gevraagd (bij project clone), kan je nadien de instellingen aanpassen in het .git/config bestand. Volgens de documentatie:

git://PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read-only)
ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read/write)

Bij mij zag het er iets anders uit:

url = git://git.code.sf.net/p/projectnaam/code

url = ssh://USERNAME@git.code.sf.net/p/projectnaam/code

Zoek de regel die begint met git:// en verander hem naar ssh:// waarbij je “USERNAME@” toevoegt (maar dan je echte loginnaam natuurlijk).

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – GitLab vb – SourceForge vb – git en gambas)
Zie ook artikel over branches in git, (Engelstalig, 2015)

Branch commando’s

git branch (--list)= toon branches; git branch -a = toon alle (ook remote)
git branch -v = toon laatste commit messages
git branch Testing = maak nieuwe branch met naam “Testing”
git checkout Testing = overschakelen naar branch
git checkout -b Testing2 = maken en overschakelen naar nieuwe branch (die op het moment wordt gemaakt; combinatie van branch en checkout)
git merge bugfix = merge bugfix in huidige branch (vorige checkout branch, hier dus Testing)
git branch -d bugfix = verwijder branch (gaat niet? checked out?)

Branch, merge
Veelgebruikte struktuur van vertakkingen:

Master branch (-> production server)
Develop branch (-> staging server)

• Feature branch
• Hotfix branch
• Release branch
• Support branch

Git Branching and merging strategies beschrijft het zo:

Master – Test – Develop

Uit Master wordt initieel test gemaakt, uit test develop, en uit develop de feature branches.

Master - Test - Develop -- Feature-1
                        -- Feature-2

(

De Develop stage krijgt updates uit de feature branch die gewijzigd is;

.. Develop <-- Feature-1
           <-- Feature-2

De feature branches houden zich up to date door de wijzigingen uit de develop regelmatig af te halen (rebase). Hoe beter ze onderling op de hoogte blijven van de ontwikkeling, hoe minder conflicten later.

.. Develop --> Feature-1
           --> Feature-2

En alles van develop gaat uiteindelijk naar boven naar test, dan naar Master.

Vanuit Master wordt een Release 1.0 branch gemaakt.
Later vanuit Master een Release 2.0 branch.

De bugs die ontdekt worden in de Release branches, kunnen gepatcht worden (éérst op eerste versie waar die voorkomt)
bv comit op Release 1 –
van daaruit Merge naar Release 2
van daaruit Merge naar Develop (waarna het met rebase bij de feature branches komt, en waar het klaar zit voor de volgende release naar boven)

Overzicht van bestaande branches:

git branch --list

bugfix
* master
testing

Verschillende commits:

• Merge
• Fast-Forward
• Rebase

Branch namen

Vb van een prefix die onderscheidend werkt:

feat-shortname bv: feat-stocklist
fix-shortname bv: fix-bugitem1234
hot-shortname bv: hot-fixCrashStartWithoutDb
rel-shortname bv: rel-v1-2
try-shortname bv: try-stocklistlocalcache

Branch lokaal-remote

Een lokaal gemaakte branch kan nadien gewoon naar de server gestuurd worden:

git push origin feat-1

of ook:

git push --set-upstream origin test
korte versie:
git push -u origin test

Voorbeeld 1 merge (recursive):

master: bestand 1 veranderd; commit
develop: bestand 2 veranderd; commit

git checkout master
git merge testing

Merge made by the ‘recursive’ strategy.
TweedeBestand.txt | 1 +
1 file changed, 1 insertion(+)

Voorbeeld 2 merge (fast-forward):

git checkout master
git checkout -b bugfix

Switched to a new branch ‘bugfix’

Wijzig bestand 2, en …

git commit -a -m "voeg commentaar toe"

[bugfix 02aa0b3] voeg commentaar toe
1 file changed, 1 insertion(+)

git checkout master

Switched to branch ‘master’
Your branch is ahead of ‘origin/master’ by 3 commits.
(use “git push” to publish your local commits)

git merge bugfix

Updating feb4282..02aa0b3
Fast-forward
TweedeBestand.txt | 1 +
1 file changed, 1 insertion(+)

Voorbeeld 3: opkuisen na merge

Daarna mag de tak van de bugfix weg:

git branch -d bugfix

Deleted branch bugfix (was 02aa0b3).

Als hij nog aktief staat krijg je een fout:

error: Cannot delete branch ‘bugfix’ checked out at ‘/home/..

Voorbeeld 4 merge (rebase)

branch master, test, feat-1, feat-2

wijzigingen feat-1, commit
wijzigingen feat-2, commit

git checkout test
git status

git merge feat-1

Updating f276191..804f3c6
Fast-forward
Project/.src/Filename.class | 12 +++++++++++-
… (bestanden en wijzigingen)
12 files changed, 291 insertions(+), 37 deletions(-)
create mode 100644 Project/.src/FGetText.class
create mode 100644 Project/.src/FGetText.form

git merge feat-2

Auto-merging Project/Changes.txt
Auto-merging Project/.src/MForm.module
Auto-merging Project/.src/FMain.class
Merge made by the ‘recursive’ strategy.
Project/.src/FMain.class | 2 +-
Project/.src/MForm.module | 1 +
… (bestanden en wijzigingen)
7 files changed, 646 insertions(+), 1 deletion(-)
create mode 100644 Project/.src/Class/CIntWeek.class
create mode 100644 Project/.src/Forms/FInterim.class

Om in mijn feat-1 alle wijzigingen van test al mee te krijgen:

git checkout feat-1
git rebase test

Opm:
– alhoewel niet iedereen voorstander is van rebase gebruik, zie ook fetch/merge, pull
– “never force push to a shared branch”, “don’t rebase on shared branches”, zegt Julia Evans

Voorbeeld 5 merge (diverged/rebase)

Zie hier…
http://linuxuser.copyleft.be/liglog/?p=7490

Merge Error 1

Fout op 1 bestand dat lokaal veranderd is, maar enkel een .settings bestand is dat mag overschreven worden:

git reset --hard
Daarna terug de merge.

Merge Error 2

git checkout test
git merge feat-1

Auto-merging Proj/Changes.txt
CONFLICT (content): Merge conflict in Proj/Changes.txt
Automatic merge failed; fix conflicts and then commit the result.

git status

On branch test
You have unmerged paths.
(fix conflicts and run “git commit”)
(use “git merge –abort” to abort the merge)

Changes to be committed:

modified: Proj/.src/ProjForms/FInterim.class
modified: Proj/.src/ProjForms/FInterim.form

Unmerged paths:
(use “git add …” to mark resolution)

both modified: Proj/Changes.txt

Inderdaad, de Changes.txt file is gewijzigd in beide takken. Als je het bestand in de huidig aktieve branch (de merge branch Test in dit geval) opent, zal je aanduidingen zien van de overlapping:

0.1.2 
...
< <<<<<< HEAD

FFactoring:
0.1.2 
=======
>>>>>>> feat-interim

HEAD : geeft de “hoofd”-branch aan, waar naartoe gemerged wordt, waarna die tekstversie
====== : geeft de scheiding aan naar het begin van de ingevoegde (feature-,..) branch en de bijhorende tekstversie
Ook de ingevoegde branch naam staat er achter.

Maak van de tekst de versie die het uiteindelijk moet worden, combineer beide stukken of gooi wat weg.
Stage de veranderingen met git add .
Commit de veranderingen met git commit -m "Resolve merge conflict by combining and ordening changes.txt"

Probeer daarna opnieuw een merge.

(Reeks Git – handboek (nl) – commando’s vb – branch, merge – GitLab vb – SourceForge vb – git en gambas)

Commando’s

git config --global user.name "mijn naam"
git config --global user.email mijnemail@mijndomein.tld
git config --list

Je kan op dezelfde manier je editor en diff tool instellen.
Waarde wordt bewaard in ~/.gitconfig (in opensuse).

Bekijk de instellingen daar, of zoals de laaste lijn met –list.
(antwoord leeg=geen instellingen)

Deze configuraties worden met –global eenmalig gedaan; je kan ze zonder global uitvoeren voor een project met afwijkende gegevens (na git init in de projectdirectory):

git config user.name "mijn andere naam"
git config user.email anderemail@mijndomein.tld

Deze komen terecht in de lokale .git/config

git init = start gebruik git; creatie van ~/.git/ directory in de projectdir waar je bent

git clone git://gitserver.org/iemandsdirectory/eenproject.git = haalt een bestaand project af en maakt een werkdirectory klaar.

Initialized empty Git repository in /home/name/Gambas3Prj/PrjName/.git/

Als het project via de webinterface is aangemaakt zal je meestal een “text” bestand README.md in vinden;
extentie md staat voor markdown, voor eenvoudige opmaak nummering enz met # heading *bold* -listitem enz

Waarna git status:

# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use “git add” to track)

Beginnen met een kopie van een project:
git clone git://gitlab.com/iemand.naam/eenProject.git

Cloning into ‘eenProject.git’ …

(Fouten zie ook 4*)

Waar komt clone terecht?
Als je geen git init gedaan hebt, maar onmiddellijk git clone:
– clone van het project “GitUse”
– commando van in de directory ~/Git/GitUsePrj>
Dan wordt ~/Git/GitUsePrj/GitUse gemaakt, met daarin de verborgen .git directory.

Git files in mijn project? (upd 2024)
Inderdaad wordt er een verborgen directory gemaakt met de files die git nodig heeft voor zijn werk. Wil je terug een “zuivere” kopie zonder die git files, een “export”, dan kan je bv een “archive” laten maken door git-archive; daar zit geen .git directoy in.

git status = overzicht lokale(!) toestand, bv nieuwe bestanden enz (! zie git fetch)
git status -s = korte samenvatting toestand, met afkortingen als M, MM, A, ??
git add test.txt = toevoegen aan staging (of nieuw bestand opvolgen- in “tracked”)
git add . voegt alle nieuwe files en dirs toe (behalve ignored)
git add -u kijkt naar de wijzigingen aan de tracked files.
git rm --cached test.txt = untrack/unstage test.txt;
git add '*.txt' = als wildcards gebruikt worden: aanhalingstekens
git
git commit -m "beschrijving van de inhoud of wijziging (m=message)" = toevoegen aan repository van alles wat in staging staat; anders filenaam opgeven
git commit test.txt = commit alleen deze file
git commit -a = gaat zelf de nodig add en remove (rm) doen
git commit -a -m 'grote lijn van wijziging' = combinatie -a en -m
git commit --amend vergist in tekst van commit? edit..

git log = geeft soort “history”, in volgorde al de laatste handelingen (in editor; verlaten met :q )
Remote instellen:
git remote add korteNaam git@gitlab.com/userdirectory/repository.git = opgeven van repository op de gitruimte ; standaard branch is ‘master’
git remote add korteNaam https://domain.tld/userdirectory/repository.git = versie met https in plaats van git of ssh.
git remote -v = lijst van gedefinieerde fetch en push remotes

git push -u korteNaam master = alles naar online (git push origin master)

git fetch = toestand van de online versie ophalen (waardoor je -lokaal- de status kan vergelijken met de bijgewerkte toestand online tot dat punt)

git pull korteNaam master = alles direkt binnenhalen om te werken. (Eigenlijk fetch + auto merge; je krijgt geen kans meer om de verschillen te bekijken zoals na fetch!)

git diff = verschillen zien tussen working directory en staging (standaard editor :q om te verlaten)
git diff HEAD = verschillen zien tov laatste commit, meest recente=’HEAD’
git diff --staged = verschillen zien eigen staged tov laatste online pull
git diff --cached = ” ” ”
git diff --color > ~/diff.txt verschillen inclusief kleurcodes bewaren om terug te kunnen zien met bv cat diff.txt
git --no-pager diff Changes.txt op het scherm tonen ipv in pager/editor te tonen, zodat het nadien zichtbaar blijft op scherm

git reset = verwijder laatste staged (maar file blijft wel tracked)
git checkout -- unwantedfile.txt = (spatie laten)

git branch branchname_voor_mij = maak nieuwe branch
git branch --list = toon branches
git checkout branchename_voor_mij = overschakelen naar branch
git branch -d branchname_voor_mij = verwijder branch (gaat niet: checked out?)

git rm '*.txt' = verwijderen van de files + wijz. klaarzetten in staging

Bij (merge) conflict, bv na git pull:
git mergetool
Dat brengt je in een gestuurde oplossing file per file, met info en keuzes als: use modified (m) or deleted (d) file, abort (a) …
Je moet dan eerst een git commit doen en daarna terug git pull.

Ik wil …

– controleren welke (exluded/uit te sluiten) bestanden mee in git zitten:

git ls-files (alleen bestanden)
git ls-files --stage (meer detail: [tag] mode object stage file)

– fout opgezette lokale repo wissen en opnieuw beginnen: rm -rf .git

(hier zit alles in). Check je .gitignore file in de project directory (waar .git stond), met git init wordt die overschreven?
rm -rf .git
git ls-files
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)

– weten of mijn lokale repo bij is met online: git status

git status
# On branch master
# Your branch is ahead of ‘nieuws/master’ by 1 commit.
# (use “git push” to publish your local commits)
#
# Untracked files:
# (use “git add …” to include in what will be committed)
#
# ProjectToTrack/.settings
nothing added to commit but untracked files present (use “git add” to track)

(zie ook 5*)

– mijn versie naar boven naar online duwen git push

git push –all
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 521 bytes | 0 bytes/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To git@gitlab.com:/mat.abc/Test.git
9512a28..a72f459 master -> master

– de laatste online versie afhalen git pull test master

git pull test master
Pass a valid window to KWallet::Wallet::openWallet().
Pass a valid window to KWallet::Wallet::openWallet().
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From https://gitlab.com/mat.ara/Test
* branch master -> FETCH_HEAD
9512a28..a72f459 master -> test/master
Updating 9512a28..a72f459
Fast-forward
ProjectToTrack/.src/FMain.form | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

Enkele vragen blijven nog:

• worden er bestanden bijgemaakt door git in de specifieke subdirectories van een project, of alleen in de onzichtbare .git directory op hoogste niveau?
• wat is beste methode: directories opnemen en files excluden, of specifieren welke wildcard-files moeten opgenomen worden?
  Bv voor gambas: ./*.txt; ./src/*.class; ./src/*.form erin of .gambas; .settings; .*~ eruit: Gebruik .gitigrnore (gambas maakt nu een .gitignnore bij creatie van een project).
• Wat met .png, .jpg, enz. Apart opslaan omdat ze binary zijn? Kunnen mee in ropository maar de diff is enkel op tekst.
• moet een projectdir dezelfde naam hebben op de verschillende locaties? De dir waarin je git init doet waarschijnlijk niet, en de rest haal je mee binnen zeker?
• Hoe werken vanop verschillende computers (als dezelfde ‘gebruiker’ (zelfde e-mail adres); ssh keys kopieren of meer keys maken? Hier ben ik nu geneigd om verschillende “users” te maken op de verschillende toestellen/locaties. Maar als ieder van die users dezelfde branch “dev” gebruikt wordt het snel weer verwarrend. Je moet telkens de branches met dezelfde naam mergen.
  Ik plan nu:

  • workmail@domainwork.tld - > branch "devwork"

  • secondwork@webmail.tld - > branch "devlaptop"

  • personalmail@hosting.tld - > branch "devhome"

  Dan is het ook duidelijker dat je inderdaad moet mergen.

Links
Een paar links voor zolang ze geldig zijn:

Nederlandstalig! https://git-scm.com/book/nl/v1/Aan-de-slag
https://git-scm.com/book/en/v1/Getting-Started-First-Time-Git-Setup
https://help.github.com/articles/se-up-git/
https://try.github.io/levels/1/challenges/1
Goede commit messages zien er zo (niet) uit:
https://chris.beams.io/posts/git-commit/
https://longair.net/blog/2009/04/16/git-fetch-and-merge/ fetch, merge (of pull?)

(meer…)