28/9/2018

Git voorbeeld: SourceForge

Filed under: — cybrarian @ 10:24 am

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit 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).

4/9/2018

Git gebruik organiseren: branches, comit, merge

Filed under: — cybrarian @ 8:59 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)
Zie ook artikel over branches in git, (Engelstalig, 2015)

Branch commando’s

git branch = toon branches = git branch --list = toon branches
git branch -v = toon laatste commit messages
git branch Testing = maak nieuwe branch met naam “Testing”
git checkout Testing = overschakelen naar branch
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

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

(alhoewel niet iedereen voorstander is van rebase gebruik, zie ook fetch/merge, pull)

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.

29/9/2017

GIT commando’s, vb, problemen

Filed under: — cybrarian @ 10:45 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit 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 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 log = geeft 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 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…)

29/6/2017

Git voorbeeld: gitlab

Filed under: — cybrarian @ 3:31 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)

Samenwerken of verdeeld werken

Een van de online diensten die git aanbieden is gitlab.com

Ik heb die gebruikt als voorbeeld bij mijn git artikel.

Registratie
Je maakt een account aan met een naam, wachtwoord en e-mail adres. Op dat laatste krijg je dan een bevestigingsmail met een link.
Je kan een icoontje voor jezelf kiezen (“avatar”) zoals in veel online diensten, of het wordt herkend als je geregistreerd hebt bij een centraal register van avatars.
Je kan je ssh key (het publieke deel) in de user settings invoegen.

Project

Bij het maken van een nieuw project moet je nadenken over de “namespace”, want het is niet eenvoudig om die nadien te wijzigen. De belangrijkste vraag is of je het project onder je eigen naam/namespace maakt;
– naam/project
of onder de naam van een groep: (zie ook verder Group)
– groupnaam/projectnaam)
Als je samen met anderen wil werken is group aan te raden (zou eigenlijk standaard moeten zijn).

Wijzigen
Om het nadien te wijzigen moet je extra opties aktiveren (Project Settings, Advanced, Expand), Transfer project, Select a new namespace; daar kan je kiezen uit bestaande projecten. Je moet nog eens bevestigen met het intypen van de projectnaam ter controle.
(De rode omgeving geeft aan dat er onverwachten en onaangename gevolgen kunnen zijn, zorg zeker voor een backup).

Je moet daarna ook je instellingen aanpassen op je lokale git-werkstation; je kan de bestaande opvragen met:

git remote -v
wijzig met hetzelde commando als het opzetten:
git remote set-url
git remote set-url origin git@gitlab.com/GrpProject/projectname.git
(zowel de fetch als de push werden aangepast)

Als je in de web-interface een oude URL gebruikt die je bewaard had, krijg je een viendelijke foutmelding (en wordt je indien mogelijk doorverwezen):

Project ‘username/projectname’ was moved to ‘GrpPrjname/projectname’. Please update any links and bookmarks that may still have the old path.

Prive of publiek
Gitlab laat op dit moment toe om een account aan te maken en je project in te stellen als:

  • publiek open source project
  • privé project

Het privé project belet je niet om toch met anderen samen te werken.
Voor het project heb je Settings: “General-Members-Integrations-Repository-Pipelines-Pages-Audit Events”; kies “Members”, “Select members to invite”. Rol en vervaldatum kunnen ingesteld worden.

Repository
(upd 12-10-2018)
Als je het project via de webinterface (website) van GitLab aanmaakt, kan je
* de repository klaarmaken om met een “clone” commando af te halen (initialisatie van de “master”); daarbij kan je de README.md invullen.
* onmiddellijk een LICENSE kiezen; met een eenvoudige klik kan je een licentie bestand toevoegen aan je repository. Je kan kiezen uit een lijstje waarin bv GPL en andere licenties voorkomen. Als je bv GPL3 kiest, wordt er een bestand LICENSE gemaakt met als inhoud de GPL3, en als commit geregistreerd.
Afhalen met:
git clone git://git@gitlab.com:userORgroup/projectname.git

