Git-basierte Quellcodeverwaltung im Unternehmen: Vorgeschlagene Tools und Vorgehensweisen?

Ich benutze Git für persönliche Projekte und finde es großartig. Es ist schnell, flexibel, leistungsstark und eignet sich hervorragend für die Remote-Entwicklung.

Aber jetzt ist es bei der Arbeit vorgeschrieben und ehrlich gesagt haben wir Probleme.

Standardmäßig scheint Git für eine zentralisierte Entwicklung in einer großen Organisation (über 20 Entwickler) mit Entwicklern mit unterschiedlichen Fähigkeiten und unterschiedlichem Git-Anspruch nicht gut zu funktionieren - insbesondere im Vergleich zu anderen Versionsverwaltungssystemen wie Perforce oder Subversion sind auf diese Art von Umgebung ausgerichtet. (Ja, ich weiß, Linus hat es nie dafür vorgesehen.)

Aber - aus politischen Gründen - wir bleiben bei Idiot, auch wenn es scheiße ist, was wir damit machen wollen.

Hier sind einige der Dinge, die wir sehen:

• Die GUI-Tools sind nicht ausgereift
• Mit den Befehlszeilen-Tools ist es viel zu einfach, eine Zusammenführung zu vermasseln und die Änderungen anderer zu löschen
• Es bietet keine Repository-Berechtigungen pro Benutzer, die über die globalen Nur-Lese- oder Lese- / Schreibrechte hinausgehen
• Wenn Sie die Berechtigung für JEDEN Teil eines Repositorys haben, können Sie JEDEN Teil des Repositorys auf dieselbe Weise ausführen. Sie können also nicht so etwas wie einen Verfolgungszweig für kleine Gruppen auf dem zentralen Server erstellen, den andere Benutzer nicht können sich anlegen mit.
• Andere Arbeitsabläufe als "alles geht" oder "wohlwollender Diktator" sind schwer zu fördern, geschweige denn durchzusetzen
• Es ist nicht klar, ob es besser ist, ein einzelnes großes Repository (mit dem jeder mit allem herumspielen kann) oder viele Repositorys pro Komponente zu verwenden (was zu Kopfschmerzen beim Versuch führt, Versionen zu synchronisieren).
• Bei mehreren Repositorys ist es auch nicht klar, wie alle Quellen, die jemand anderes hat, durch Abrufen aus dem zentralen Repository repliziert werden sollen, oder wie man gestern Nachmittag ab 4:30 Uhr alles abruft.

Ich habe jedoch gehört, dass Leute Git in großen Entwicklungsorganisationen erfolgreich einsetzen.

Wenn Sie sich in einer solchen Situation befinden - oder wenn Sie im Allgemeinen Tools, Tipps und Tricks haben, um die Verwendung von Git in einer großen Organisation, in der einige Leute keine Kommandozeilenfans sind, einfacher und produktiver zu gestalten -, würde ich gerne hören, was Sie haben vorschlagen.

Übrigens, ich habe bereits auf LinkedIn eine Version dieser Frage gestellt und keine wirklichen Antworten erhalten, aber viele "Meine Güte, das würde ich auch gerne wissen!"

UPDATE: Lassen Sie mich klarstellen ...

Wo ich arbeite, können wir nichts anderes als Git verwenden . Es ist keine Option. Wir bleiben dabei. Wir können nicht mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, Basar, Darcs, monoton, Perforce, Fossil, AccuRev, CVS oder sogar Apples guten alten Projektor verwenden, den ich 1987 verwendet habe. Während Sie gerne andere Optionen besprechen können, erhalten Sie kein Kopfgeld, wenn Sie nicht über Git sprechen.

Außerdem suche ich nach praktischen Tipps zur Verwendung von Git im Unternehmen . Ich habe eine ganze Wäscheliste mit Problemen, die wir haben, ganz oben auf diese Frage gesetzt. Auch hier können die Leute gerne über Theorie diskutieren, aber wenn Sie das Kopfgeld verdienen möchten, geben Sie mir Lösungen.

Entgegen der allgemeinen Meinung denke ich, dass die Verwendung eines DVCS eine ideale Wahl in einem Unternehmen ist, da es sehr flexible Workflows ermöglicht. Ich werde zuerst über die Verwendung eines DVCS vs. CVCS sprechen, über Best Practices und dann insbesondere über Git.

DVCS vs. CVCS im Unternehmenskontext:

