Wie strukturierst du deinen Git-Repository-Workflow?

Question

Wir haben die Videos gesehen und gesehen, wie große verteilte Teams Git benutzen, aber was ist mit denen von uns, die nicht verteilt sind und die mit dem Rest unseres Teams im Büro arbeiten? Wie sollten wir unsere Repositories und unseren Workflow strukturieren?

Denken Sie an das traditionelle Büro, das Subversion oder CVS als einzigen Autoritätspunkt verwendet hat. Sicherlich könnten diese Teams ihre eigenen Git-Repositories unterhalten und je nach Bedarf zwischen ihnen hin- und herschieben, was in vielen Situationen schnell zum Albtraum werden würde. Oder sie könnten jeweils ihr eigenes Repository verwalten und mit einem einzigen Repository synchronisieren, das als "Master" für das Team bekannt ist. Oder es könnte eine Kombination von Workflows mit den Möglichkeiten geben, die ein DVCS eröffnet.

Wie funktioniert Ihr Team? Was haben Sie als nützlichen Arbeitsablauf gefunden?

Answer 1

Ich mag die Art, wie die Yahoo! User Interface (YUI) Team scheint zu arbeiten. Ich bin weder bei Yahoo, noch bin ich in diesem Team, aber ihre git commit-Logs offenbaren viel über ihren Prozess.

Das YUI-Team unterhält ein zentrales Repository, in dem jeder im Team Zugriff auf Commits hat. Periodisch nach Commits in dieses Repository (es könnte nach jedem Push sein, aber ich denke nicht), feuert das Build-System, baut YUI neu auf und schiebt ein neu getagtes Commit nach github, wo die Community den Code forkieren und daran arbeiten kann .

Ich bin für das zentrale Repository, das den "offiziellen" Status des Projekts darstellt. Natürlich, wenn ich Code mit einem Kollegen teilen möchte, kann ich dafür sorgen, dass sie einen Zweig von mir ziehen, und wir können auf diese Weise zusammenarbeiten.

Das "Master" -Repository bietet noch weitere Vorteile, wie die einfache kontinuierliche Integration, da die Push/Pull-Trigger im Master-Repository konfiguriert werden können, um die Komponententests auszulösen und das System zu erstellen. Es stellt außerdem sicher, dass jeder weiß, wo die neueste Version des Repositorys "bekannt" ist, so dass, wenn das Projekt erstellt, veröffentlicht oder getestet werden muss, die Gewissheit besteht, dass das Master-Repository dafür bereit ist .

Git wird fast jeden denkbaren Workflow unterstützen, aber selbst in einem kleinen Team wollen Sie nicht, dass es eine Frage darüber gibt, wo das "offizielle" Repository ist. Der Wartungsalphabet, der dazu führen könnte, insbesondere wenn Sie sich einer Veröffentlichung nähern, wäre unangenehm.

Answer 2

einen Blick auf schönen Blog http://nvie.com/git-model und Kommentare

Answer 3

bei einem Workflow Github Team Werfen Sie einen Blick verwendet:

http://scottchacon.com/2011/08/31/github-flow.html

Es erfordert Github verwenden, aber auch recht einfach und sauber ist.