Um im eclipse eine Zeichenkette in Groß- bzw. Kleinbuchstaben zu konvertieren braucht man lediglich:
Text selektieren und
Lower case: CTRL+SHIFT+Y
Upper case: CTRL+SHIFT+X
~
Donnerstag, 28. März 2013
Montag, 4. März 2013
git merging approach
Nach dem wir von einfachem svn auf coolen git umgestiegen sind. Ging am Anfang gar nichts mehr. Das Merging mit dem eGit-Plugin und mit dem alten Rangehensweise wie bei SVN - funktionierte an der Stelle nicht.
Bei svn war das ganze schön einfach: vor dem Entwickeln einmal updaten dann anpassen, dann wieder updaten falls in Zwischenzeit jamand an der gleiche Stelle was gemacht hat - mergen und letzendilch commiten.
Bei git ist natürliche Weise alles komplizierte, oder denke ich das nur so. Auf jedem Fall habe ich nach lange Suche keinen vernünftigen Tutorial gefunden, wie das normale Arbeitsablauf mit git funktionieren soll.
Nach langem hier-und-her habe ich für uns folgende Vorgehensweise identifiziert.
Über Feedback und Hinweise, dass es auch einfache gehen kann, werde ich mich freuen.
Übrigens, ich mache jetzt alles über Konsole, da eGit bei den ersten Versuchen nicht so richtig funktioniert hat.
Das Geheimnis des erfolgreichen Mergen mit git liegt im lokalen Branch!
Also so gehe ich vor:
10: Begin:
20: Aktuelle Version des Codes herunterladen (svn update)
git pull
30: Eigenen lokalen Branch anlegen (das kann auch später gemacht werden, aber auf jedem Fall vor dem ersten add/commit)
git checkout -b FeatureXXX (Name des Branches kann z.B. der zu entwickelnde Feature oder Bug sein)
40: (Optional) Alle branches anschauen und wo man gerade arbeitet, das wird mit * vermekrt.
git branch
50: Programmieren und Entwicklen und add und commit, und add und commit ...
git add -A
git commit -m "das FeatureXXX ist schon fast fertig"
60: Wenn man fertig mit dem Feture/Fix ist, dann letztes mal commiten und zurück auf den master (trunk) switchen
git checkout master
70: Noch mal von dem remote updaten, kann ja sein dass in der Zwischenzeit jemand was gemacht und commitet hat
git pull
Jetzt haben wir im lokalen master die aktuelle Version von dem Server und im Branch FeatureXXX unsere Anpassungen.
80: Jetzt wird gemergt, wichtig ist dass das Merging von dem master gemacht wird. Das kann mit git branch überprüft werden.
master branch, you can pruef it with "git branch")
git merge FeatureXXX
90: Im Eclipse nachschauen ob wir keine Konfikte haben, dafür ist eGit gut. Die Konflikte werden mit rotem Sternchen vermerkt. Wenn wir so viel Gluck haben, das keine Konflikte entstanden sind (kann natürlich auch daran liegen, dass keine sonst außer uns was gemacht hat :) ) Dann Pushen:
git push
100: Wenn Konflikte nach dem Merging entstanden sind, dann müssen diese manuelle behoben werden und dann wie üblich: add/commit/push
git add -A
git commit -m "FeatureXXX ist gemerget"
git push
110:END
Ich teste erfolgreich das Vorgehen schon seit 3 Wochen.
Hier noch ein gutes Tutorial für großere Teams:
http://nvie.com/posts/a-successful-git-branching-model/
Good luck
Bei svn war das ganze schön einfach: vor dem Entwickeln einmal updaten dann anpassen, dann wieder updaten falls in Zwischenzeit jamand an der gleiche Stelle was gemacht hat - mergen und letzendilch commiten.
Bei git ist natürliche Weise alles komplizierte, oder denke ich das nur so. Auf jedem Fall habe ich nach lange Suche keinen vernünftigen Tutorial gefunden, wie das normale Arbeitsablauf mit git funktionieren soll.
Nach langem hier-und-her habe ich für uns folgende Vorgehensweise identifiziert.
Über Feedback und Hinweise, dass es auch einfache gehen kann, werde ich mich freuen.
Übrigens, ich mache jetzt alles über Konsole, da eGit bei den ersten Versuchen nicht so richtig funktioniert hat.
Das Geheimnis des erfolgreichen Mergen mit git liegt im lokalen Branch!
Also so gehe ich vor:
10: Begin:
20: Aktuelle Version des Codes herunterladen (svn update)
git pull
30: Eigenen lokalen Branch anlegen (das kann auch später gemacht werden, aber auf jedem Fall vor dem ersten add/commit)
git checkout -b FeatureXXX (Name des Branches kann z.B. der zu entwickelnde Feature oder Bug sein)
40: (Optional) Alle branches anschauen und wo man gerade arbeitet, das wird mit * vermekrt.
git branch
50: Programmieren und Entwicklen und add und commit, und add und commit ...
git add -A
git commit -m "das FeatureXXX ist schon fast fertig"
60: Wenn man fertig mit dem Feture/Fix ist, dann letztes mal commiten und zurück auf den master (trunk) switchen
git checkout master
70: Noch mal von dem remote updaten, kann ja sein dass in der Zwischenzeit jemand was gemacht und commitet hat
git pull
Jetzt haben wir im lokalen master die aktuelle Version von dem Server und im Branch FeatureXXX unsere Anpassungen.
80: Jetzt wird gemergt, wichtig ist dass das Merging von dem master gemacht wird. Das kann mit git branch überprüft werden.
master branch, you can pruef it with "git branch")
git merge FeatureXXX
90: Im Eclipse nachschauen ob wir keine Konfikte haben, dafür ist eGit gut. Die Konflikte werden mit rotem Sternchen vermerkt. Wenn wir so viel Gluck haben, das keine Konflikte entstanden sind (kann natürlich auch daran liegen, dass keine sonst außer uns was gemacht hat :) ) Dann Pushen:
git push
100: Wenn Konflikte nach dem Merging entstanden sind, dann müssen diese manuelle behoben werden und dann wie üblich: add/commit/push
git add -A
git commit -m "FeatureXXX ist gemerget"
git push
110:END
Ich teste erfolgreich das Vorgehen schon seit 3 Wochen.
Hier noch ein gutes Tutorial für großere Teams:
http://nvie.com/posts/a-successful-git-branching-model/
Good luck
Abonnieren
Posts (Atom)