Groep
Daarvoor maak je een groep aan (menu “+”, new group), die je een naam naar keuze geeft; ik hou hem vrij algemeen omdat het gemakkelijk is om veel projecten te delen met 1 groep.

Daarna ga je de leden voor de groep kiezen. Zelf ben je al lid doordat je de groep gemaakt hebt. Je kan een andere account opzoeken in de bestaande gitlab accounts, en lid maken van de groep. Je kan zoeken op naam, e-mail adres. Je kan de duur instellen van het lidmaatschap, en het niveau (Guest, Reporter, Developer, Master, Owner); Owner ben je zelf.

De andere partij krijgt dan een mail met “Access to the NewGroupName group was granted”. Hij kan met een klik weer uit de groep stappen.

Die andere account kan natuurlijk ook een andere account van jezelf zijn, waarbij je bv thuis een andere account gebruikt dan op het werk.

Groepsproject
Het is de bedoeling dan een nieuw project te maken binnen die groep. Je kan een bestaand project aan die groep toevoegen / overzetten van persoonlijk project naar groepsproject; je gaat het importeren als het ware, maar dat houdt in dat de naam van het project (url) verandert, en dat kan onverwachte problemen geven wordt opgemerkt door gitlab. Je kan natuurlijk ook gewoon een nieuw project maken en daar de bestaande code van het moment in invoeren.

Rechten
De volgende stap is dan de toegangsniveau’s instellen. Hier bepaal je de fijnere betekenis van bv Developer; maar ze hebben al een ingevulde standaardbetekenis volgens deze tabel: (Permissions).
Rondkijken kan iedereen, labels toekennen bijna iedereen, en de Master kan een project maken in de groep.

Afhalen
(upd 2017-09-17)
Als je ingelogd bent op de site kan je ook in je browser door de broncode bladeren; je ziet het voorgesteld als een bestandssysteem met betanden. Je kan iedere individuele file bekijken of afhalen als download.
Op hoger/het hoogste niveau kan je ook het project afhalen (symbool van pijl naar beneden op plat streepje); je krijgt dan de keuze aangeboden om het als een gecomprimeerd pakket (bv tar.gz) te downloaden.

Documentatie-wiki
Eén van de opties in de linkermenubalk van GitLab is de wiki, die je kan gebruiken voor documentatie. Het startscherm heeft een knop “Create your first page”.

Issue tracker
De issue tracker wordt gebruikt bij het maken van voorstellen (feature proposal), fouten te melden (bug reporting), enz.
Issue tracker menu leidt naar de lijst of naar het issue board, waar je issues kan slepen naar bv de labels “To Do”, “Doing”, en andere zelf te maken onderverdelingen, waarnaar ze ook verder gesleept kunnen worden. Zo krijgen de issues een traject.

8/6/2017

“Pro Git”-boek ook in Nederlandstalige versie

Filed under: — cybrarian @ 3:47 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)

Pro Git
Het boek is origineel in het Engels uitgegeven, en is in tweede versie te vinden op https://git-scm.com/book/en/v2
Geschreven door Scott Chacon en Ben Straub en uitgegeven bij Apress.
Ze kozen voor de “Creative Commons Attribution Non Commercial Share Alike 3.0 license”, waardoor het ook vertaald kan worden.
Een papieren versie bestaat ook en is waarschijnlijk te vinden via Amazon.com.

De Nederlandstalige versie (is gebaseerd op de eerste versie) en bevat:

6/6/2017

git

Filed under: — cybrarian @ 2:04 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)

Git is het broncode-beheersysteem dat opgestart werd door Linus Torvalds, en nu door/voor honderdduizenden projecten gebruikt wordt. Het maakt samenwerken aan broncode en aftakken plus terug samenvoegen mogelijk. Het is een client-server systeem, waarbij het serverdeel ook gebruikt kan worden van een hoster die het als online dienst aanbiedt, zoals github, gitlab, sourceforge…

