Forum: PC-Programmierung Einstieg in Git


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Matthias S. (da_user)


Lesenswert?

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

von Nop (Gast)


Lesenswert?

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.

von Chris K. (Gast)


Lesenswert?

Eigentlich ist Git ganz einfach:

In Case of Fire:
1. Git Commit
2. Git Push
3. Leave Buildig

von Matthias S. (da_user)


Lesenswert?

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.

von guest (Gast)


Lesenswert?

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.

von Horst (Gast)


Lesenswert?

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

von Borislav B. (boris_b)


Lesenswert?

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.
von Matthias S. (da_user)


Lesenswert?

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.
von Konrad (Gast)


Lesenswert?

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)

von ~Mercedes~ (Gast)


Lesenswert?

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

von foo (Gast)


Lesenswert?

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

von Matthias S. (da_user)


Lesenswert?

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?

von Egon N. (egon2321)


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von foobar (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von asd (Gast)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von Matthias S. (da_user)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Matthias S. (da_user)


Lesenswert?

Hi,

Wie ist den da V1 vs. V2 zueinander zu bewerten?
Insbesondere was die absoluten Basics angeht?

: Bearbeitet durch User
von Martin H. (horo)


Lesenswert?

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.

von Nobody (Gast)


Lesenswert?

Wenn schon Microsoft warum dann nicht den Team Foundation Server?

von Cyblord -. (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.