Ich werde hier nicht über die allgemeinen Vor- und Nachteile sprechen, sondern mich auf Ihren Kontext konzentrieren. Es ist die gängige Auffassung, dass die Verwendung eines DVCS ein disziplinierteres Team erfordert als die Verwendung eines zentralisierten Systems. Dies liegt daran, dass ein zentrales System Ihnen eine einfache Möglichkeit bietet , Ihren Workflow durchzusetzen . Die Verwendung eines dezentralen Systems erfordert mehr Kommunikation und Disziplin, um die festgelegten Konventionen einzuhalten. Dies scheint zwar Overhead zu verursachen, aber ich sehe einen Vorteil in der verstärkten Kommunikation, die erforderlich ist, um einen guten Prozess zu erzielen. Ihr Team muss über Code, Änderungen und den Projektstatus im Allgemeinen kommunizieren.

Eine weitere Dimension im Kontext der Disziplin ist die Förderung von Verzweigungen und Experimenten. Hier ist ein Zitat aus Martin Fowlers jüngstem Bliki-Eintrag zu den Versionskontroll-Tools . Er hat eine sehr präzise Beschreibung für dieses Phänomen gefunden.

DVCS fördert eine schnelle Verzweigung zum Experimentieren. Sie können Zweige in Subversion erstellen, aber die Tatsache, dass sie für alle sichtbar sind, hält die Benutzer davon ab, einen Zweig für experimentelle Arbeiten zu öffnen. In ähnlicher Weise empfiehlt ein DVCS das Überprüfen der Arbeit: Übertragen Sie unvollständige Änderungen, die möglicherweise nicht einmal kompiliert werden oder Tests bestehen, an Ihr lokales Repository. Wiederum könnten Sie dies in einem Entwicklerzweig in Subversion tun, aber die Tatsache, dass sich solche Zweige im gemeinsam genutzten Bereich befinden, verringert die Wahrscheinlichkeit, dass Benutzer dies tun.

DVCS ermöglicht flexible Workflows, da sie die Verfolgung von Änderungssätzen über global eindeutige Bezeichner in einem gerichteten azyklischen Diagramm (DAG) anstelle einfacher Textunterschiede ermöglichen. Auf diese Weise können sie den Ursprung und den Verlauf eines Änderungssatzes transparent verfolgen, was sehr wichtig sein kann.

Workflows:

Larry Osterman (ein Microsoft-Entwickler, der im Windows-Team arbeitet) hat einen großartigen Blog-Beitrag über den Workflow, den sie im Windows-Team verwenden. Vor allem haben sie:

• Ein sauberer, qualitativ hochwertiger Trunk nur für Code (Master Repo)
• Die gesamte Entwicklung erfolgt in Feature-Zweigen
• Feature-Teams haben Team-Repos
• Sie führen die neuesten Trunk-Änderungen regelmäßig in ihrem Feature-Zweig zusammen ( Forward Integrate ).
• Komplette Funktionen müssen mehrere Qualitätstore bestehen, z. B. Überprüfung, Testabdeckung, Fragen und Antworten (Repos für sich allein).
• Wenn ein Feature abgeschlossen ist und eine akzeptable Qualität aufweist, wird es in den Trunk integriert ( Reverse Integrate ).

Wie Sie sehen können, können Sie, wenn jedes dieser Repositories für sich aktiv ist, verschiedene Teams entkoppeln, die in unterschiedlichen Schritten vorankommen. Auch die Möglichkeit, ein flexibles Qualitätsgattersystem zu implementieren, unterscheidet DVCS von einem CVCS. Sie können Ihre Berechtigungsprobleme auch auf dieser Ebene lösen. Nur einer Handvoll Personen sollte der Zugang zum Master-Repo gewährt werden. Erstellen Sie für jede Ebene der Hierarchie ein separates Repo mit den entsprechenden Zugriffsrichtlinien. In der Tat kann dieser Ansatz auf Teamebene sehr flexibel sein. Sie sollten es jedem Team überlassen, zu entscheiden, ob es sein Team-Repo unter sich teilen möchte oder ob es einen hierarchischeren Ansatz wünscht, bei dem nur der Teamleiter sich zum Team-Repo verpflichten darf.

(Das Bild wurde von Joel Spolskys hginit.com gestohlen .)

An dieser Stelle bleibt jedoch noch eines zu sagen: - Obwohl DVCS hervorragende Zusammenführungsfunktionen bietet, ist dies niemals ein Ersatz für die Verwendung der kontinuierlichen Integration. Selbst zu diesem Zeitpunkt haben Sie ein hohes Maß an Flexibilität: CI für das Trunk-Repo, CI für Team-Repos, Q & A-Repos usw.

