3. Verständnisfrage zu git

Verständnisfrage zu git

  • F

    Hallo

    ich habe gerade erst mit git (auf gitHub) angefangen und verstehe es noch nicht ganz, ich habe folgende Frage:

    Ich habe eine Webanwendung als git-Projekt.
    Ich will nun lokal einen eigenen branch eröffnen, in welchem ich etwas ausprobieren will. Dazu mache ich ja einfach nur:

    $ git checkout -b mybranch

    Um zwischen den verschiedenen branches umzuschalten mach ich dann:

    $ git checkout master
$ git checkout mybranch

    gemäß der gitHub-Hilfe:
    http://help.github.com/fork-a-repo/
    unter "How do I use branches?"

    Aber das spielt sich doch alles nur in der git-internen Verwaltung des Projektes ab, aber nicht in den tatsächlichen Dateien.
    Ich will ja auch sehen, was sich jetzt im neuen branch geändert hat, indem ich das Webprojekt lokal im Browser aufrufe, aber der Browser weiß doch nichts von meinen branches.

    Ich meine: wie mache ich dieses "Umschalten zwischen branches" denn nach außen hin sichtbar?

    Geht das dann nur, indem ich "merge"? Dann wäre mein branch ja aber auch unnötig, weil ich ihn dann ja gar nicht ausprobieren kann.

    Ich glaube das ist wirklich eine blutige Anfängerfrage.

    franc

    0
  • S

    Genau das machen Deine beiden "git checkout"-Befehle. Probier's aus, die Dateien auf deiner Platte werden sich ändern.

    0
  • F

    Das probiere ich gleich morgen aus, wenn das klappt, das wäre ja phantastisch und superpraktisch!

    0
  • F

    Hm, sicher habe ich da etwas noch nicht verstanden.

    Ich habe also einen neuen branch (mygit) angelegt, dahin gewechselt, mit einem Editor eine bestehende Datei geändert (style.css) und dann wieder zurück zum master-branch gewechselt.
    Die Änderung im neuen branch ist allerdings noch aktiv, die Datei ist also nicht mehr so wie vorher.

    Das ist meine (vereinfachte) Kommandozeile:

    $ git branch mygit
me@MYCOMP /c/apache/htdocs/test (master)
$ git checkout mygit
M       .gitignore
Switched to branch 'mygit'

me@MYCOMP /c/apache/htdocs/test (mygit)
$ git checkout master
M       .gitignore
M       style.css
Switched to branch 'master'

me@MYCOMP /c/apache/htdocs/test (master)
$

    Kann ich style.css etwa nur im git-Kommandofenster bearbeiten, damit es beim branch-Wechsel wieder zurückgesetzt wird, oder was muss ich da noch tun?

    0
  • F

    OK, ich glaube ich habe es verstanden 😉

    Ich muss natürlich die Änderung in meinem branch auch committen, also mit z.B.

    git commit -a

    Und jetzt geht es. Wenn ich wechsle werden die jeweiligen Dateien geändert.
    Prima Sache.

    0
  • S

    Da hab ich jetzt extra ein Beispiel getippt 😉 Genau so ist es! 🙂

    0
  • F

    Oh, tut mir leid!
    Dennoch vielen Dank!

    Gruß

    0
  • N

    Wenn du aus irgendeinem Grund gerade nicht committen möchtest, kannst du deine Änderungen auch kurz mit "git stash" weglegen und dann mit "git stash pop" wieder herstellen. Wobei ich das nur für Kleinmist benutze, alles andere wird committet; notfalls kann man Commits ja immer noch aufräumen, bevor man sie pusht.

    0
  • N

    Ach ja, die GitHub-Leute verlinken das eh auch, aber eine tolle Ressource zu Git ist das hier:
    http://progit.org/book/

    0
  • P

    Was abseits der einzelnen Kommandos aus meiner Sicht für das Verständnis von git & Co. gut verständlich geschrieben ist: http://www.ericsink.com/vcbe/

    0
  • S

    franc schrieb:

    Oh, tut mir leid!

    Ach, muss Dir nicht leid tun. Hauptsache, Du bist weitergekommen!

    0
  • F

    Jetzt habe ich doch noch eine Frage:

    Ich habe ein bestehendes GitHub Projekt geforkt (gegabelt) und daran herumgebastelt.
    Mit:

    git remote add upstream git://github.com/originalrep.git

    habe ich die Originalquelle zu meinem lokalen Repository hinzugefügt, wie man unter:

    http://help.github.com/fork-a-repo/

    nachlesen kann.
    Ich kann nun mit:

    git fetch upstream

    das Originalrepository holen:

    c:\apache\Apache2\htdocs\kimai-git>git fetch upstream
