At være social med git

Det følgende er en lille oversættelse af en tekst jeg faldt over, udgivet på engelsk i tildeverse’s zine af ubergeek.

At være social med git #

Introduktion #

Et undervurderet socialt aspekt i tildeverset er muligheden for at samarbejde via kode eller skabelsen af dokumenter. Mange folk tænker at det er “loner work”, når det i virkeligheden, kan være meget mere end det!

En god mulighed for at socialisere mens man laver materiale som kildekode, eller dokumenter, er via git. Git er generelt brugt for kildekode kontrol, men det kan blive bruge for enhver arbitrær ikke-binær formatteret fil: To-do lister, kalendar begivenheder, eller bare simple tekst-filer, som denne.

Introduktion til Git #

Git er et command-line tool, som er tilgængelig på de fleste operativ systemer. og installeret på alle tilde servere (Alle jeg kender til i det mindste), og det er af en god årsag: Det er et meget kraftigt værktøj, brugt til at håndtere konfigurations filer, kildekode for projekter fra internettet (Github er en af de mest besøgte hjemmesider på internettet, som et eksempel), og mange andre grunde. ~team bruger sågar git til at redigere deres hjemmeside!

Git virker ved at lave en slags database som tracker ændringer lavet til alle filer i et “repo” eller “repository”. Et repository er bare en mappe med filer, som også har git database filer i samme mappe. En af de bedste kvaliteter ved dette system er at enhver som “kloner” et repo (mere om det senere) har en komplet kopi af hele projektet historie! Hvilket gør det meget resistent til ting som at en server er nede :)

Commando’en “git” gør ikke meget i sig selv, udover at spytte noget hjælpe information ud (hvilket er brugbar information). Git virker i faser: rediger en fil, commit ændringerne lokalt, og da efter push ændringerne til et andet sted (Oftest til en delt lokation for mange folk, som eks. Tildegit).

Der er mange frontends til git. Tildegit bruger en software-pakke som hedder “Gitea”. Github bruger deres egen. Gitlab er en anden. Der faktisk en del derude.

Git samarbejde #

Der et par forskellige måder at samarbejde på ved at bruge git. En af måderne er at enhver bruger har en kopi af git repo’et lokalt som de kan arbejde på. Når en person er færdig med deres arbejde, “commit’er” de deres ændringer (Det betyder at de markere at alle deres ændringer skal trackes i deres lokale kopi). Før de starter deres arbejde, “pull’er” de den anden person’s ændringer til deres lokale kopi, og efterfølgende arbejder videre.

Dette virker fint, hvis der kun er en anden person som arbejder på projektet sammen med dig. Men, hvad hvis der er 3? eller 10? eller 50? Det bliver let svært at holde styr på hvis kopi du har pull’et ind. I dette tilfælde, bruger de fleste grupper et centralt sted til at opbevare deres repo, hvorfra at alle pull’er, og npr de er færdige med deres lokale ændringer, push’er de deres ændringer til den centrale opbevaringslokation.

En anden kvalitet ved git er “branches”, hvor du kan “stage” ændringer til at blive “merged” ind senere, og som du ikke behøves at bekymre dig om du træder på andres’ ændringer indtil du er færdig med dine.

Hvis du ønsker at alle kan foreslå ændringer, men at du (eller et team) kontrollere hvad bliver puttet ind som “the one truth”, så kan andre foreslå en ændring i deres egne lokale kopi, som du kan review før du merger deres ændring ind.

Gitea gør det meste af denne process lettere ved kalde den en “Pull request”. Ved at udføre en pull request (også kaldet en PR), Gitea forker repo’et til en lokal kopi ejet af brugeren som laver PR’en (eksempelvis dig selv), hvor du kan lave din ændring. Dette åbner en speciel “ticket” som hedder en pull request ticket.

Fra en shell ser processen sådan her ud:

git clone https://tildegit.org/ProjectX/neatX.git
git checkout -b FeatureY
vi ./module/Zimm.sh (Editing the file ./module/Zimm.sh)
touch ./subModule/NewFile

Med ovenstående har du lavet din ændring, men hvis du gør følgende:

git status

Den vil sige at der intet er at gøre, men at du har untracked ændringer. git status er meget hjælpsom til at vise dig hvad du er nødt til at gøre for at din ændring bliver færdiggjort. Lad os commit ændringerne lokalt.

git add ./subModule/NewFile
git commit -am "FeatureY changes, ready!"

./module/Zimm.sh eksistere allerede, så du er ikke nødt til at gøre noget, udover at commit. ./subModule/NewFile er ny, så vi er nødt til først at tilføje den til repo’et, for at tracke filen.

Så nu er disse ændringer i en branch i din lokale kopi. Hvis du vil have nogen til at give feedback eller review dine ændringer, er du nødt til at give dem en specifik lokation, og måde at “pull” din “remote” på (en remote er en kopi af git repo’et, som du ikke ejer). Som eksempel, kan jeg være på ~yourtilde, og din kopi er på ~team (hvor dit ~team login navn er FeatureXUSer), og jeg (ubergeek) vil pull ændringerne derfra for at merge dem ind på mit repo (jeg ejer repo’et)

git remote add -f FeatureXUser ssh://ubergeek@tilde.team:~FeatureXUser/repos/ProjectX
git fetch FeatureXUser
git merge ..FeatureXUser/FeatureY

Det ovenstående tilføjer din kopi som en “remote” for mig, fetch’er alle dine ændringer og branches, og efterfølgende merger din FeatureY branch ind i min “main” branch. Det betyder at alle dine ændringer nu er “live”.

Gitea gør en masse af dette arbejde for dig, i en web-based UI, og gør endda mere ben-arbejde (Laver en ticket, notificere repo ejeren eller ejere af en forslået ændring, etc etc).