Git im Unternehmenskontext:

Git ist möglicherweise nicht die ideale Lösung für einen Unternehmenskontext, wie Sie bereits betont haben. Ich wiederhole einige Ihrer Bedenken und denke vor allem:

• Noch etwas unausgereifte Unterstützung unter Windows (bitte korrigieren Sie mich, wenn sich das kürzlich geändert hat) Jetzt hat Windows Github Windows Client , Tortoisegit , SourceTree von atlassian
• Mangel an ausgereiften GUI-Tools, keine erstklassige Integration von Bürger-Vdiff / Merge-Tools
• Inkonsistente Schnittstelle mit einem sehr geringen Grad an Abstraktionen zusätzlich zu ihrem Innenleben
• Eine sehr steile Lernkurve für SVN-Benutzer
• Git ist sehr leistungsfähig und macht es einfach, den Verlauf zu ändern. Sehr gefährlich, wenn Sie nicht wissen, was Sie tun (und manchmal sogar, wenn Sie dachten, Sie wüssten es).
• Keine kommerziellen Support-Optionen verfügbar

Ich möchte hier keinen Git vs. Hg Flamewar starten, Sie haben bereits den richtigen Schritt getan, indem Sie zu einem DVCS gewechselt sind. Mercurial spricht einige der oben genannten Punkte an und ist daher meiner Meinung nach im Unternehmenskontext besser geeignet:

• Alle Plattformen, auf denen Python ausgeführt wird, werden unterstützt
• Hervorragende GUI-Tools auf allen wichtigen Plattformen (Win / Linux / OS X), erstklassige Integration von Merge- / Vdiff-Tools
• Sehr konsistente Oberfläche, einfacher Übergang für SVN-Benutzer
• Kann die meisten Dinge tun, die Git auch kann, bietet aber eine sauberere Abstraktion. Gefährliche Operationen sind immer explizit. Erweiterte Funktionen werden über Erweiterungen bereitgestellt, die explizit aktiviert werden müssen.
• Kommerzielle Unterstützung erhalten Sie von Selenic.

Kurz gesagt, wenn Sie DVCS in einem Unternehmen verwenden, ist es meiner Meinung nach wichtig, ein Tool zu wählen, das die geringste Reibung einführt. Für einen erfolgreichen Übergang ist es besonders wichtig, die unterschiedlichen Fähigkeiten der Entwickler (in Bezug auf VCS) zu berücksichtigen.

Reibung reduzieren:

Ok, da Sie wirklich mit der Situation festzuhalten scheinen, gibt es meiner Meinung nach noch zwei Möglichkeiten. Es gibt kein Werkzeug, um Git weniger kompliziert zu machen. Git ist kompliziert. Entweder du konfrontierst das oder du arbeitest um Git: -

1. Holen Sie sich einen Git-Einführungskurs für das gesamte Team. Dies sollte nur die Grundlagen und einige Übungen (wichtig!) Enthalten.
2. Konvertieren Sie das Master-Repo in svn und lassen Sie die "jungen Stars" git-svn . Dies gibt den meisten Entwicklern eine benutzerfreundliche Oberfläche und kann die mangelnde Disziplin in Ihrem Team ausgleichen, während die jungen Stars weiterhin Git für ihre eigenen Repos verwenden können.

Um ehrlich zu sein, ich denke, Sie haben wirklich eher ein Menschenproblem als ein Werkzeugproblem. Was kann getan werden, um diese Situation zu verbessern?

• Sie sollten klarstellen, dass Ihr aktueller Prozess eine wartbare Codebasis haben wird.
• Investieren Sie etwas Zeit in die kontinuierliche Integration. Wie ich oben dargelegt habe, gibt es unabhängig von der Art des verwendeten VCS keinen Ersatz für CI. Sie haben angegeben, dass es Leute gibt, die Mist in das Master-Repo schieben: Lassen Sie sie ihren Mist reparieren, während ein roter Alarm ausgelöst wird, und beschuldigen Sie sie, den Build gebrochen zu haben (oder eine Qualitätsmetrik oder was auch immer nicht zu erfüllen).

Ich bin der SCM-Ingenieur für eine relativ große Entwicklungsorganisation, und wir haben im letzten Jahr oder so von svn auf git umgestellt. Wir nutzen es zentral.

