Anfängerprobleme mit git

[Jan Bruns]

Hallo,

da ich selbst bisher immer svn genutzt habe, und git eben nur selten mal
fürs auschecken irgendwelcher Projekte, an denen ich selbst nix zu
verbessern hatte, habe ich jetzt ein Paar Anfängerprobleme mit git.


Als Beispielproblem wollte ich in einem selbst angelegten Projekt
(Userzahl: nur ich, auf Dauer erwartete Branch-Anzahl: 1) von einem
Server (hier gitlab) einen Tippfehler in einer Datei korrigieren.

Mit den folgenden Kommandos hat das zwar funktioniert (Vorarbeit:
Abstimmung von ssh-keys):


git init

git remote add origin g...@gitlab.com:username/project.git

git fetch g...@gitlab.com:username/project.git

git pull g...@gitlab.com:username/project.git

[edit file example/somefile]

git status

git commit -m "fix typo in example program"

git add example/somefile

git commit -m "fix typo in example program"

git push

git push --set-upstream origin master



aber irgendwie erscheint mir das zurechgefrickelt, und ich verstehe gar
nicht wirklich, was ich da mache, bzw. wann wo welche Details wie in das
Versionsmanagment kommen, bzw. eben nicht.


Wie ist das bspw. mit fetch/pull? Was davon kommt "svn update" am
nächsten? Also ein automatisches update aller Dateien, ausser denen, an
denen lokal bereits Änderungen vorgenommen wurden.

Und wieso sieht commit zwar, daß ich eine Datei verändert habe, und ist
dann aber zu faul sich mal zu überlegen, daß diese Änderung vllt. der
Grund für's Aufrufen von commit gewesen sein könnte? Muss ich wirklich
immer explizit die schon vorhandene, modifizierte Datei adden?

Und mit "git push" gab es eine Fehlermeldung dazu, daß ein Branch gewählt
werden müsse. Inwiefern ist denn nicht klar, daß das solange nichts
weiter gesagt ist, der gleiche Branch sein soll, wie beim auschecken?

Achso, und managt übrigens git auch Zeilenumbrüche usw. bei Text-Dateien
so, daß auch Nutzer anderer Betriebssysteme damit zurecht kommen?

Gruss

Jan Bruns

[Jan Bruns]

Am Fri, 01 Jul 2022 04:33:42 +0000 schrieb Jan Bruns:

> Und mit "git push" gab es eine Fehlermeldung dazu, daß ein Branch
> gewählt werden müsse. Inwiefern ist denn nicht klar, daß das solange
> nichts weiter gesagt ist, der gleiche Branch sein soll, wie beim
> auschecken?

Die Fehlermeldung lautete tatsächlich:

git push

fatal: Der aktuelle Branch master hat keinen Upstream-Branch.
Um den aktuellen Branch zu versenden und den Remote-Branch
als Upstream-Branch zu setzen, benutzen Sie

git push --set-upstream origin master

Was immer mir das sagen will.


Und noch eine Frage:

Auf einem anderen Rechner habe ich keinen ssh key manager installiert
(und möchte das dort eigentlich auch nicht nachholen), sondern pflege
dort (wie auch hier, eigentlich), ssh mit "-i idfile" aufzurufen. Das
ausdrückliche angeben der ID hat auch den Vorteil, daß man auch so ein
bisschen sieht, wo man da gerade am machen ist.

Leider fand ich aber bisher keinen git-switch dafür. Sicherlich habe ich
noch nicht gründlich genug gesucht?

Gruss

Jan Bruns

[Laurenz Trossel]

On 2022-07-01, Jan Bruns <eb...@abnuto.de> wrote:

> fatal: Der aktuelle Branch master hat keinen Upstream-Branch.
> Um den aktuellen Branch zu versenden und den Remote-Branch
> als Upstream-Branch zu setzen, benutzen Sie
> git push --set-upstream origin master
> Was immer mir das sagen will.

Das bedeutet, daß du git mitteilen musst, in welchen remote-Branch du
pushen möchtest.

Git schreibt nicht vor, daß dein lokaler Branch A auch im remote repository
A heissen muss.

> Leider fand ich aber bisher keinen git-switch dafür. Sicherlich habe ich
> noch nicht gründlich genug gesucht?

Ich benutze dafür ~/.ssh/config

Host github.com
User git
IdentityFile ~/.ssh/github_key

Host github-anderer_user
Hostname github.com
User git
IdentityFile ~/.ssh/anderer_key

> git init
> git remote add origin g...@gitlab.com:username/project.git
> git fetch g...@gitlab.com:username/project.git
> git pull g...@gitlab.com:username/project.git

Das kann man kombinieren als
git clone g...@gitlab.com:username/project.git

Dann gibt es auch obiges Problem beim Push nicht.

[Jan Bruns]

Laurenz Trossel:

> Das bedeutet, daß du git mitteilen musst, in welchen remote-Branch du
> pushen möchtest.

> Git schreibt nicht vor, daß dein lokaler Branch A auch im remote
> repository A heissen muss.

Lokal hiess aber doch sowieso nix "master". Und in der Vezeichnisstruktur
taucht der Name auch überhaupt nicht auf. Das kann doch irgendwie nicht
sein, daß ich bei jedem Projekt einzeln jedesmal beim comitten erstmal
auf die guthub-Seite gehen muss, um nachzuschlagen, wie dieser
vereinzelte Branch bei dem Prjekt genau hiess.

Und wieso muss nur beim hochladen (und nicht beim runterladen) dieser
Branchname angegeben werden?

> Ich benutze dafür ~/.ssh/config

> Host github.com User git IdentityFile ~/.ssh/github_key

