Hi, ich möchte mich jetzt endlich mal mit dem Thema Git beschäftigen. Demnächst werde ich wohl einen kleinen Homserver haben, auf dem ich Docker-Container installieren kann. Derzeit läuft das ganze noch experimentell in der virtuellen Maschine. Auf jeden Fall würde ich dann einen eigenen Docker-Git-Server aufsetzen um GitHub nicht mit meinem Geraffel vollzumüllen. Was ich derzeit aber suche, ist eine gute(!) idealerweise deutschsprachige Anleitung/Einstiegslektüre/Tutorial zum Thema Git. Wenns noch weiterhilft: meine bevorzugte Entwicklungsumgebung ist Visual Studio Community Edition. Vielleicht kann mir da wer was gutes Empfehlen? VG
Ein Standardwerk ist https://git-scm.com/book/en/v2 . Teilweise wohl auf deutsch übersetzt, aber bei technischer Literatur gewöhn Dir besser gleich an, das auf englisch zu lesen.
Eigentlich ist Git ganz einfach: In Case of Fire: 1. Git Commit 2. Git Push 3. Leave Buildig
Nop schrieb: > eilweise wohl auf > deutsch übersetzt, aber bei technischer Literatur gewöhn Dir besser > gleich an, das auf englisch zu lesen. Ja... habe ich mir prinzipiell schon angewöhnt. Aber gerade für die allerersten Schritte ist was in der Muttersprache meistens doch besser, bzw. von mir bevorzugt. Darum auch "idealerweise" ;-) Danke für den Link.
Nop schrieb: > Ein Standardwerk ist https://git-scm.com/book/en/v2 . Teilweise wohl auf > deutsch übersetzt, aber bei technischer Literatur gewöhn Dir besser > gleich an, das auf englisch zu lesen. Die deutsche Version ist "Translations started": https://git-scm.com/book/de/v2 Auf den ersten Blick sind wohl Kapitel 1 & 4 in deutsch. Ansonsten hat Nop recht, besser gleich das englische Original nehmen.
Matthias S. schrieb: > meine bevorzugte Entwicklungsumgebung ist Visual > Studio Community Edition. Und warum nicht was vernünftiges? Die erste Auflage des oben verlinkten Buchs ist komplett auf Deutsch: https://git-scm.com/book/de/v1
Horst schrieb: > Und warum nicht was vernünftiges? Weil's einfach gut ist. "Vernünftiger" geht es kaum :-)
Beitrag #5400853 wurde von einem Moderator gelöscht.
Horst schrieb: >> meine bevorzugte Entwicklungsumgebung ist Visual >> Studio Community Edition. > > Und warum nicht was vernünftiges? Und warum nie rausrücken, was daran unvernünftig/schlecht ist, besseres Vorschlagen und begründen warum?
Beitrag #5400898 wurde von einem Moderator gelöscht.
Beitrag #5400905 wurde von einem Moderator gelöscht.
Beitrag #5400917 wurde von einem Moderator gelöscht.
Beitrag #5400918 wurde von einem Moderator gelöscht.
Beitrag #5400938 wurde von einem Moderator gelöscht.
Chris K. schrieb: > Eigentlich ist Git ganz einfach: > > In Case of Fire: > 1. Git Commit > 2. Git Push > 3. Leave Buildig Nicht ganz so einfach: da fehlt 0) git add -A Siehe auch https://git-man-page-generator.lokaltog.net/ (git ist ein schrulliges Werkzeug, zu dem man wunderbar eine Hassliebe pflegen kann)
Horst meinte:
> Und warum nicht was vernünftiges?
Was hast Du gegen Microsoft? ;--P
Windows ist professionell, keine Frikelware.
Und es hilft der darbenden deutschen Kofferindustrie,
wie wir ja in München sehen konnten. ;-))
mfg
Konrad schrieb: > (git ist ein schrulliges Werkzeug, zu dem man wunderbar eine Hassliebe > pflegen kann) Jo und damit auch nix schiefgeht, gibts coole features: https://blog.sebastian-daschner.com/entries/custom-git-subcommands
Horst schrieb im Beitrag #5400938: > Matthias S. schrieb im Beitrag #5400918: >> Dann weiß ich ja, wo ich >> deine Aussagen einsortieren darf: >> >> Borislav B. schrieb: >>> Horst schrieb: >>>> Witzbold. >>> >>> Dummschwätzer... > > Da kannste dich selbst einsortieren. Egal was ich erwähnen würde, ihr > MS-Trolle würdet es sofort schlecht machen. Ich hätte mich eigentlich schon dafür interessiert, was du vorgeschlagen hättest, und warum du es besser findest. Ob ich es auch besser gefunden hätte, bzw. ob es mir einen Umstieg wert gewesen wäre, steht natürlich auf einem anderen Blatt. Aber da spielt natürlich auch etwas persönliche Vorliebe mit... Aber mit einem dahingerotzten pauschalisierten Satz wüsste ich nicht, was ich anderes damit anfangen soll, oder was meinst du?
Gibt für GIT einige gute Cheat Sheets, such einfach mal danach, da findet sich so einiges. In deinem Fall dürfte das vermutlich auf Gitlab hinauslaufen, Visual Studio wird in der Hilfefunktion vermutlich eh die Einbindung einer Versionsverwaltung erklären. Wobei ich persönlich so etwas nicht zwingend selbst hosten würde, für ein paar private Projekte reicht auch Github/Bitbucket (erlaubt private Repos), da muss man dann nicht am Server rumfrickeln und hat es von überall erreichbar. Backups kann man sich auch bequem mittels Skript auf den NAS ziehen lassen.
Chris K. schrieb: > Eigentlich ist Git ganz einfach: > > In Case of Fire: > 1. Git Commit > 2. Git Push > 3. Leave Buildig 4. Nighmares due to missing: 0. Git Add
Nur zur Info: nen Server brauchst du bei Git eigentlich nicht, nichtmal einen lokalen zentralen Speicher. Git ist mit einem Unterverzeichnis im Arbeitsverzeichnis vollkommen zufrieden.
Matthias S. schrieb: > Ich hätte mich eigentlich schon dafür interessiert, was du vorgeschlagen > hättest, und warum du es besser findest. Ehrliche Meinung: Mercurial. Einfach, weil dort die Kommandos noch einigermaßen so sind, wie sie bei anderen VCSen zuvor (RCS, CVS, SVN) auch waren. Bei Git ist schlicht alles anders. Von vielen Konzepten sind sich Git und Mercurial ansonsten durchaus ähnlich. Git hat'n paar Knöppe mehr. :) Ansonsten ist natürlich jegliche Versionierung besser als gar keine. RCS oder CVS würde ich allerdings heutzutage wirklich keinem mehr empfehlen.
Ich hab die ersten Schritte mit dieser Webseite gemacht: https://rogerdudler.github.io/git-guide/index.de.html Anmerkung: Wenn man das entfernte Repository mit "git init" erstellt hat bekommt man eine Fehlermeldung wenn man rein "push"en will, weil das entfernte Respository dazu "bare" sein muss, d.h. es hat selber keine ausgecheckte working copy. Damit es geht, erstellt man das leere entfernte Repository mit "git init --bare" Das ist hier erklärt: https://stackoverflow.com/questions/11117823/git-push-error-refusing-to-update-checked-out-branch
Matthias S. schrieb: > ich möchte mich jetzt endlich mal mit dem Thema Git beschäftigen. > [...] > Wenns noch weiterhilft: meine bevorzugte Entwicklungsumgebung ist Visual > Studio Community Edition. Unabhängig von einer IDE würde ich Dir empfehlen, Deine ersten Schritte mit Git -- zum Beispiel beim Durcharbeiten eines der verlinkten Bücher -- nicht mit einer IDE zu machen, sondern tatsächlich auf der Kommandozeile. Dadurch gewinnst Du nicht nur viel bessere Einblicke und Erkenntnisse bezüglich der Funktionsweise und der Möglichkeiten von Git, sondern lernst obendrein auch noch, was Du tun kannst, wenn einmal etwas schief gelaufen ist.
Ich würde ebenfalls empfehlen, git manuell zu bedienen. Mein Ablauf ist für gewöhnlich ungefähr so:
1 | # Letzte änderungen vom server holen |
2 | git pull |
3 | |
4 | # änderungen machen |
5 | |
6 | # tests laufen lassen |
7 | |
8 | # nachsehen, welche Dateien sich geändert haben |
9 | git status |
10 | |
11 | # Dateien, die nicht ins Projekt gehören, in die .gitignore eintragen (einige ignorieren einfach alles, und nutzen "git add -f datei" bei neuen Dateien, damit sie immer bedenkenlos git add -A machen können, finde ich aber unschön) |
12 | echo '*.o' >> .gitignore |
13 | echo 'build/' >> .gitignore |
14 | |
15 | # Änderungen ansehen |
16 | git diff |
17 | |
18 | git add -A oder git add datei # Änderungen an Dateien für nächsten Commit zwischenspeichern |
19 | |
20 | # eventuell wieder am Anfang anfangen, falls man auf den neuesten Commit aufbauen will und keinen merge commit will, falls ein neuer auf dem Server gekommen ist. Kann aber umständlich sein. |
21 | |
22 | # optional einen anderen temporären branch erstellen |
23 | git checkout -b branchname |
24 | |
25 | # Alle Änderungen nochmal betrachten vor dem Commit |
26 | git diff --cached |
27 | |
28 | # Änderungen in lokaler Versionshistorie speichern |
29 | git commit -m "Hinzufügen von Feature XY, see #1234" |
30 | |
31 | # Vorherigen Branch wieder auschecken, falls neuer erstellt |
32 | git checkout master |
33 | |
34 | # neueste Änderungen nochmal holen |
35 | git pull |
36 | |
37 | # Falls man einen neuen Branch erstellt hatte, eigene Commits nochmal einbauen. Meistens genügt |
38 | git cherrypick <die commits> |
39 | |
40 | # Mögliche merge conflicts beheben |
41 | |
42 | # Tests durchlaufen lassen |
43 | |
44 | # Gemergete änderungen committen |
45 | git commit -m "Merge bla bla" |
46 | |
47 | # änderungen hochladen |
48 | git push |
49 | |
50 | # Falls man zu langsam war, wieder zurück zum schritt "git pull". Oder eventuell mit git reset letzten merge zurücksetzen und zurück zum schritt "git checkout master" |
51 | |
52 | # Falls man einen temporären branch erstellt hatte, diesen optional löschen |
53 | git branch -d branchname |
54 | |
55 | # fertig, zurück zum anfang |
Manchmal schaue ich noch mit "git log", "git diff" und "git blame", wer wo was kaputt gemacht hat.
Ja genau sowas suche ich eben nicht! ;-) Merge, Commit, Branch,... usw. usf. sind einfach Begriffe, die mir bis dato noch gar nix sagen. Ich muss in Sachen Versionskontrolle mehr oder weniger bei 0 anfangen. Jörg W. schrieb: >> Ich hätte mich eigentlich schon dafür interessiert, was du vorgeschlagen >> hättest, und warum du es besser findest. > > Ehrliche Meinung: Mercurial. Einfach, weil dort die Kommandos noch > einigermaßen so sind, wie sie bei anderen VCSen zuvor (RCS, CVS, SVN) > auch waren. Bei Git ist schlicht alles anders. Danke.
Matthias S. schrieb: > Merge, Commit, Branch,... usw. usf. sind einfach Begriffe, die mir bis > dato noch gar nix sagen. Ich muss in Sachen Versionskontrolle mehr oder > weniger bei 0 anfangen. Die gleich in der ersten Antwort verlinkte Doku https://git-scm.com/book/en/v2 kann ich uneingeschränkt weiterempfehlen. Da wird dir alles von der Pike auf eingeimpft. Schön mit Beispielen, UseCases (wann wähle ich welches Vorgehen?) und ganz genaue Erklärungen und Fallstricke. Da wird das Thema Versionsverwaltung praktisch ab Adam und Eva behandelt. Wenn dir diese Doku (eigentlich ein Mix aus Doku und Tutorial) nicht zusagt, tja, was besseres wirst du nicht finden.
Hi, Wie ist den da V1 vs. V2 zueinander zu bewerten? Insbesondere was die absoluten Basics angeht?
:
Bearbeitet durch User
Kannst ja mal nach "GIT Lernen mit Beispielen" von Xtreme Software GmbH suchen, findet sich als pdf-Download im Internet. Ist 'ne Schritt-für-Schritt-Anleitung, die die Zusammenhänge auch graphisch erläutert.
Nobody schrieb: > Wenn schon Microsoft warum dann nicht den Team Foundation Server? TFS ist schon ein bisschen mehr als nur Versionsverwaltung. Der dortige Standard ist nun aber auch Git. TFVC wird afair nicht weiter entwickelt. Für nur VC ist TFS ist zu fett zu managen, aber wenn man die restlichen Features ebenfalls nutzt (allen voran Work Item Tracking), dann kann man damit wirklich gut und professionell arbeiten.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.