git: Änderungen ins Remote-Repository übertragen

[Dennis S. (eltio)]

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

[Georg (Gast)]

Du musst erst einen Commit durchführen; also quasi deine Änderungen 
abgeben. Dann kannst du mit push die Commits auf das remote repo laden.

[Kaj (Gast)]

git add --all

oder

git add <datei>

git commit -m 'commit nachricht'
git push

[Dennis S. (eltio)]

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

[Git User (Gast)]

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!

[Stm M. (stmfresser)]

git remote add origin /your/share/folder/project.git

git add .
git commit -m 'msg'
git push -f origin master

[Sven B. (scummos)]

git add . ist schlechter Stil.
git push -f ist sehr schlechter Stil. Vernünftige Remotes haben das 
deaktiviert.

[rebase? (Gast)]

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.

[Sven B. (scummos)]

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.

[rebase? (Gast)]

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?

[Sven B. (scummos)]

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.

[rebase? (Gast)]

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.

[Sven B. (scummos)]

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 ...