Archiv der Kategorie: git

Git Tip of the Day – Spiel das Commit Game

Manchmal ist es ganz interessant zu sehen, wer wie viel comitted, wer also der „fleissigste“ ist (Sarkasmus Ende.).

Sehen kann man das ganz einfach mit folgendem Befehl:


git shortlog --numbered --summary

Ich habe das mal testweise im Wicket-Source-Repository gemacht, mit folgendem Ergebnis.


2932  Eelco Hillenius
2816  Igor Vaynberg
1867  Juegen Donnerstag
1780  Martin Tzvetanov Grigorov
1484  Johan Compagner
1321  Jonathan Locke
963  Matej Knopp
899  Martijn Dashorst
422  Alastair Maw
352  Peter Ertl
277  Jean-Baptiste Quenot
235  Frank Bille Jensen
218  Janne Hietamaki
205  Gerolf Seitz
98  martin-g
94  Sven Meier
91  Emond Papegaaij
76  Pedro Henrique Oliveira dos Santos
69  svenmeier
62  Gwyn Richard Evans
51  Jeremy Ryan Thomerson
42  Timo Heikki Rantalaiho
40  sourceforge-skipoles
16  Carl-Eric Menzel
14  Ate Douma
12  Maurice Marrink
8  Jan Blok
4  Jeremy Thomerson
2  Jesse Long
1  Thomas Götz
1  Pedro Santos
1  cvs2svn
1  Joe Schaefer
1  robert mcguinness
1  slowery
1  Michael Mosmann
1  Bertrand Guay-Paquet
1  Sven

Folien zu „Besser Gits nicht – Best Practices mit GIT“ sind jetzt auf Slideshare verfügbar

Die Folien zum Talk beim Herbstcampus 2012 in Nürnberg sind hier zu finden:


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

„Besser Gits nicht“ live auf dem Herbstcampus

Auf dem diesjährigen Herbstcampus erzähle ich live ein wenig aus meiner täglichen Arbeit mit GIT und zeige nützliche und praktische Beispiele – aus der Praxis für die Praxis. Das ganze basiert auf dem gleichnamigen Artikel, der dieses Jahr im Java-Magazin erschienen ist.

U.a. zeige ich:

  • Wie kann man Commits sauber strukturieren
  • Wie kann und sollte mit Branches gearbeitet werden
  • Wie kann man parallel mit Subversion und Git arbeiten
  • Wie wird mit Remote Repositories gearbeitet
  • Welche GUI Clients gibt es hierfür?
  • Git Flow

Ich habe schon mehrfach Vorträge zum Thema GIT gehalten, u.a. hier.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Git Flow – einfaches Arbeiten mit dem perfekten Git Workflow

Die Frage steht immer noch im Raum, wie sieht der perfekte Git-Workflow aus?

Eine genaue Beschreibung zum Git-Workflow, der meiner Ansicht nach am besten ist findet man hier bei nvie.

Ich gehe hier nicht näher auf den Workflow an sich ein, weil dieser im Artikel schon sehr ausführlich und verständlich beschrieben wird.

Vielmehr möchte ich in diesem Artikel eine einfache Möglichkeit beschreiben, den Workflow zu verwenden und zwar über GIT-FLOW.

Im Folgenden versuche ich zu beschreiben, wie man am einfachsten mit git-flow arbeitet.

Installation

Die Installation von git-flow ist hier beschrieben. Im Prinzip handelt es sich hier nur um eine Menge von Skripten, die in einem Git-Repo ausgeliefert werden.

Schaut man sich das Verzeichnis nach der Installation an, sieht das ungefähr so aus:

.
├── AUTHORS
├── bump-version
├── Changes.mdown
├── contrib
│   ├── gitflow-installer.sh
│   └── msysgit-install.cmd
├── git-flow
├── gitflow-common
├── git-flow-feature
├── git-flow-hotfix
├── git-flow-init
├── git-flow-release
├── gitflow-shFlags -> shFlags/src/shflags
├── git-flow-support
├── git-flow-version
├── LICENSE
├── Makefile
├── README.mdown
└── shFlags
├── bin
│   └── gen_test_results.sh
├── doc
│   ├── CHANGES-1.0.txt
│   ├── coding_standards.txt
│   ├── contributors.txt
│   ├── LGPL-2.1
│   ├── LICENSE.shunit2
│   ├── RELEASE_NOTES-1.0.0.txt
│   ├── RELEASE_NOTES-1.0.1.txt
│   ├── RELEASE_NOTES-1.0.2.txt
│   ├── RELEASE_NOTES-1.0.3.txt
│   ├── rst2html.css
│   └── TODO.txt
├── examples
│   ├── debug_output.sh
│   ├── hello_world.sh
│   └── write_date.sh
├── lib
│   ├── shunit2
│   └── versions
├── README.html
├── README.txt
└── src
├── shflags
├── shflags_test_defines.sh
├── shflags_test_helpers
├── shflags_test_parsing.sh
├── shflags_test_private.sh
├── shflags_test_public.sh
└── shflags_test.sh

Initialisierung von git-flow

Zunächst mal legen wir uns ein leeres Git-Repository an.

git init
Initialized empty Git repository in /home/madi/development/git/.git/

Das Repository muss für git-flow enabled werden:

git flow init

Die erste Frage die git-flow stellt ist, welcher Branch für Produktions-Releases verwendet werden soll.

Branch name for production releases: [master]

Wir definieren hierfür einfach mal master-release.

Die nächste Frage die gestellt wird ist, welches ist der Branch für zukünftige Entwicklungen?


Branch name for "next release" development: [develop]

Wir nennen den Branch einfach mal next.

Dann möchte git-flow wissen, mit welchem Prefix Feature-Branches beginnen sollen:


How to name your supporting branch prefixes?
Feature branches? [feature/]

Das passt soweit.

git-flow möchte wissen, welches Prefix Release-Branches haben sollen:


Release branches? [release/]

Auch das passt.

Jetzt möchte git-flow wissen, welches Prefix Bugfix-Branches erhalten sollen?


Hotfix branches? [hotfix/]

Auch das passt soweit.

Damit ist git-flow vollständig initialisiert (alle Restlichen Fragen sind für uns momentan uninteressant und können einfach bestätigt werden).

git-flow hat im leeren Repository automatisch die Branches master-release (den Produktions-Branch und den next-Branch erzeugt).


git branch -a
master-release
* next

Verwendung von Git-Flow

Man kann sich alle Feature Branches mit git flow feature ausgeben lassen.

git flow feature
No feature branches exist.

You can start a new feature branch:
git flow feature start <name> [<base>]

Aktuell sind noch keine Features vorhanden, nehmen wir an, wir möchten gerne das Feature „Validierung von Kundendaten“ entwickeln.


git flow feature start "validate-customerdata"

git-flow ist so freundlich, und beschreibt genau, was jetzt passiert ist.


Summary of actions:
- A new branch 'feature/validate-customerdata' was created, based on 'next'
- You are now on branch 'feature/validate-customerdata'

Now, start committing on your feature. When done, use:

git flow feature finish validate-customerdata

Wir machen einen Commit auf dem aktuellen Branch


git diff HEAD~1
diff --git a/validate-customerdata.txt b/validate-customerdata.txt
new file mode 100644
index 0000000..d2eef98
--- /dev/null
+++ b/validate-customerdata.txt
@@ -0,0 +1 @@
+this feature validates customerdata

Genau wie von git-flow vorgeschlagen, ist damit das Feature beendet und wir machen folgendes:


git flow feature finish validate-customerdata
Switched to branch 'next'
Updating 95a7f6a..2c1d9a4
Fast-forward
validate-customerdata.txt |    1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 validate-customerdata.txt
Deleted branch feature/validate-customerdata (was 2c1d9a4).

Summary of actions:
- The feature branch 'feature/validate-customerdata' was merged into 'next'
- Feature branch 'feature/validate-customerdata' has been removed
- You are now on branch 'next'

Ok, was macht git-flow, es reintegriert ein fertiges Feature automatisch in den next-Branch, löscht den Feature Branch und das alles vollautomatisch.

Wir versuchen jetzt nochmal dasselbe aber ohne Fast-Forward-Merge. Damit simulieren wir quasi, dass im Remote-Repository ein anderer Entwickler bereits ein wenig vorgearbeitet hat.