ClientSecureConceptTerminologieCommando’sVragenLinks – ..gebruik..
Images: “Pro Git book” by Scott Chacon en Ben Straub, Creative Commons SA licentie


Client
git is het commando op de commandolijn, dat je kan zoeken in je software repository voor installatie (in bv OpenSUSE zoek je in Yast naar “git”, dat zal de nodige software-onderdelen afhalen, een 15-tal; * zie dependencies hier ).
De server (deamon) moet je apart installeren, maar die heb je niet nodig als je een externe dienst gebruikt.

Secure
Voor de communicatie van git heb je een publiek/private sleutel nodig; als je die nog niet hebt, in de terminal:
ssh-keygen -t rsa -C "mijnemail@mijndomein.tld" -b 4096
Resultaat in ~/.ssh/id_rsa.pub
Als je een online dienst gebruikt als gitlab, krijg/maak je een combinatie e-mail (of username) en wachtwoord. Daarmee moet je in de online instellingen je public key invoeren.
Per e-mail krijg je een bevestiging (en ook zichtbaar in de online dienst).

Concept

  • git bewaart een soort “snapshot” van een projectdirectory, waarin het een file bewaart als die veranderd is, anders een ‘link’ naar de bestaande file (in vorige snapshot)
  • git werkt zo veel mogelijk lokaal. Je hebt zelf, lokaal, een “werkdirectory”, een “staging area” en een “repository” (git directory)
  • je haalt het/een project naar je werkdirectory met clone (of “checkout”)
  • lokaal is een gewijzigde file “changed”, “staged” of “comitted”
  • het gebruikt je username en e-mail adres naast de ssh keys
  • om te vermijden dat allerlei lokale tijdelijke bestanden (van bv tekstverwerker) in je repository terechtkomen, kan je een “.gitignore” bestand gebruiken (vb).

Terminologie:

“Untracked” files: bv maak test.txt = nieuw bestand vastgesteld. (niet “in” git)
“Tracked”: bestand wordt opgevolgd door git (“index”). Na bv git add test.txt – staat dan als “new file” in status.
“Unmodified” files: bestanden die in opvolging staan (1e added) maar niet veranderd zijn sindsdien (lokaal, door jezelf).
“Modified”: bestanden in opvolging (tracked) en waar je aan gewerkt hebt. Ze zijn nog niet “staged”, dat doe je met “git add”.
“Staged” : changes to be committed; bestand in opvolging dat veranderd is én klaar staat om met een commit opgenomen te worden in de repository.
“Staging” area: waar Git de wijzigingen volgt. Op te volgen bestanden moeten in de staging area terechtkomen met git add. Deze wordt later gesynchroniseerd naar je lokale repository, die later naar de online kan geduwd worden.
“Comitted”: bestanden die staged zijn finaal in je lokale repo* opnemen met commit en voorzien zijn van commit messages, een korte/lange beschrijvende tekst die later ook zichtbaar wordt voor deze commit.
*(er is nog niet gesynchroniseerd met de online repo)
Master: standaard aangemaakte ontwikkelingstak, stam van de ontwikkelingsboom. Meestal dus de branch waarvan andere afgeleid worden.
Branch: (zij)tak, afgesplitst van tak of master (deelontwikkelingen doen, onderscheid maken tussen development en release, ..). Voor git een (verzetbare) pointer (met label) naar een commit.
Head : een soort pointer die aangeeft welke snapshot van de branch lokaal aktief is (“checked out”).
Tag : referentie om bepaald punt in ontwikkeling te markeren
Node: iedere commit maakt een nieuwe node of knooppunt in de ontwikkelingsboom.
.
(https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)

(ingekort 29/9; Zie ook git commando’s, vb, problemen)

(meer…)

Powered by WordPress