Wir verwenden Gitosis , um die Repositories zu hosten. Wir haben unsere monolithischen SVN-Repositorys in viele kleinere Git-Repositorys aufgeteilt, da die Verzweigungseinheit von Git im Grunde das Repository ist. (Es gibt Möglichkeiten, dies zu umgehen , aber sie sind umständlich.) Wenn Sie branchenübergreifende Zugriffskontrollen wünschen , ist Capitolit möglicherweise der bessere Ansatz. Es gibt auch eine Version von GitHub innerhalb der Firewall, wenn Sie das Geld ausgeben möchten. Für unsere Zwecke ist Gitosis in Ordnung, da wir ziemlich offene Berechtigungen für unsere Repositories haben. (Wir haben Gruppen von Personen, die Schreibzugriff auf Gruppen von Repositorys haben, und jeder hat Lesezugriff auf alle Repositorys.) Wir verwenden gitweb für eine Weboberfläche.

Einige Ihrer spezifischen Anliegen:

• Zusammenführungen: Sie können ein visuelles Zusammenführungswerkzeug Ihrer Wahl verwenden. An verschiedenen Stellen finden Sie Anweisungen zum Einrichten. Die Tatsache, dass Sie die Zusammenführung durchführen und ihre Gültigkeit vollständig auf Ihrem lokalen Repo überprüfen können, ist meiner Meinung nach ein großes Plus für git; Sie können die Zusammenführung überprüfen, bevor Sie etwas verschieben.
• GUIs: Wir haben ein paar Leute, die TortoiseGit verwenden, aber ich empfehle es nicht wirklich. Es scheint auf seltsame Weise mit der Befehlszeile zu interagieren. Ich muss zustimmen, dass dies ein Bereich ist, der verbessert werden muss. (Trotzdem bin ich kein Fan von GUIs für die Versionskontrolle im Allgemeinen.)
• Tracking-Zweige für kleine Gruppen: Wenn Sie etwas verwenden, das feinkörnigere ACLs wie Gitolite bereitstellt, ist dies einfach genug. Sie können jedoch auch einen gemeinsam genutzten Zweig erstellen, indem Sie die lokalen Repositorys verschiedener Entwickler verbinden. Ein Git-Repo kann mehrere Fernbedienungen haben.

Wir sind zu Git gewechselt, weil wir viele Remote-Entwickler haben und weil wir viele Probleme mit Subversion hatten. Wir experimentieren immer noch mit Workflows, aber im Moment verwenden wir sie im Grunde genauso wie früher Subversion. Eine andere Sache, die uns daran gefallen hat, war, dass es andere mögliche Workflows eröffnet hat, wie die Verwendung von Staging-Repositorys für die Codeüberprüfung und die gemeinsame Nutzung von Code zwischen kleinen Gruppen. Es wird auch vielen Leuten empfohlen, ihre persönlichen Skripte usw. zu verfolgen, weil es so einfach ist, ein Repository zu erstellen.

Ja, ich weiß, Linus hat es nie dafür vorgesehen.

Tatsächlich argumentiert Linus, dass zentralisierte Systeme einfach nicht funktionieren können.

Und was ist los mit dem Workflow von Diktatoren und Leutnants?

Denken Sie daran, Git ist ein verteiltes System. Versuchen Sie nicht, es wie ein zentrales zu verwenden.

(Aktualisiert)

Die meisten Ihrer Probleme verschwinden, wenn Sie nicht versuchen, git so zu verwenden, als wäre es "svn on steroids" (weil es nicht so ist).

Anstatt ein nacktes Repository als zentralen Server zu verwenden, auf den jeder pushen kann (und möglicherweise Fehler macht), richten Sie einige Integrationsmanager ein, die Zusammenführungen verarbeiten, sodass nur sie auf das nackte Repository pushen können.

Normalerweise sollten diese Personen die Teamleiter sein: Jeder Leiter integriert die Arbeit seines eigenen Teams und schiebt sie in das gesegnete Repository.

Noch besser ist, dass jemand anderes (dh ein Diktator) sich von den Teamleitern zurückzieht und ihre Änderungen in das gesegnete Repository integriert.

An diesem Workflow ist nichts auszusetzen, aber wir sind ein überarbeitetes Startup und benötigen unsere Tools, um die menschliche Zeit und Aufmerksamkeit zu ersetzen. Niemand hat Bandbreite, um Codeüberprüfungen durchzuführen, geschweige denn ein wohlwollender Diktator.