remote: Counting objects: 271, done.
remote: Compressing objects: 100% (64/64), done.
remote: Total 222 (delta 168), reused 210 (delta 156)
Receiving objects: 100% (222/222), 218.02 KiB | 239 KiB/s, done.
Resolving deltas: 100% (168/168), completed with 31 local objects.
From git://github.com/kimai/kimai
 * [new branch]      master     -> upstream/master

    Aber wie schalte ich die zwei Repositorys (mein geforktest und das Upstream-Original) nun um?

    Das eigene geforkte Repository ist nämlich nach wie vor aktiv.
    Es ist mir noch recht unklar das gitten.

    Ich habe dann auch noch:

    >git checkout -b upstream
Switched to a new branch 'upstream'

    ausgeführt, aber ich befinde mich noch in meinem eigenen git, also mit dessen Änderungen am (upstream)Original. Meine Änderungen am Original sind immer noch zu sehen.

    Ein git commit -a ergibt:

    c:\apache\Apache2\htdocs\kimai-git>git commit -a
# On branch upstream
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       core/extensions/ki_adminpanel/compile/wrt4B2.tmp
#       core/extensions/ki_invoice/templates/00_Rechnung.odt
#       core/kimai-mobile/
#       core/skins/standard/grfx/lupe.jpg
#       core/skins/standard/grfx/lupe.psd
#       core/temporary/logfile.txt
#       docu/Programmieranleitungen.txt
#       update.bat
nothing added to commit but untracked files present (use "git add" to track)

    Was mach ich falsch?

    0
  • ?

    was genau willst du denn machen? du kannst die änderungen aus dem original repository mittels pull holen. als nach git remote add upstream ... machst du git fetch upstream und dann git pull upstream. die änderungen an deinem code kannst du aber nur pushen, wenn du auch berechtigungen dazu hast. da du ja auf einem fork arbeitest, hast du ja offenbar keine rechte für das original repository. du kannst also nur in deinen fork pushen. über die github oberfläche könntest du dann an die leute des original repositories einen pull request schicken, um sie aufzufordern, die änderungen aus deinem fork in das original repository zu übernehmen.

    0
  • F

    Ich will bequem umschalten zwischen dem Original Repository, woran ich gar nichts ändern will und meinem Repository, wohin ich auch Änderungen einpflege.

    c:\apache\Apache2\htdocs\kimai-git>git pull upstream
You asked to pull from the remote 'upstream', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

    Welchen "branch" nehme ich denn da nun?

    EDIT:

    c:\apache\Apache2\htdocs\kimai-git>git branch --set-upstream origin origin/master
Branch origin set up to track remote branch master from origin.

    und dann:

    c:\apache\Apache2\htdocs\kimai-git>git pull upstream
You asked to pull from the remote 'upstream', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

    bingt immer noch nichts.
    Geht das prinzipiell vielleicht gar nicht, so einfach zwischen dem Original und meinem Fork umzuschalten?

    0
  • C

    franc schrieb:

    Ich will bequem umschalten zwischen dem Original Repository, woran ich gar nichts ändern will und meinem Repository, wohin ich auch Änderungen einpflege.

    Mach mal git branch -a, um zu sehen welche branches du überhaupt hast. Dein Branch "upstream" hat nichts mit dem Remote-Repository zu tun, so wie du ihn angelegt hast. Den würde ich daher erstmal löschen (git branch -d upstream).

    Du könntest dann entweder den branch "master/upstream" direkt auschecken mit "git checkout master/upstream", oder einen tracking branch dafür machen mit "git branch upstream master/upstream". Wichtig ist hier das "master/upstream" am Ende des Aufrufs.

    Hin und herschalten geht in jedem Fall mit git checkout <branch>. Im ersten Fall ist <branch> dann master/upstream, im zweiten einfach nur upstream.

    Wenn du direkt master/upstream auscheckst, landest du aber im "detached HEAD state", was erstmal nur bedeutet, dass du in diesen Branch nicht committen kannst. Einen separaten Branch "upstream" anlegen hat den Nachteil, dass du manuell git pull aufrufen musst, um ihn zu aktualisieren.

    Aber eigentlich sollte das nicht nötig sein. Die Anleitung, die du verlinkt hast, erklärt auch, wie man upstream-Änderungen in den eigenen master-Branch merged:
    $ git fetch upstream
    $ git merge upstream/master

    So würde ich das einfach machen, da musst du den upstream/master-Branch gar nicht erst manuell auschecken.

    0
  • C

    franc schrieb:

    c:\apache\Apache2\htdocs\kimai-git>git branch --set-upstream origin origin/master
