Versionsmanagement-Tipps: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) (→Git) |
Codica (Diskussion | Beiträge) |
||
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 100: | Zeile 100: | ||
* Holen von Änderungen vom Server | * Holen von Änderungen vom Server | ||
git pull | git pull | ||
+ | |||
+ | === Zweige === | ||
+ | |||
+ | ==== Erzeugen von Zweigen ==== | ||
+ | Einen Branch/Zweig erzeugt man am einfachsten so: | ||
+ | git checkout -b NEUERZWEIG | ||
+ | |||
+ | ==== Wechseln des Zweigs ==== | ||
+ | Zu einem anderen Zweig wechselt man mit | ||
+ | git checkout ZWEIG | ||
+ | |||
+ | Der Standard-Zweig nennt sich normalerweise <code>master</code> oder <code>main</code>. | ||
+ | |||
+ | ==== Auflisten von Zweigen ==== | ||
+ | |||
+ | Die vorhandenen lokalen Zweige listet man mit | ||
+ | |||
+ | git branch | ||
+ | |||
+ | Die Zweige des entfernten Repository mit | ||
+ | git branch -r | ||
+ | |||
+ | Dieser Befehl schaut nur ins lokale Repository, um die Zweige des entfernten Repository anzuzeigen. Um sicher zu sein dass die Liste aktuell ist, bitte vorher folgenden Befehl nutzen: | ||
+ | git fetch --all | ||
+ | |||
+ | Um zuerst die zuletzt geänderten Git-Zweige anzuzeigen, nutzt man | ||
+ | git branch --sort=-committerdate | ||
=== Git Merge === | === Git Merge === | ||
Siehe [https://git-scm.com/book/de/v1/Git-Branching-Einfaches-Branching-und-Merging Anleitung zum Einfachen Branching und Merging] | Siehe [https://git-scm.com/book/de/v1/Git-Branching-Einfaches-Branching-und-Merging Anleitung zum Einfachen Branching und Merging] | ||
+ | |||
+ | === Ändern des letzten commits === | ||
+ | |||
+ | Manchmal vergisst man eine Datei beim Commiten. Wenn es den letzten commit betrifft, ist die Fehlerbehebung einfach: | ||
+ | |||
+ | git add FEHLENDE_DATEI | ||
+ | git commit --amend --no-edit | ||
+ | |||
+ | === Zugang zu Git-Server über nicht Standard-SSH-Port === | ||
+ | |||
+ | Wenn man (z.B. in einem [[Docker]]-Container) einen git-Server so eingerichtet hat, dass man ihn nur über einen [[SSH]]-Port erreicht, der nicht dem Standard-SSH-Port 22 entspricht, sollte man das <code>ssh://</code>-Schema nutzen: | ||
+ | git clone ssh://USER@SERVER:PORT/REPOSITORY | ||
+ | |||
+ | === Anzeigen der Änderungen einer Datei === | ||
+ | |||
+ | Um festzustellen, welcher Commit für die jeweilige Zeile in einer Datei verantwortlich ist, benützt man den Befehl | ||
+ | |||
+ | git blame DATEI | ||
+ | |||
+ | Um dazu auch die Commit-Message anzuzeigen, verwendet man folgendes leicht von [https://stackoverflow.com/questions/44177174/how-to-display-commit-message-along-with-blame-command ElpieKay] abgewandeltes Skript: | ||
+ | <pre> | ||
+ | git blame -l DATEI | while read hash others; | ||
+ | do | ||
+ | echo hash $others "|Subject:" $(git log -1 --pretty=%s $(echo $hash | sed 's/\^//g') ) | ||
+ | done | ||
+ | </pre> | ||
+ | |||
+ | === Erstellen von Changelog === | ||
+ | |||
+ | Es gibt Diskussionen, ob man aus der Git-Historie ein Changelog schreiben kann. Und es gibt dafür Tools. | ||
+ | |||
+ | Siehe | ||
+ | * https://git-cliff.org/ | ||
=== Weiteres zu Git === | === Weiteres zu Git === | ||
Zeile 109: | Zeile 169: | ||
* [http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Getting started] | * [http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Getting started] | ||
+ | * [https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/ Bessere Commit Messages] | ||
+ | * [https://www.freecodecamp.org/news/git-internals-objects-branches-create-repo/ Wie arbeitet Git intern?] | ||
+ | |||
---- | ---- |
Aktuelle Version vom 23. April 2024, 11:19 Uhr
Siehe oldCt:Versionsmanagement-Tipps
Das Versionsmanagementsystem CVS wird nach und nach von Subversion (SVN) oder auch verteilten Systemen wie Mercurial abgelöst.
Subversion-Server
Folgende Schritte sind für einen einfachen Subversionserver mit einem Repository nötig:
Einrichten eines Repository
- Einrichten eines Repository auf dem Server mit Hilfe des Utility svnadmin:
svnadmin create myRepo
- Dadurch wird unterhalb des aktuellen Verzeichnisses ein neues Repository angelegt (im Prinzip eine Verzeichnisstruktur für SVN-Verwaltungsdaten und die eigentlichen Inhalte).
Zugriffsberechtigungen
- Editieren der Datei
conf/svnserve.conf
:password-db=passwordDatei
Name der Passwort-Dateirealm=AuthUmgebung
wird als Teilschlüssel zwischen Server und Client ausgetauschtanon-access=none
kein anonymer Zugriffauth-access=write
authentifizierte User können Lesen und Schreiben
- Erstellen der
passwordDatei
(im selben Verzeichnis wiesvnserve.conf
:
[users] user1=passwort1 user2=passwort2
Serverstart
- Starten des Servers mit
svnserve -d --foreground
- bzw. mit Angabe des Wurzelverzeichnisses:
svnserve -d --foreground -r /wurzelverzeichnis
- In der Firewall muss der betroffene Port freigegeben werden.
Automatischer Start bei Systemboot
- Anlegen eines speziellen Users für svnserve mit
useradd svnserve
- Erstellen einer Datei
/etc/init.d/svnserve.sh
mit folgendem Inhalt:
#! /bin/sh REPOS_DIR=/home/svnserve/repos start-stop-daemon --start --chuid svnserve --exec /usr/bin/svnserve -- -d -r $REPOS_DIRvs20067:
- Ausführbar machen (als root):
chmod +x /etc/init.d/svnserve.sh
- Installieren für die User-Runlevel:
update-rc.d dhSvnServe.sh defaults
- Siehe auch das automatische Starten von svnserve jedenfalls unter Debian
Subversion-Client
- Der Zugriff mittels des Clients
svn
erfolgt dann z.B. so:
svn --editor-cmd joe --username user1 --password passwort1 --import meinBestehendesArbeitsverzeichnis svn://IP-AdresseDesServers/myRepo
- Danach muss übrigens ein Checkout erfolgen.
Mercurial
Mercurial ist wie Git ein verteiltes Versionsverwaltungssystem.
- Mercurial: The Definitive Guide (Englisch) von Bryan O'Sullivan
- Zusammenarbeit zwischen Netbeans und Mercurial
Git
Git ist ein verteiltes Versionskontrollsystem.
Git Konfiguration
Es kann man auch als Server-Client-System einsetzen:
- Einrichten des GIT-Systems
git config --global user.name "Max Mustermann" git config --global user.email "muster@mann.de"
Einrichten eines Git-Repository
- Einrichten eines GIT-Repository auf einem Server server.de
cd ~ mkdir myproject git init touch README.txt git add . git commit -a -m "Erstversion" git checkout -b tmpBranch #Wechsel weg vom Master, sonst ist dieser für Remote-Schreibzugriffe gesperrt
- Einrichten eines GIT-Repository auf dem Client
git clone user@server.de:myproject/.git
Arbeiten im Projekt
- Hinzufügen von Dateien
git add . git commit -a -m "Kommentar" git push origin master
- Holen von Änderungen vom Server
git pull
Zweige
Erzeugen von Zweigen
Einen Branch/Zweig erzeugt man am einfachsten so:
git checkout -b NEUERZWEIG
Wechseln des Zweigs
Zu einem anderen Zweig wechselt man mit
git checkout ZWEIG
Der Standard-Zweig nennt sich normalerweise master
oder main
.
Auflisten von Zweigen
Die vorhandenen lokalen Zweige listet man mit
git branch
Die Zweige des entfernten Repository mit
git branch -r
Dieser Befehl schaut nur ins lokale Repository, um die Zweige des entfernten Repository anzuzeigen. Um sicher zu sein dass die Liste aktuell ist, bitte vorher folgenden Befehl nutzen:
git fetch --all
Um zuerst die zuletzt geänderten Git-Zweige anzuzeigen, nutzt man
git branch --sort=-committerdate
Git Merge
Siehe Anleitung zum Einfachen Branching und Merging
Ändern des letzten commits
Manchmal vergisst man eine Datei beim Commiten. Wenn es den letzten commit betrifft, ist die Fehlerbehebung einfach:
git add FEHLENDE_DATEI git commit --amend --no-edit
Zugang zu Git-Server über nicht Standard-SSH-Port
Wenn man (z.B. in einem Docker-Container) einen git-Server so eingerichtet hat, dass man ihn nur über einen SSH-Port erreicht, der nicht dem Standard-SSH-Port 22 entspricht, sollte man das ssh://
-Schema nutzen:
git clone ssh://USER@SERVER:PORT/REPOSITORY
Anzeigen der Änderungen einer Datei
Um festzustellen, welcher Commit für die jeweilige Zeile in einer Datei verantwortlich ist, benützt man den Befehl
git blame DATEI
Um dazu auch die Commit-Message anzuzeigen, verwendet man folgendes leicht von ElpieKay abgewandeltes Skript:
git blame -l DATEI | while read hash others; do echo hash $others "|Subject:" $(git log -1 --pretty=%s $(echo $hash | sed 's/\^//g') ) done
Erstellen von Changelog
Es gibt Diskussionen, ob man aus der Git-Historie ein Changelog schreiben kann. Und es gibt dafür Tools.
Siehe
Weiteres zu Git