Wenn die Integratoren keine Zeit haben, Code zu überprüfen, ist das in Ordnung, aber Sie müssen immer noch Leute haben, die die Zusammenführungen von allen integrieren.

Git Pulls zu machen dauert nicht allzu lange.

git pull A
git pull B
git pull C

git tut Ersatz für menschliche Zeit und Aufmerksamkeit; Deshalb wurde es an erster Stelle geschrieben.

• Die GUI-Tools sind nicht ausgereift

Die GUI-Tools können mit den grundlegenden Dingen ziemlich gut umgehen.

Fortgeschrittene Operationen erfordern eine Codierer- / Nerd-Denkweise (z. B. arbeite ich bequem über die Befehlszeile). Es braucht etwas Zeit, um die Konzepte zu verstehen, aber es ist nicht so schwer.

• Mit den Befehlszeilen-Tools ist es viel zu einfach, eine Zusammenführung zu vermasseln und die Änderungen anderer zu löschen

Dies ist kein Problem, es sei denn, Sie haben viele inkompetente Entwickler mit vollem Schreibzugriff auf das "zentrale Repository".

Wenn Sie Ihren Workflow jedoch so einrichten, dass nur wenige Personen (Integratoren) in das "gesegnete" Repository schreiben, ist dies kein Problem.

Git macht es nicht einfach, Zusammenführungen zu vermasseln.

Wenn es Zusammenführungskonflikte gibt, markiert git die widersprüchlichen Zeilen deutlich, sodass Sie wissen, welche Änderungen Ihnen gehören und welche nicht.

Es ist auch einfach, den Code anderer Leute mit svn oder einem anderen (nicht verteilten) Tool zu löschen. Tatsächlich ist es mit diesen anderen Tools viel einfacher, weil Sie dazu neigen, lange Zeit auf Änderungen zu sitzen, und irgendwann können die Zusammenführungen schrecklich schwierig werden.

Und weil diese Tools nicht wissen, wie sie zusammengeführt werden sollen, müssen Sie die Dinge immer manuell zusammenführen. Sobald beispielsweise jemand eine Festschreibung für eine Datei vornimmt, die Sie lokal bearbeiten, wird dies als Konflikt markiert, der manuell gelöst werden muss. jetzt , dass eine Wartung Alptraum.

Mit git gibt es die meiste Zeit keine Zusammenführungskonflikte, da git tatsächlich zusammengeführt werden kann. Im Falle eines Konflikts markiert git die Linien für Sie deutlich, sodass Sie genau wissen , welche Änderungen Ihnen gehören und welche Änderungen von anderen Personen stammen.

Wenn jemand die Änderungen anderer Personen bei der Lösung eines Zusammenführungskonflikts auslöscht, ist dies kein Fehler: Entweder weil dies für die Konfliktlösung erforderlich war oder weil er nicht weiß, was er tut.

• Es bietet keine Repository-Berechtigungen pro Benutzer, die über die globalen Nur-Lese- oder Lese- / Schreibrechte hinausgehen

• Wenn Sie die Berechtigung für JEDEN Teil eines Repositorys haben, können Sie JEDEN Teil des Repositorys auf dieselbe Weise ausführen. Sie können also nicht so etwas wie einen Verfolgungszweig für kleine Gruppen auf dem zentralen Server erstellen, den andere Benutzer nicht können sich anlegen mit.

• Andere Arbeitsabläufe als "alles geht" oder "wohlwollender Diktator" sind schwer zu fördern, geschweige denn durchzusetzen

Diese Probleme verschwinden, wenn Sie aufhören, git so zu verwenden, als wäre es ein zentrales System.

• Es ist nicht klar, ob es besser ist, ein einzelnes großes Repository (mit dem jeder mit allem herumspielen kann) oder viele Repositorys pro Komponente zu verwenden (was zu Kopfschmerzen beim Versuch führt, Versionen zu synchronisieren).

Urteilsruf.

Welche Art von Projekten haben Sie?

Beispiel: Hängt die Version xy von Projekt A von der genauen Version wz von Projekt B ab, sodass Sie jedes Mal , wenn Sie xy von Projekt A überprüfen, auch wz von Projekt B auschecken müssen, da sie sonst nicht erstellt wird? Wenn ja, würde ich sowohl Projekt A als auch Projekt B in dasselbe Repository stellen, da sie offensichtlich zwei Teile eines einzelnen Projekts sind.

Die beste Vorgehensweise hier ist, Ihr Gehirn zu benutzen

