Hallo zusammen, ich verstehe es irgendwie nicht: ich habe ein kleines Projekt auf Github und nun lokal Änderungen an einer Datei gemacht. Diese möchte ich jetzt nach Github übertragen. "git status" zeigt die "Auf Branch master; zum Commit vorgemerkte Änderungen" und die korrekte Datei. Ich habe nun versucht mit "git push origin master" bekomme ich die Meldung "Everything up-to-date". Was mache ich falsch? Gruß Dennis
Gast
#4511552
Du musst erst einen Commit durchführen; also quasi deine Änderungen abgeben. Dann kannst du mit push die Commits auf das remote repo laden.
Gast
#4511572
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Okay, das hat funktioniert.. Das heißt: "git add" fügt Änderungen der Staging Area hinzu "git commit" überträgt die Staging Area in das lokale Repository "git push" überträgt die Daten erst auf ein Remote Repository? Gruß Dennis
Gast
#4513043
Dennis S. schrieb: > Das heißt: > "git add" fügt Änderungen der Staging Area hinzu > "git commit" überträgt die Staging Area in das lokale Repository > "git push" überträgt die Daten erst auf ein Remote Repository? Genau so ist es!
1 | |
2 | |
3 | |
4 | |
5 | |
git add . ist schlechter Stil. git push -f ist sehr schlechter Stil. Vernünftige Remotes haben das deaktiviert.
Gast
#4513264
Sven B. schrieb: > Vernünftige Remotes haben das > deaktiviert. Das ist natürlich Unsinn. Wie pushst du branches, bei denen du ein rebase gemacht hast? Ach ich kenne die Antwort schon: Man macht keine rebases, weil sie schlechter Stil sind. Blah.
rebase? schrieb: > Sven B. schrieb: >> Vernünftige Remotes haben das >> deaktiviert. > Das ist natürlich Unsinn. Wie pushst du branches, bei denen du ein > rebase gemacht hast? Nicht. Oder wie bringst du das deinen Kollegen bei dass sie jedes Mal ihr Repo umbauen müssen wenn du was gepusht hast? Veröffentlichte Änderungen zurücknehmen geht mit git einfach nicht sinnvoll. > Ach ich kenne die Antwort schon: Man macht keine rebases, weil sie > schlechter Stil sind. Blah. Rebase ist völlig ok, ich tue das ständig. Nur nicht von veröffentlichten Änderungen. Überleg' dir halt vor dem push, ob du noch Commits zusammenfassen willst. Danach ist es einfach zu spät. Wenn das nicht flexibel genug ist, entwickle in einem Branch, dann kannst du vor dem merge nochmal ein rebase -i machen, den alten Branch löschen und einen neuen anlegen, und den dann mergen.
Gast
#4513495
Sven B. schrieb: > Nicht. Oder wie bringst du das deinen Kollegen bei dass sie jedes Mal > ihr Repo umbauen müssen wenn du was gepusht hast? > Veröffentlichte Änderungen zurücknehmen geht mit git einfach nicht > sinnvoll. Das ist schlichtweg Unsinn. >Wenn das >nicht flexibel genug ist, entwickle in einem Branch, Aha. Und wie pushst du den branch dann, ohne --force?
rebase? schrieb: >>Wenn das >>nicht flexibel genug ist, entwickle in einem Branch, > > Aha. Und wie pushst du den branch dann, ohne --force? Du legst einen neuen Branch an.
Gast
#4513583
Sven B. schrieb: > Du legst einen neuen Branch an. Und versinkst dann irgendwann in 9000 branches, die niemand braucht. Sieh es einfach ein, dass rebase im Zusammenhang mit push --force nützlich ist, wenn es sich um Entwicklungsbranches handelt.
Wenn das Entwicklungsbranches sind die nur für dich sind, kannst du die ja lokal behalten ... wenn du sie als Backup irgendwo hin pushen möchtest, nehme ich dafür einen Extra-Remote ...