Ok, nehmen wir an, wir möchten gerne an einem Feature Performance-Improvement arbeiten.


git flow feature start "performance-improvement"

git-flow erzeugt erneut automatisch einen neuen Feature-Branch:


git branch
* feature/performance-improvement
master-release
next

Hier ein kurzes Transkript der Performance-Verbesserung:


git commit -m "better performance"
[feature/performance-improvement 1a42f54] better performance
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 performance.txt
git (feature/performance-improvement)]$git checkout next
Switched to branch 'next'
git (next)]$vim new-development.txt
git (next)]$git add new-development.txt
git (next)]$git commit -m "new development"
[next fe76679] new development
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 new-development.txt

Wir haben die Änderungen so gemacht, dass es beim Zurückführen des Feature-Branches einen Merge-Konflikt gibt:


CONFLICT (content): Merge conflict in performance.txt
Automatic merge failed; fix conflicts and then commit the result.

There were merge conflicts. To resolve the merge conflict manually, use:
git mergetool
git commit

You can then complete the finish by running it again:
git flow feature finish performance-improvement

Ok, nehmen wir an, wir möchten ein Release machen, nichts einfacher als das.


git flow release
No release branches exist.

You can start a new release branch:

git flow release start <name> [<base>]

Selbes Spiel wie zuvor, zunächst nutzen wir git-flow um einen Release-Branch anzulegen:


git flow release start 1.o
Switched to a new branch 'release/1.o'

Summary of actions:
- A new branch 'release/1.o' was created, based on 'next'
- You are now on branch 'release/1.o'

Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:

git flow release finish '1.o'

Ein Release-Branch wird quasi zu dem Zeitpunkt gezogen, an dem ein Release vorbereitet wird. Der Release-Branch wird gezogen und ab diesem Zeitpunkt werden keine neuen Features mehr in den Release-Branch mit aufgenommen. Neue Features werden nur noch auf dem next-Branch entwickelt. (Kann alles in der Beschreibung des Git-Flow nachgelesen werden).


git flow release finish 1.o
Switched to branch 'master-release'
Merge made by recursive.
hotfix.txt                |    2 ++
new-development.txt       |    1 +
performance.txt           |    4 ++++
validate-customerdata.txt |    1 +
4 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 hotfix.txt
create mode 100644 new-development.txt
create mode 100644 performance.txt
create mode 100644 validate-customerdata.txt
Switched to branch 'next'
Merge made by recursive.
hotfix.txt |    2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 hotfix.txt
Deleted branch release/1.o (was 9fbb1ad).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master-release'
- The release was tagged '1.o'
- Release branch has been back-merged into 'next'
- Release branch 'release/1.o' has been deleted

Ok, was macht git-flow, wenn wir ein Release machen?

git-flow merged alles von master-release in den release-branch, und führt dann alles auf den master-release branch zurück.
git flow setzt außerdem automatisch einen Tag und merged den Release-Branch letztendlich automatisch in den next-Branch.

Cool, oder?

Ok, das kratzt mehr oder weniger an der Oberfläche, anschließend noch einige Links zum Thema:

Git Flow Command Line Argumente

Git Branching Model auf NVIE

Git Best Practices


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Git Talk @ mobileX Ag in München

Ich habe heute einen Git-Talk bei der mobileX-AG in München gegeben.

Hat sehr viel Spaß gemacht, erstaunlich viel Interesse und Fragen zum Thema.

Vielen Dank für den netten Abend und den gut gefüllten Kühlschrank voller Bier:).


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Besser Gits Nicht – Git Artikel im Java Magazin

Hallo,

wie bereits angedroht ist im aktuellen Java Magazin ein Artikel von mir erschienen, der auch hier hier gelesen werden kann.

Da ich leider heute krank im Bett liege habe ich die Zeit genutzt, diesen nochmal zu lesen. Ich finde, er ist sehr lesenswert.

Viel Spaß damit.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Git Artikel im nächsten Java Magazin

Hallo zusammen,
im nächsten Java Magazin wird ein Artikel von mir zum Thema GIT erscheinen mit dem Titel „Besser Gits nicht!“

Der Artikel ist inhaltlich relativ locker, aber ich hoffe lesenswert geschrieben.

Ich freue mich über Kommentare.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban