Zu zweit an einem App-Projekt über Git(Hub) arbeiten

[olex.]

Hallo !

Ich habe mit einem Kumpel ein app-projekt angefangen, wir sind beide keine profis und kennen uns noch nicht hundertprozentig aus. Unser größtes problem bisher ist, wie wir an einem projekt als team arbeiten können, also das versionsmanagement. Wir haben uns für die nutzung von git und GitHub entschieden, zusammen mit dem egit plugin in eclipse. Wir arbeiten beide auf einem 64bit Ubuntu 13.04.

Ich habe bereits gefühlt seeehr viel darüber gelesen (z.B. http://visualcosmos.com/presse/github/index.html, http://www.vogella.com/articles/EGit/article.html), und mir unzählige tutorials angesehen, habe aber immernoch keine konkrete Vorstellung, wie die arbeit ablaufen soll.

Wir haben bereits git installiert, einen github account und dort eine repository angelegt. Eclipse ist auch fertig für android konfiguriert, zusammen mit dem egit plugin. Das problem ist wie gesagt die zusammmenarbeit an einem projekt, und dazu habe ich noch ein paar fragen.

- Wie kann man die lokale repository mit der entfernten github-repo "synchronisieren" ?
- Wo sollte sich die lokale repo befinden ? Im workspace ?
- Oder braucht man überhaupt eine lokale repo ?
- Ich habe ein android-app-projekt erstellt. dieses liegt ja als package vor. muss ich jetzt immer dass package pushen ? oder muss es in der lokalen repo liegen ?
- Könnte ich nicht einfach die github repo runterladen, dann dort das package erstellen und wieder pushen ? somit würde dohc das projekt dann in github liegen und man könnte nach diesem schema arbeiten.
- Muss jeder einen eigenen branch erstellen ? Und den dann einfließen lassen ?

Arbeitet vielleicht jemand hier genauso oder ähnlich und kann mir/uns behilflich sein ?

Wäre für profesionelle hilfe sehr dankbar !

 

[blackfire185]

Also wir hatten mit git auch solche Probleme. Schließlich sind wir dann zu den Team foundation Server von Microsoft gewechselt welches uns keine Probleme bereitete und meines Wissens ähnliche Funktionen bietet.

Wollte ich nur mal erwähnen, war unsere Lösung und wir sind froh darüber.

Gesendet von meinem LG-P880 mit der Android-Hilfe.de App

 

[derjens]

Schönen guten Abend.

Sorry wenn ich das jetzt mal so unverschämt sage
aber nach deinen fragen nach zu urteilen hast du nicht besonders viel oder eben nicht das richtige über Git gelesen.
Ich bin zwar kein Profi und setze git erst seit ca. einem Jahr ein aber ich versuche dir mal nach bestem wissen und gewissen zu antworten.

- Wie kann man die lokale repository mit der entfernten github-repo "synchronisieren" ?
Wie egit funktioniert weis ich leider nicht aber ich würde sagen das du damit deine push und pulls machen kannst die zum synchronisieren notwendig sind.
Ich setze Android Studio ein und damit geht das einwandfrei.

- Wo sollte sich die lokale repo befinden ? Im workspace ?
Denke das das im Prinzip keine rolle spielt, aber ich würde auch den workspace vorschlagen.

- Oder braucht man überhaupt eine lokale repo ?
Git ist eine Dezentrale Versionsverwaltung und du bzw. ihr arbeitet immer mit einer Lokalen kopie.

- Ich habe ein android-app-projekt erstellt. dieses liegt ja als package vor. muss ich jetzt immer dass package pushen ? oder muss es in der lokalen repo liegen ?
Dein Projekt besteht ja aus verschiedenen Ordnern in denen die Quellcode dateien liegen (src ordner und res ordner) aus denen eclipse dann die APK baut. Diese dateien solltest du synchronisieren.

- Könnte ich nicht einfach die github repo runterladen, dann dort das package erstellen und wieder pushen ? somit würde dohc das projekt dann in github liegen und man könnte nach diesem schema arbeiten.
Siehe oben.

- Muss jeder einen eigenen branch erstellen ? Und den dann einfließen lassen ?
Nein. Ihr könnt beide an einer Branch arbeiten.


Grundsätzlich muss jeder von euch beiden seine Änderungen immer in seinem Lokalem repo commiten und dann die commits in das zentrale repo (GitHub) pushen.
Ebenso müsst ihr die Änderungen des jeweiligen anderen aus der zentralen repo (GitHub) pullen.

Ich empfehle dir das Buch:
Git: Dezentrale Versionsverwaltung im Team - Grundlagen und Workflows

Gruß
derjens

 

[olex.]

Ich habe mir das so vorgestellt dass man dass ganze projekt package synchronisiert, und nicht nur die java klassen und aktivities.

Das heist also, ich muss in meinem workspace meine lokale repository erstellen, und dann in dieser lokalen repository das android-app-projekt erstellen, also das package. Und dann kann ich diese ganze repo mit dem package nach github pushen (bzw. man muss doch erst in die staging area adden, dann commiten und dann pushen oder ?). dort ist das package dann für alle sichtbar.

Und jetzt, wenn man anfängt zu arbeiten, muss man erst 'pull from upstream' machen, also den github inhalt in die lokale repo laden. Jetzt müsste git ja die dateien des lokalen packages und des github packages vergleichen, und diejenigen in meinem lokalen repo ersetzen, die in github anders sind (also von jemandem geändert worden sind).

Hab ich dass so richtig verstanden und kann man dass so machen? Wenn ja wie wird das in egit oder im terminal funktionieren ?

 

[TheDarkRose]

Funktioniert in egit genauso wie im Terminal.

Einen Punkt noch, nicht hauptsächlich am master arbeiten, sondern mit feature branches. Wenn man nicht gerade am selben Feature (je nachdem wie man diese definiert) arbeitet, kommt man sich auch nicht in die Quere. Ist das Feature abgeschlossen, pusht man den Branch nach GitHub und erstellt dort online einen PullRequest, wo alle nochmal über die Änderungen drüber schauen bevor dieser in den master (bzw. develop) gemerged wird. A successful Git branching model » nvie.com

Falls man unter Windows oder Mac ist, kann ich noch SourceTree empfehlen, ist deutlich angenehmer zum arbeiten als eGit.

 

[olex.]

Erst einmal vielen dank für die tipps

Da wir nur zu zweit arbeiten, und das projekt auch nicht besonders groß oder aufwendig ist, habe ich bisher keinen nutzbaren sinn im erstellen von branches für jeden von uns gesehn. womöglich weil ich es nicht ganz verstehe wie man mit branches arbeitet. da hat mir leider auch der link nicht geholfen. was genau ist denn mit feature gemeint ?

unter linux gibt es auch viele anwendungen zum verwalten von git repos, z.B. cola, giggle, qgit oder gitg

 

[TheDarkRose]

Branchen ist der essentiellste Workflow von Git. Ich bin allein und branche immer für jedes Feature. Bringt nur Vorteile. Passt es nicht, wird der Branch einfach verworfen. Hätte ich diese Änderungen am Master gemacht, müsste ich dies umständlich wieder rückgängig machen. Branchen ist bei Git billig, nicht wie bei SVN.

Was ein Feature ist, definiert ihr. Das kann ein Eintrag im Menü sein, eine neue Activity, egal.

 

[Thenex]

gitHub ist der Oberknaller. Danke, dass ihr mich n bisschen inspiriert habt das zu nutzen

 

[StefMa]

Nur um es zu verstehen.
Ich mach eine initial release. Dort ist eine funktionierende App die Hallo Welt ausgibt. (Also eine *.java und eine *.xml).
Dies ist nun im Master-Branche zu finden.

Als nächstes baue ich ein Widget, welches ebenso nur Hallo Welt auf dem Homescreen ausgibt.
Dazu lade ich zunächst alles runter ins lokale Repo. Erstelle die neue *.java. Wenn es dann funktioniert pushe ich es als "feautre".
Frage1: Was enthält das feature? Nur die geänderte Datei oder den kompletten Master-Zweig + änderungen. Ist es quasi ein "insich fork"?

Wenn ich das ganze nun für gut befinde und ich den Master-Zweig übergebe, dann jedoch trotzdem ein fehler auftritt und das komplette Feature 1 löschen will.
Frage2: Kann ich das "feautre 1" einfach löschen? Oder ist es schon im Master "fest verankert" und ich muss zurück zum initial release?

Hoffe das Bild erklärt es auch noch mal ein bisschen

Gruß

 

[TheDarkRose]

* Repo auf Github anlegen
* lokal ein git clone
* bisschen proggen, git add, git commit
* git push, deine Änderungen sind am master lokal und in Github.

* git checkout -b feature/tolle-sache, du hast lokal einen Featurebranch angelegt. Ein Branch beinhaltet natürlich immer die Änderungen vom master (bzw. von wo man aus den Branch angelegt hat).
* bisschen am feature proggen, immer wieder git add, git commit (oder git commit -a).
* Feature fertig, ein push nach Github (git push -u origin feature/tolle-sache beim ersten mal, ansonsten reicht ein git push)
* Dort nun einen Pull Request erstellen und mergen. Online werden dir eh schon etwaige Konflikte angezeigt. Aber da niemand am master arbeiten sollte, sollte es nie Konflikte geben.
* Passt alles, sind die Änderungen vom Feature Branch im master. Der Feature Branch kann nun gelöscht werden. (git branch -d feature/tolle-sache)

* Gefällt es nicht oder war die Idee doof, oder was auch immer, einfach den Pull Request schließen und den Branch löschen. Es war nie was davon im master

 

[olex.]

also das mit den branches ist generell natürlich ne tolle sache...
nur ich werde denk ich fürs erste nur am master arbeiten da ich das projekt einfach so schnell und unkompliziert wie möglich zum laufen bringen will.

nach meinem jetztigen verständnis ist ein fork und ein branch aber fast das gleiche, oder ? beides sind komplette ''kopien'' des repos.

 

[TheDarkRose]

Naja, ich wünsch euch viel Spaß mit den ständigen Mergekonflikten, wenn ihr gleichzeitig immer am master arbeitet.