• Bei mehreren Repositorys ist es auch nicht klar, wie alle Quellen, die jemand anderes hat, durch Abrufen aus dem zentralen Repository repliziert werden sollen, oder wie man gestern Nachmittag ab 4:30 Uhr alles abruft.

Ich bin mir nicht sicher was du meinst.

Ich empfehle http://code.google.com/p/gerrit/ für Unternehmensarbeiten. Sie erhalten Zugriffskontrolle sowie einen integrierten, auf Überprüfungen basierenden Workflow. Es authentifiziert sich gegen jedes LDAP-System. Sie können es mit http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin an Hudson anschließen , sodass Sie Änderungen erstellen und testen können, während sie noch überprüft werden. Es ist ein wirklich beeindruckendes Setup.

Wenn Sie sich für Gerrit entscheiden, empfehle ich, eine ziemlich lineare Historie beizubehalten, keine verzweigte Historie, wie sie einige Open-Source-Leute mögen. Gerrit formuliert dies als "nur Änderungen im Schnellvorlauf zulassen". Dann können Sie das Verzweigen und Zusammenführen mehr wie gewohnt für Releases und so weiter verwenden.

Ich beantworte diese Frage aufgrund meiner Erfahrung als Entwickler-Manager in einem großen Telekommunikationsunternehmen, in dem wir Git 2010 eingeführt haben

Sie haben hier ganz andere Probleme:

• Workflows
• Client-Tools
• Serverzugriffskontrolle und Integration

Workflows

Wir haben erfolgreich einen zentralen Repository-Modus eingeführt: Was wir in unserem Unternehmensprojekt haben (ein großes Portal für eine 5-Millionen-Benutzerbasis), ist ein de facto zentrales Repository, das die offiziellen Builds erstellt und dann durch den Bereitstellungsprozess geführt wird (der in unserem Fall besteht aus drei Testebenen und zwei Bereitstellungen). Jeder Entwickler verwaltet sein eigenes Repo, und wir arbeiten nach Filialen.

Client-Tools

Es gibt jetzt mehrere Optionen, dies ist jetzt ein sehr überfüllter Bereich. Viele Entwickler verwenden IntelliJ Idea und Eclipse erfolgreich mit dem Git-Plugin , ohne andere Dinge. Auch die meisten Linux-Entwickler verwenden problemlos den CLI-Git-Client. Einige Mac-Entwickler verwenden Tower Git erfolgreich . Bitte beachten Sie, dass keiner dieser Clients verhindern kann, dass der Benutzer das zentrale Repository "durcheinander bringt": Ein serverseitiger Steuerungsmechanismus ist erforderlich

Serverzugriffskontrolle und -integration

Wenn Sie vermeiden möchten, dass Entwickler Ihr Git-Repository "durcheinander bringen", müssen Sie wirklich eine Lösung wählen, die:

• stellt eine anständige Webadministrationsoberfläche zur Verfügung, um jeden Vorgang auszuführen
• ermöglicht es Ihnen, Benutzeridentitäten zu erzwingen (die Verwendung eines "nackten" Git-Repositorys ist extrem einfach, im Namen einer anderen Person festzuschreiben)
• bietet Ihnen fein abgestimmte Sicherheit (so dass Sie beispielsweise FORCE-PUSH verhindern und einige Zweige so einstellen können, dass sie nur für einige Entwickler / Gruppen schreibgeschützt sind)
• Integration in Ihr Unternehmensauthentifizierungssystem (z. B. LDAP, Windows ActiveDirectory)
• bietet Ihnen eine vollständige Prüfung (SOX-Konformität ist für große Unternehmen manchmal sehr wichtig)

Es gibt nicht so viele gebrauchsfertige serverseitige Lösungen, die dies unterstützen können. Ich schlage vor, Sie sehen sich eine der folgenden Lösungen an:

• Gitorious : Es kann grundlegende Sicherheit auf Zugriffsebene bieten, es fehlt jedoch sofort eine fein abgestimmte Berechtigungssteuerung, sodass Sie wahrscheinlich einige Codierungen vornehmen müssen, um Szenarien wie Berechtigungen auf Zweigstellenebene zu verarbeiten. Es fehlt auch die Integration in vorhandene Unternehmensauthentifizierungsmechanismen
• GitHub Enterprise: Kürzlich von GitHub veröffentlicht, enthält es GitHub in Ihrem Unternehmen. Es fehlt SOX-Konformität und feinkörnige Sicherheit
• Gerrit : Es kann eine gute Sicherheit auf Zugriffsebene und die Integration in Unternehmensauthentifizierungssysteme bieten, es fehlen jedoch SOX-Konformität und SSO. Einige Vorgänge können auch nur über SSH über CLI ausgeführt werden
• GitEnterprise : Es bietet Berechtigungen auf Zweigstellenebene, SSO, SOX-Konformität und vollständige webbasierte Verwaltung. Es wurde kürzlich auch in Gerrit integriert, sodass Sie auch eine vollständige Gerrit-Instanz erhalten

