Versionsmanagement-Tipps: Unterschied zwischen den Versionen

Aus CodicaTipps
Zur Navigation springen Zur Suche springen
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 139: Zeile 139:
   git commit --amend --no-edit
   git commit --amend --no-edit


=== Zugang zu Git-Server über nicht Standard-SSH-Port ===
=== Anzeigen der Änderungen einer Datei ===


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:
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>
 
=== Kommunikation mit Remote Repositories ===
 
 
==== 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
   git clone ssh://USER@SERVER:PORT/REPOSITORY


==== Authentifizierung bei Github ====
Zur Authentifizierung bei GitHub braucht man entweder ein Personal Access Token oder man behilft sich mit einem Credential Helper.
Dazu installiert man das Package git-credential-oauth
  sudo aptitude install git-credential-oauth
und gibt git mit, dass es diesen Credential Helper nutzen soll:
  git-credential-oauth configure
Beim nächsten Aufruf, z.B. von
  git push
wird man auf eine Authentifizierungsseite im Browser weitergeleitet.
Benutzt man nur das herkömmlich Passwort, erhält man etwa folgende Fehlermeldung:
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentifizierung fehlgeschlagen
=== 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 149: Zeile 190:


* [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?]


* [https://www.freecodecamp.org/news/git-internals-objects-branches-create-repo/ Wie arbeitet Git intern?]


----
----

Aktuelle Version vom 31. August 2026, 21:06 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-Datei
    • realm=AuthUmgebung wird als Teilschlüssel zwischen Server und Client ausgetauscht
    • anon-access=none kein anonymer Zugriff
    • auth-access=write authentifizierte User können Lesen und Schreiben
  • Erstellen der passwordDatei (im selben Verzeichnis wie svnserve.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
 
 

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.

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

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

Kommunikation mit Remote Repositories

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

Authentifizierung bei Github

Zur Authentifizierung bei GitHub braucht man entweder ein Personal Access Token oder man behilft sich mit einem Credential Helper. Dazu installiert man das Package git-credential-oauth

 sudo aptitude install git-credential-oauth

und gibt git mit, dass es diesen Credential Helper nutzen soll:

 git-credential-oauth configure

Beim nächsten Aufruf, z.B. von

 git push 

wird man auf eine Authentifizierungsseite im Browser weitergeleitet.

Benutzt man nur das herkömmlich Passwort, erhält man etwa folgende Fehlermeldung:

remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentifizierung fehlgeschlagen

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