Branch origin set up to track remote branch master from origin.

    Ich würde eventuell noch mal ein frisches git clone machen. Diese Zeile mit --set-upstream (und ich weiß ja nicht, was du noch alles gemacht hast), kann ziemlich viel kaputt machen. Natürlich kann man das alles schnell reparieren, wenn man weiß wie, aber ein git clone dürfte viel einfacher sein.

    Mit --set-upstream musst du normalerweise nie arbeiten, "git branch <branch> <start-point>" macht das automatisch.

    0
  • F

    Christoph schrieb:

    Mach mal git branch -a, um zu sehen welche branches du überhaupt hast. ...

    c:\apache\Apache2\htdocs\kimai-git>git branch -a
  fcw
  master
  origin
* upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master

    Mir scheint das ist schon völlig verkorkt 😞

    0
  • F

    So also den branch upstream, der ja nur für Verwirrung sorgt, habe ich wieder gelöscht, so schaut das jetzt aus:

    c:\apache\Apache2\htdocs\kimai-git>git checkout fcw
Switched to branch 'fcw'

c:\apache\Apache2\htdocs\kimai-git>git branch -d upstream
Deleted branch upstream (was 119cc7f).

c:\apache\Apache2\htdocs\kimai-git>git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.

c:\apache\Apache2\htdocs\kimai-git>git checkout origin/master
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d53d059... Ignore some new files

c:\apache\Apache2\htdocs\kimai-git>git branch -a
* (no branch)
  fcw
  master
  origin
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master

    So langsam funktioniert das auch mit dem git checkout ... 🙂

    Ich bin mir nicht sicher, ob ich meine Änderungen in meinen Fork korrekt auf github gepusht habe, sonst würde ich nämlich jetzt wirklich alles nochmal löschen und neu pullen.
    Warum steht bei mir denn da untereinander master UND origin? Ist das nicht das gleiche und beides lokal?

    0
  • C

    franc schrieb:

    Christoph schrieb:

    Mach mal git branch -a, um zu sehen welche branches du überhaupt hast. ...

    c:\apache\Apache2\htdocs\kimai-git>git branch -a
  fcw
  master
  origin
* upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/upstream/master

    Mir scheint das ist schon völlig verkorkt 😞

    Ja, deswegen mein Tipp ein neues git clone zu machen von deinem (deinem persönlichen) github-Repository (nicht das Original-Repository).

    Wenn du das nicht möchtest, würde ich erstmal master auschecken und dann die beiden Branches "origin" und "upstream" löschen mit git branch -d. Dann master mit --set-upstream wieder reparieren, sodass er origin/master trackt. Dann das machen, was ich in meinem ersten Posting hier beschrieben habe.

    Aber nochmal, was spricht gegen die Anleitung von github?
    $ git fetch upstream
    $ git merge upstream/master

    Dann musst du den Original-Branch gar nicht auschecken, sondern bekommst die Änderungen in deinen Branch gemerged. Du siehst dann auch exakt die Änderungen, die du gemacht hast gegenüber den Änderungen, die upstream passiert sind. Diese Änderungen sind ja normalerweise das interessante, nicht der tatsächliche Zustand des upstream-Repositories. Man möchte ja nicht tausende Zeilen manuell vergleichen, da ist es gut, wenn git einem ein diff automatisch erstellt und man nicht manuell zwischen Original-Branch und eigenem Branch hin- und herwechseln muss, um zu vergleichen.

    0
  • C

    franc schrieb:

    Ich bin mir nicht sicher, ob ich meine Änderungen in meinen Fork korrekt auf github gepusht habe, sonst würde ich nämlich jetzt wirklich alles nochmal löschen und neu pullen.
    Warum steht bei mir denn da untereinander master UND origin? Ist das nicht das gleiche und beides lokal?

    Du hast scheinbar manuell einen Branch namens "origin" angelegt.

    Die Namen "master", "origin", und so weiter haben für git keinerlei besondere Bedeutung. Das sind keine keywords und die werden von git auch nicht speziell behandelt. Das sind einfach nur willkürliche Namen für einen Branch oder ein remote repository. Du kannst also ein remote repository "origin" nennen, du kannst aber genausogut einen Branch "origin" nennen. Das eine hat mit dem anderen nichts zu tun.

    0
Anmelden zum Antworten