Hoffe das hilft!

Es klingt so, als ob Ihr Problem darin besteht, dass Sie sich nicht für einen Workflow entschieden oder ihn eingerichtet haben. Git ist flexibel genug, um es wie svn oder jedes andere VCS zu verwenden, aber es ist so leistungsfähig, dass Sie, wenn Sie keine Regeln festlegen, denen jeder folgen muss, nur ein Durcheinander bekommen. Ich würde den oben erwähnten Workflow für Diktatoren und Leutnants empfehlen, der jedoch mit dem von Vincent Driessen beschriebenen Verzweigungsmodell kombiniert wird . Weitere Informationen finden Sie in diesen Screencasts von David Bock und in diesem von Mark Derricutt .

MacOS-X-Benutzer finden GitX (http://gitx.frim.nl/) in den Tools sehr einfach und effektiv. Nachteil ist, dass Git Client-Hooks nicht unterstützt werden (die unter $ GIT_ROOT / .git / hooks).

Insgesamt habe ich mich nachdrücklich für ein Tool entschieden, das eine differenzierte Zugriffskontrolle für folgende Bereiche unterstützt : - Zweige (um die stabilen Release-Zweige mit strikter Sicherheit von den Themenzweigen zu trennen, die mehr Flexibilität und Flexibilität erfordern) - Identitätsdurchsetzung (Autor / Committer) ). Dies ist der Schlüssel für SOX - Einschränkungen für Git-Befehle - Audit-Trail. Dies ist der Schlüssel für SOX

Diejenigen, die ich mit diesen Funktionen erfolgreich verwendet habe, sind:

1. Gerrit Code Review (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit) verwendet Gerrit 2.1.8 hinter den Kulissen

PS Unterschätzen Sie nicht die SOX- und CMMI-Konformität : Oft haben Sie nur eine begrenzte Auswahl, die von Ihren Unternehmensrichtlinien zur Sicherheit vorgegeben wird.

Hoffe das hilft.

Luca.

Wir haben kürzlich von svn zu git gewechselt. Da git-daemon nicht mit msysgit funktioniert, haben wir uns für einen zentralen Repository-Ansatz auf einem Linux-Server mit gitosis entschieden.

Um die Möglichkeit auszuschließen, den Master zu vermasseln, haben wir ihn einfach geschält. Stattdessen bereiten wir alle Releases vor, indem wir die zum Testen ausgewählten Zweige zusammenführen und die Zusammenführung markieren. Wenn es Tests besteht, wird das Commit mit einer Version versehen und in Produktion genommen.

Um dies zu handhaben, haben wir eine rotierende Rolle als Release Manager. Der Release Manager ist dafür verantwortlich, jeden Zweig zu überprüfen, bevor er zum Testen bereit ist. Wenn der Produktbesitzer entscheidet, dass es Zeit ist, die genehmigten Zweige für eine neue Testversion zu bündeln, führt der Release-Manager die Zusammenführung durch.

Wir haben auch eine rotierende Rolle als Helpdesk der 2. Ebene und zumindest für uns ist die Arbeitsbelastung so, dass es möglich ist, beide Rollen gleichzeitig zu haben.

Da kein Master vorhanden ist, kann dem Projekt kein Code hinzugefügt werden, ohne den Release-Manager zu durchlaufen. Daher haben wir direkt festgestellt, wie viel Code zuvor stillschweigend zum Projekt hinzugefügt wurde.

Der Überprüfungsprozess beginnt damit, dass der Filialbesitzer das Diff an das Reviewboard sendet und ein grünes Post-It mit dem Filialnamen (wir haben einen Kanban-basierten Workflow) unter "zur Überprüfung" oder wenn es Teil eines abgeschlossenen Benutzers ist, auf dem Whiteboard anbringt Verschieben Sie die gesamte Story-Karte auf "Zur Überprüfung" und setzen Sie das Postit darauf. Der Relase-Manager ist derjenige, der Karten und Post-its auf "Testbereit" verschiebt. Anschließend kann der Product Owner auswählen, welche Karten in der nächsten Testversion enthalten sein sollen.

