lokal:
git branch -D issue_xyz
remote:
git push origin --delete issue_xyz
Offenbar nicht im CentOS 7.x Paket für git enthalten, daher git-git19 installiert. Gitweb aus dem rpm verlinkt (/var/www/git) und angepasst, ohne ansonsten git19 zu aktivieren.
ite-git ist physisch identisch mit ite-srv24
Schreibzugriff erfolgt stets über ssh mit individuellem User
Anmerkung: Damit man sich per ssh verbinden kann, muss entweder der entsprechende Public-Key hinterlegt werden, oder man benötigt das Passwort für den Linux-Account. (Ggf. beim Admin nachfragen)
- Projekt-Repository anlegen (reines Repository ohne Working Files, Namenskonvention .git )
# um Repository mit den richtigen Berechtigungen anzulegen, # individuellen User (nicht root) benutzen su - nbt cd /srv/git git init --bare --shared test1.git # beschreibbar durch group prod
- Repository Root in /etc/gitweb.conf eintragen
- in /srv/git/test1.git
- Kurzbeschreibung des Projekts als Datei description anlegen
- Project Owner in config eintragen:
[gitweb]
owner = nbt
- Webzugriff http://ite-git/git (mit Authentication, beschränkt auf ITE)
- auf ite-git
cd /srv mv git-repositories git
- auf clients
cd /opt/labs/.git vi config # unter [remote "origin"] neue URL eintragen (url = ssh://nbt@ite-git/srv/git/labs.git)
- das scheint's schon gewesen zu sein
Zugriff per SSH (Gitweb ist nur zum Browsen der Repositories; daher muss der Dateisystem-Pfad (/srv/git/<repo>) benutzt werden):
- Standard Protokoll
git clone nbt@ite-git:/srv/git/test1.git
- git+ssh (liest man ja ab und zu)
git clone git+ssh://nbt@ite-git/srv/git/test1.git
Anmerkung: Unter Windows (mit Git Extensions) hat nur der erste Weg funktioniert.
Repository auf dem Server wie unter Git#zentrales-git-projekt-repository-auf-ite-git einrichten.
Auf dem Client-Rechner remote "origin" definieren und
$ git push --mirror origin
bzw.
$ git push --mirror <user>@ite-git:/srv/git/<project>.git
ausführen.
Anmerkung:
- --mirror bewirkt, dass alle Branches und Tags etc. in das remote Repository eingespielt werden.
$ git clone --bare -l /path/to/repo /srv/git/repo.git $ rm -rf /path/to/repo
Anmerkungen:
- -l: erzeugt hardlinks, anstatt die Dateien zu kopieren (ist der Default)
- Alternative:
git clone --bare --no-hardlinks /path/to/repo /srv/git/repo.git
Gegenüber der Initialisierung von scratch fehlt hier die shared-Einstellung (die --shared Option von clone macht etwas komplett anderes als bei init).
Dazu muss das Repository nur noch Schreibrechte für die Gruppe prod bekommen.
$ chgrp -R prod /srv/git/repo.git $ chmod -R g+w /srv/git/repo.git
Und als letztes muss (sicherheitshalber?) noch ein Eintrag in die config (/srv/git/repo.git/config)
[core]
sharedRepository = true
SeeAlso:
- http://stackoverflow.com/questions/1784506/when-creating-a-git-repository-that-will-be-on-the-server-can-i-convert-it-to-a
- How do I make existing non-bare repository bare? (git FAQ)
- http://serverfault.com/questions/26954/how-do-i-share-a-git-repository-with-multiple-users-on-a-machine
- Setting Up a Shared Repository (gitcvs-migration)
$ mkdir /srv/git/my-repo.git $ cd /srv/git/my-repo.git $ git --bare init --shared $ git --bare fetch /home/alice/myproject master:master
Anmerkungen:
- Ich habe nicht getestet, ob (oder wie) fetch alle branches klont.
- Setting Up a Shared Repository (gitcvs-migration)
Der gitcvs-migration Guide merkt an, dass es andere Workflows neben dem Workflow gibt, bei dem alle in ein zentrales Repository pushen.
Im propagierten Workflow hat jeder Entwickler ein public Repository und es gibt einen Maintainer, der alle Änderungen begutachtet und zusammenführt, und in ein primary public Repository comitted.
Die folgenden Einstellungen sind wichtig für die Commit-Messages und lassen sich später nur mühsam nachholen:
git config --global user.name "nbt" git config --global user.email "j.neubert@zbw.eu"
Der Rest ist Geschmacksache:
git config --global color.status "auto"
Ein globales .gitignore-File kann mit
git config --global core.excludesfile ~/.gitignore
verlinkt werden. Zusätzlich können projektspezfische .gitignores eingebunden werden.
cd /opt/fuseki
# verify being on master branch
# checkin everything
/etc/init.d/fuseki stop
# goto vendor branch
git co jena-fuseki
rsync -rav --delete --exclude=.git* --exclude=log --exclude=DB --exclude=Lucene extracted_dir/ .
git diff && git st
# add any new files
git ci -am "synced from XXX-distribution.tar.gz"
# back to master branch
git checkout master
git merge jena-fuseki
git push
/etc/init.d/fuseki start
Z.T. überholt
1. Unter /srv/git/ ein neues leeres Repository anlegen:
git init --bare --shared REPOSITORY.git
2. Ins eigene home Verzeichnis wechseln.
3. Wenn das SVN Repository die Standardstruktur mit den Ordnern trunk, tag und branch besitzt lautet der Befehl zum Übertragen wie folgt:
git svn clone --trunk=trunk --tags=tag --branches=branch --repack http://ite-svn/repos/ite/REPOSITORY
4. Ins frisch ausgecheckte Repository wechseln cd REPOSITORY
5. und mit
git push --mirror /srv/git/REPOSITORY.git/
ins zentrale Repository senden.
6. Das temporär im eigenen home Verzeichnis angelegte Repository kann jetzt gelöscht werden.
# frischer Branch vom Upstream HEAD
git checkout -b tmp
git fetch upstream
git reset --hard upstream/main
# Ausgewählte Commits einfügen
git cherry-pick <commit-hash>
# temporären Branch pushen (Github bietet Erstellung von Pull Request an)
git push origin tmp:tmpgit branch --set-upstream Issue_LABS-49_dbpedia origin/Issue_LABS-49_dbpedia
Bei neuen Branches funktioniert das nicht - vorher einen spezifischen commit, der vor dem beabsichtigten rebase liegt, pushen:
git push origin 771bd83:refs/heads/Issue_LABS-49_dbpedia
Nach dem Clonen eines leeren Repositories und Committen von Dateien, einmalig
git push origin master
Erst dann wird der Master-Branch auch Remote angelegt.
(z.B. bei Zugriff auf Github)
git clone --config "http.sslVerify=false" https://github.com/jneubert/doc.git
bzw. dauerhaft:
git config --global http.sslVerify false