Genau, nicht pull sondern fetch
Ich habe auch das Nutzen von Commands gelernt. Nicht umsonst kann ich Server Administrieren. Bei Git wird des wohl auch nicht anders sein.
Aber mal ehrlich, wer gibt 5.000 Commands ein um etwas “hochzuladen”, das ist doch eher kontraproduktiv.
Man will doch einfach nur einen Button klicken “Update mal”, wähl seine Files an, setz eine Info was geändert wurde und gut ist.
Lästig ist es aufjedenfall jetzt schon dabei verspürte ich noch nichtmals wirklichen Erfolg.
Nein es gibt ein Command um etwas hochzuladen: push
Es gibt ein Command für das Holen von Änderungen: fetch
Es gibt ein Command zum Mergen: merge
Es gibt einen Shortcut für fetch/merge: pull
Und es gibt ein Command zum Committen: commit
Wieso 5000?
Es sind zwei oder, falls du mit mehreren Leuten am selben Repo arbeitest, drei:
git commit
git fetch & git rebase oder git pull (nur wenn sich am Repo was geaendert hat)
git push
Wo genau ist das Problem?
Manchmal hilft ein Bild, siehe Anhang… (ich habe dieses Bild bei mir auf dem Desktop, hat mir schon oft geholfen).
Nö, ich möchte gerne auch noch Review machen, die Arbeit von anderen fortsetzen bzw. anderen die Möglichkeit geben an meiner nicht vollendeten Arbeit weiterzumachen. Wird mit SVN nur unnötig erschwert.
Wo genau ist das Problem?
Immer noch: Die **vernünftige ** Nutzung unter einer IDE
Wie gesagt, wenn du nur Änderungen einchecken und holen willst, dann lohnt sich Git nicht. Bei Git (und insbesondere GitHub) wird ein Workflow mitgeliefert den man einhalten sollte oder man hat ein Problem.
Dann Schritt 2 des Szenarios: Man selbst hat die Dateien A und C geändert, und jemand anderes die Dateien B, C und D. Und man will diese Änderungen übernehmen. Die Datei C soll dabei 1. überschrieben werden oder 2. ignoriert werden. Jaaa, einfach
git -stash
git -merge -hard
git -pull origin/master/ -someFlag -evenHarder
git -stash pop
git commit --f ein/pfad/zu/datei/c -hardest -butIgnore path/to/repo/branch
git -drop irgendeineID
:twisted: Öhnee… Das kommt jeden Tag vor, und es heißt „IDE“ und nicht „DEWYCWCBNSCTDBST“ (Development Environment Where You Can Write Code But Need Some Console To Do Basic SCM Things") … Da les’ ich doch lieber Geek And Poke: http://geek-and-poke.com/geekandpoke/2012/7/27/simply-explained.html 
Also. Ich habe mir jetzt mal den Clienten von GitHub installiert. Ok,… Ja. Der erste Commit und Push funktionierte auch.
Jetzt stehe ich aber vor einem Problem.
Ich habe das Repo ja nun Lokal erstellt und auch Online neu erstellt. Jetzt habe ich Lokal eine Testdatei hinzugefügt und würde die gerne Committen als auch Pushen lassen.
Gibt es keinen “aktualisieren” Button in der Software? Ich bin verwirrt. Einerseits stellt die Software eine UI zum Arbeiten zur verfügung aber irgendwie doch auch nicht?
man git-rebase?
Keine Ahnung, noch nie benutzt. Aktualisieren ist ein „git add && git commit“. Dann die Commitmessage eingeben und anschließend „git push“.
EDIT: Damn, bei den beiden Beiträgen würde ich jetzt gerne ein merge machen können…
Das heißt ich muss jede einzelne Datei, jeden einzelnen Ordner immer manuell über command hinzufügen?
Wo findet ihr des denn produktiv?
“git add -A” fügt alle Änderungen auf einmal hinzu, “git add .” nur diejenigen die nicht untracked sind. Und “git add -i” bietet sogar ein “Kommandozeilen GUI”.
Wenn ich mir das ganze so durchlese bin ich doch ganz froh, dass wir hier Perforce als zentrales repo benutzen.
Mit einer schönen GUI die nichts weiter ist als ein visueller wrapper um die Kommandozeile. Man hat im Log Fenster sogar direkt eine Übersicht welche perforce Befehle die GUI da eigentlich gerade absetzt für den Fall dass man evtl. doch mal etwas per Kommandozeile machen möchte. Und ansonsten hat man komplett die Wahl ob man jetzt selbst die Komandos einhacken möchte oder lieber per Maus in der GUI rumklickt.
Und natürlich noch der Vorteil das ein zentrales repo mit exklusiven Locks arbeitet, somit läuft man gar nicht in die Gefahr das man selbst File A und C bearbeitet und einchecken will und in der zwischenzeit jemand anderes meinte Files C und D zu verändern.
Habs nun. Werde nun weiter experementieren.
Die GitHub Software erkennt nur änderungen wenn Ordner nicht Leer sind.
Danke für eure Hilfe.
Git kennt nur Dateien. Ein Verzeichnis ist Teil des Namens der Datei. Deshalb gibt es im Git keine leeren Verzeichnisse 
Bei der Bekanntheit von Git eigentlich erstaunlich, dass es etwas ähnliches nicht auch schon gibt. Vllt. habe ich es bisher auch nur noch nicht gefunden. Aber da die meisten Git Nutzer wohl kein Bedürfnis dafür haben sehen die Chancen dafür u.U. wirklich schlecht aus.
[QUOTE=MarderFahrer;23379]
Und natürlich noch der Vorteil das ein zentrales repo mit exklusiven Locks arbeitet, somit läuft man gar nicht in die Gefahr das man selbst File A und C bearbeitet und einchecken will und in der zwischenzeit jemand anderes meinte Files C und D zu verändern.[/QUOTE]
Die Strategie kommt für OpenSource Projekte nur nicht in Frage, nicht mal für Closed Source Projekte mit mehr als eine Hand voll Commitern.
Ich erzähle mal eben ein Schwank aus meinem Leben, um die ganzen Git Newbies mal etwas zu beruhigen. Ich selbst habe erst 2007 mit einer Versionskontrolle angefangen, und zwar war das CVS. Das habe ich allerdings nie richtig tiefer kennengelernt, sondern nur während meiner Abschlussarbeit Dinge eingecheckt.
Kurz danach habe ich mit Subversion begonnen, weil plötzlich überall nur noch von Subversion die Rede war. In den Unternehmen wurde auch SVN immer mehr gefragt, also musste an SVN doch irgendwas Gutes dran sein, dachte ich mir.
Und so lernte ich mit viel Schweiß und in meiner Freizeit mit SVN umzugehen. Es war am Anfang eine Qual, da mir aber kein anderes VCS bekannt war zu dem Zeitpunkt, habe ich eben weitergemacht. Schließlich fand man “SVN Kenntnisse” auch in vielen Stellenausschreibungen wieder.
Und schließlich war es auch so, dass ich mit Subversion meine ersten knapp 4 Berufsjahre “überstanden” habe. Ich habe aber nie in einer Firma gearbeitet, die mit SVN exzessiv Branching betrieben hat, obwohl das doch angeblich so einfach geht mit SVN. In der Theorie zumindest.
Schließlich kam dann ca. 2010 bei mir GIT auf den Schirm. Plötzlich war in den Magazinen nur noch von GIT die Rede und in den Stellenausschreibungen hat man auch vermehrt “SVN/Git Kenntnisse” gelesen.
Zu diesem Zeitpunkt habe ich mich in GIT nur eingelesen, nie damit praktisch etwas gemacht. Ein Grund dafür war die fehlende Integration in eine IDE, EGIT konnte damals nur ganz rudimentäre GIT Kommandos.
Ich fand aber schon damals, dass sich die vielen Vorteile von GIT sehr gut angehört haben. Ich habe aber dann noch 1 Jahr gebraucht, um mir GIT nochmals genauer anzusehen. Also ich das dann über die Konsole gemacht habe und erste Tutorials abgearbeitet hatte, war mir klar, dass ich mit GIT zu 90% so arbeiten könnte, wie ich es mit SVN getan habe.
Nur warum sollte ich dan nüberhaupt wechseln? Und warum genau soll GIT dann soviel besser sein als SVN?
Um das herauszufinden bzw. einzusehen habe ich noch ein Jahr gebraucht. Mittlerweile weiß ich, dass Branching wie selbstverständlich von der Hand gehen muss, ebenso wie das Mergen. Und genau das ist die größte Veränderung in meiner Arbeit mit GIT gegenüber SVN. In SVN ist es eine Qual mit mehreren Feature Branches im Team zu arbeiten. Es sei denn man hat den oft gefragten “SVN Guru” der einem alles abnimmt und man selbst nur committen und updaten muss.
Mit GIT ist jede Scheu einen Branch zu erstellen wie weggeblasen, und zwar auch deswegen, weil der Branch erstmal nur lokal für mich alleine existiert! Das bedeutet, ich kann mir soviele Branches wie ich möchte erstellen, und wenn manche davon auch für andere Entwickler zugänglich sein sollen, dann greifen die entweder auf meinen Branch zu oder ich pushe den Branch in das zentrale Repository. Das alles geht so schnell und stabil von der Hand, das hatte ich bei SVN nie so “gefühlt”.
Im Endeffekt ist es tatsächlich so, dass GIT etwas mehr Kommandos hat und daher auch komplexer ist als SVN. Da es ein dezentralisiertes VCS ist, sind auch die Workflows etwas anders. Allerdings ist das ein sehr sehr großer Vorteil, wenn man durch einen Commit erstmal nur in das lokale Repo eincheckt, statt auf den Server. Denn so kann man seine Commits viel besser organisieren.
Und nun? Also ich habe einige Zeit gebraucht, um mit GIT warm zu werden, und am Anfang habe ich GIT auch genau so wie SVN genutzt. Das ist vielleicht nicht Sinn und Zweck, hat mir aber beim Umstieg geholfen, GIT besser zu verstehen.
Ich habe nun seit ein paar Monaten einen neuen Kollegen, der seit über 7 Jahren mit SVN gearbeitet hat. Er versteht GIT und die Vorteile gegenüber SVN nur schwer und wenn man ihm etwas erklärt, dann kommen immer nur die üblichen Phrasen “geht doch mit SVN genauso” oder “mit SVN geht das viel einfacher”. Um solche Aussagen machen zu können, sollte man doch wenigstens mal 1-2 Proejkte mit GIT umgesetzt haben, oder?
Ich kann hier mit voller Überzeugung sagen: Es geht sogut wie nichts mit SVN einfacher als mit GIT! Es ist tatsächlich so, dass man mit GIT fast die selben Workflows umsetzen kann, wie mit SVN, umgekehrt trifft das zu einem viel kleineren Prozentsatz zu. Das ist aber auch nicht Sinn und Zweck, dass man einfach nur von SVN zu GIT umsteigt ohne etwas an seinen Workflows zu ändern! Das ist das, was viele nicht erkennen. Man kann durchaus erstmal mit SVN Workflows beginnen, irgendwann wird man automatisch merken, dass man hier und da die Vorteile von GIT effizienter nutzen kann, wenn man seinen Workflow einfach anpasst!
EDIT:
Allerdings muss ich eins auch sagen, da GIT keine Benutzerverwaltung/Rechtesystem mitbringt, ist das der größte und aus meiner Sicht auch einzige Vorteil, den SVN gegenüber GIT hat.
Bei GIT benötigt man zusätzliche Extension/Plugins wie gitolite oder gitosis.