Beim Zusammenführen stellt der Release-Manager außerdem sicher, dass das Zusammenführungs-Commit eine sinnvolle Commit-Nachricht enthält, die im Änderungsprotokoll für den Product Owner verwendet werden kann.

Wenn ein Release in Produktion gegangen ist, wird das Tag als neue Basis für Zweige verwendet und alle vorhandenen Zweige werden mit diesem zusammengeführt. Auf diese Weise haben alle Zweige ein gemeinsames übergeordnetes Element, was die Handhabung von Zusammenführungen erleichtert.

Ich werde auch einen Beitrag "Haben Sie darüber nachgedacht" hinzufügen.

Eines der großartigen Dinge an Bazaar ist seine Flexibilität. Hier schlägt es alle anderen verteilten Systeme. Sie können Bazaar im zentralisierten oder verteilten Modus betreiben oder beides: Dies bedeutet, dass Entwickler auswählen können, mit welchem ​​Modell sie vertraut sind oder welches für ihre Arbeitsgruppe am besten geeignet ist. Sie können auch ein zentrales Repository trennen, während Sie unterwegs sind, und es wieder verbinden, wenn Sie zurückkehren.

Darüber hinaus eine hervorragende Dokumentation und etwas, das Ihr Unternehmen glücklich macht: kommerzieller Support.

• Installieren Sie ein anständiges Webinterface wie Github FI
• Halten Sie sich (anfangs) an ein relativ zentrales Modell, um den Menschen Komfort zu bieten.
• Führen Sie für jeden gemeinsam genutzten Zweig einen Build für die kontinuierliche Integration aus .
• Teilen Sie eine gute Auswahl an globalen Git-Konfigurationsoptionen.
• Integrieren Sie Git in Ihre Shell, mit Bash-Abschluss und einer Eingabeaufforderung mit dem aktuellen Zweig.
• Probieren Sie die Git-Integration von IntelliJ als Zusammenführungswerkzeug aus.
• Stellen Sie sicher, dass Sie .gitignore entsprechend.

In Bezug auf die Punkte 3 und 4 (Berechtigungen pro Benutzer, pro Abschnitt, pro Zweig) werfen Sie einen Blick auf gitolite (behandelt im Pro Git-Buch: http://progit.org/book/ch4-8.html ).

Politik oder nicht, Git ist eine ebenso gute Wahl für ein DCVS wie jedes andere. Wie bei jedem leistungsstarken Tool lohnt es sich, ein wenig Zeit im Voraus zu investieren, um zu verstehen, wie das Tool funktioniert. Zu diesem Zweck empfehle ich das Pro Git-Buch. Ein paar Stunden damit werden auf lange Sicht viel Frust ersparen.

GUI: Im Moment sollte TortoiseGit v1.7.6 für die meisten täglichen Operationen in Ordnung sein. Protokollieren, Festschreiben, Drücken, Ziehen, Abrufen, Diff, Zusammenführen, Verzweigen, Cherry-Pick, Rebase, Tag, Exportieren, Verstecken, Hinzufügen von Submodulen usw. Unterstützt x64 auch nativ

Um git in einem Entwicklungsteam mit vielen Entwicklern effizient nutzen zu können, ist ein CI-System erforderlich, das kontinuierlich erstellt und getestet wird. Jenkins bietet ein solches Fahrzeug an und ich kann es nur empfehlen. Das Integrationsstück muss auf jeden Fall gemacht werden und es ist viel billiger, das früher und öfter zu machen.

Gitorious ist eher für die kollabrative Entwicklung geeignet als Gitosis oder Gitolite, aber Open Source ist Gitorious . Es ist eine Ruby on Rails-Anwendung, die die Verwaltung von Repositorys und das Zusammenführen übernimmt. Es sollte viele Ihrer Probleme lösen.

Mit Git können private Zweige erstellt werden. Dies ermutigt Entwickler, häufig Commits durchzuführen, um Änderungen in kleine Commits aufzuteilen. Wenn der Entwickler bereit ist, seine Änderungen zu veröffentlichen, wechselt er zum zentralen Server. Er kann Pre-Commit-Skripte verwenden, um seinen Code bei Bedarf zu überprüfen.

NXP verwaltet Git und Subversion mit einer gemeinsamen Plattform (im Unternehmensmaßstab) und integriert die mobile Android-Entwicklung in herkömmliche Softwareprojekte: http://www.youtube.com/watch?v=QX5wn0igv7Q