Dank, dass werde ich gleich mal ausprobieren!

>> git init git remote add origin g...@gitlab.com:username/project.git git
>> fetch g...@gitlab.com:username/project.git git pull
>> g...@gitlab.com:username/project.git
>
> Das kann man kombinieren als
> git clone g...@gitlab.com:username/project.git

> Dann gibt es auch obiges Problem beim Push nicht.

ja? Also ohne "git init" geht hier bisher überhaupt nichts, was mit
Versionsmanagment zu tun hat. Konkret weiss dann commit überhaupt nicht
bescheid, daß das Verzeichnis überhaupt was mit git zu tun hat. Und
"clone" scheint auch nix weiter als download zu machen, und insbesondere
nicht die geladenen Dateien zum Versionsmanagment anzumelden.
Jedenfalls war das mein bisheriger Eindruck.

Gruss

Jan Bruns

[Christian Weisgerber]

On 2022-07-01, Jan Bruns <eb...@abnuto.de> wrote:

> aber irgendwie erscheint mir das zurechgefrickelt, und ich verstehe gar
> nicht wirklich, was ich da mache, bzw. wann wo welche Details wie in das
> Versionsmanagment kommen, bzw. eben nicht.

Aus eigener Erfahrung empfehle ich, die ersten Kapitel des Git-Buchs
zu lesen, um ein Verständnis für die grundlegenden Zusammenhänge
zu entwickeln.
https://git-scm.com/book/en/v2

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Stefan Reuther]

Am 01.07.2022 um 06:33 schrieb Jan Bruns:
> Als Beispielproblem wollte ich in einem selbst angelegten Projekt
> (Userzahl: nur ich, auf Dauer erwartete Branch-Anzahl: 1) von einem
> Server (hier gitlab) einen Tippfehler in einer Datei korrigieren.

Sobald ein Server im Spiel ist, gibt es mindestens zwei Branches: deinen
("master") und den des Servers ("origin/master").

> Wie ist das bspw. mit fetch/pull? Was davon kommt "svn update" am
> nächsten? Also ein automatisches update aller Dateien, ausser denen, an
> denen lokal bereits Änderungen vorgenommen wurden.

Während svn (und cvs) dir beim Update ungefragt und kommentarlos die
Dateien mit Merge-Konflikten zerschießen, musst du bei git immer
explizit sagen: jetzt möchte ich mergen, mit allen Konsequenzen (und der
Möglichkeit, abzubrechen und auf später zu verschieben).

Wenn du keine lokalen Änderungen hast, ist 'git pull' das Äquivalent zu
'svn update'.

Wenn du lokale Änderungen hast, kommt 'git stash; git pull; git stash
pop' dem am nächsten, wobei ich beim pull ganz stark die Option
'--rebase' bevorzugen würde, weil das eine schönere History produziert.

> Und wieso sieht commit zwar, daß ich eine Datei verändert habe, und ist
> dann aber zu faul sich mal zu überlegen, daß diese Änderung vllt. der
> Grund für's Aufrufen von commit gewesen sein könnte? Muss ich wirklich
> immer explizit die schon vorhandene, modifizierte Datei adden?

Ja, musst du. Es gibt aber zahllose Optionen, die dir das vereinfachen.
'man git commit' listet gleich am Anfang fünf Möglichkeiten.

Dafür bietet das Möglichkeiten, von denen man bei svn nur träumen kann
(z.B. 'git add -p').


Stefan

[Laurenz Trossel]

On 2022-07-01, Jan Bruns <eb...@abnuto.de> wrote:

> Das kann doch irgendwie nicht sein, daß ich bei jedem Projekt einzeln
> jedesmal beim comitten erstmal auf die guthub-Seite gehen muss, um
> nachzuschlagen, wie dieser vereinzelte Branch bei dem Prjekt genau hiess.

Musst du auch nicht. Check das Projekt mit git clone aus, wie alle anderen
auch.

>> Das kann man kombinieren als
>> git clone g...@gitlab.com:username/project.git
>
>> Dann gibt es auch obiges Problem beim Push nicht.
>
> ja? Also ohne "git init" geht hier bisher überhaupt nichts, was mit
> Versionsmanagment zu tun hat.

Clone braucht kein init. Es legt ein neues Verzeichnis an.

> Und "clone" scheint auch nix weiter als download zu machen, und
> insbesondere nicht die geladenen Dateien zum Versionsmanagment
> anzumelden. Jedenfalls war das mein bisheriger Eindruck.

Dein Eindruck ist falsch.

[Jan Bruns]

Christian Weisgerber:

> On 2022-07-01, Jan Bruns <eb...@abnuto.de> wrote:
>
>> aber irgendwie erscheint mir das zurechgefrickelt, und ich verstehe gar
>> nicht wirklich, was ich da mache, bzw. wann wo welche Details wie in
>> das Versionsmanagment kommen, bzw. eben nicht.
>
> Aus eigener Erfahrung empfehle ich, die ersten Kapitel des Git-Buchs zu
> lesen, um ein Verständnis für die grundlegenden Zusammenhänge zu
> entwickeln.
> https://git-scm.com/book/en/v2

Nunja, somit habe ich also schonmal eine der vielen Fragen beantworten
können: git commit hat eine -a option.

Weiter hat Laurenz demnach recht mit Meinung, daß in meinem Beispiel clone
hätte funktionieren sollen, und wohl auch so tut.

Vmtl. habe ich das .git Untervezeichnis mit seinen Funktionen schlicht
und ergreifend im cwd erwartet. Ja, ich glaube so wars, Warum auch immer.

Gruss

Jan Bruns