Git-basierte Quellcodeverwaltung im Unternehmen: Vorgeschlagene Tools und Praktiken?
Ich benutze git für persönliche Projekte und finde es toll. Es ist schnell, flexibel, leistungsstark, und funktioniert Super für die remote-Entwicklung.
Aber es ist jetzt beauftragt, bei der Arbeit und, ehrlich gesagt, wir haben Probleme.
Out of the box, git scheint nicht gut zu funktionieren für die zentrale Entwicklung in einem großen (20+ Entwickler) Organisation mit den Entwicklern von unterschiedlichen Fähigkeiten und Ebenen der git Raffinesse, vor allem im Vergleich mit anderen source-control-Systeme wie Perforce oder Subversion, die sich an dieser Art von Umgebung. (Ja, ich weiß, Linus nie gedacht, es.)
Aber - aus politischen Gründen - wir stecken mit git, auch wenn es nervt, für das, was wir versuchen zu tun.
Hier sind einige der Dinge, die wir sehen:
- Die GUI-tools nicht ausgereift
- Mithilfe der Kommandozeilen-tools, es ist viel zu einfach zu Schraube bis ein verschmelzen und verwischen jemand anderes änderungen
- Es nicht pro-user-repository-Berechtigungen über Globale lese-oder lese- /Schreibzugriff Berechtigungen
- Wenn Sie die Berechtigung haben, zu JEDEM Teil eines Repositorys, die Sie tun können, die gleiche Sache, die zu JEDEM Teil des Repositorys, so dass Sie nicht tun können, so etwas wie eine kleine-Gruppe-tracking-branch auf dem zentralen server, die andere Leute nicht Durcheinander.
- Workflows, die andere als "anything goes" oder "wohlwollenden Diktator" sind schwer zu fördern, geschweige denn durchzusetzen
- Es ist nicht klar, ob es besser ist, verwenden Sie eine einzige große Ablage (die kann jeder Durcheinander mit allem) oder eine Menge von pro-Komponenten-repositories (die für Kopfschmerzen versucht zu synchronisieren-Versionen).
- Mit mehreren repositories, es ist auch nicht klar, wie das replizieren aller Quellen, die jemand anderes hat, der durch das ziehen aus dem zentralen repository, oder etwas zu tun, wie alles bekommen, was ab 4:30 gestern Nachmittag.
Aber ich habe gehört, dass Menschen mit git erfolgreich in großen Organisationen der Entwicklungszusammenarbeit.
Wenn Sie in so einer situation - oder wenn Sie haben in der Regel tools, Tipps und tricks für die macht es einfacher und produktiver zu nutzen git in einer großen Organisation, wo einige Leute sind nicht Kommandozeilen-fans - ich würde gerne hören, was Sie vorschlagen.
BTW, ich habe gefragt, eine version dieser Frage bereits auf LinkedIn, und bekam keine richtige Antwort, aber viele "Oh Mann, ich würde lieben, zu wissen, dass auch!"
AKTUALISIEREN: Lassen Sie mich klarstellen...
, Wo ich arbeite, wir können nicht ALLES andere als git. Es ist nicht eine option. Wir ' re mit es stecken. Können wir nicht verwenden, mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, oder auch Apple 's good ol' Projektor, den ich im Jahr 1987. So, während Sie sind willkommen, um zu diskutieren, andere Optionen, Sie ain ' T gonna bekommen die bounty, wenn du nicht diskutieren git.
Auch, ich bin auf der Suche nach praktische Tipps, wie Sie mithilfe von git im enterprise -. Ich habe eine ganze Wäsche Liste der Probleme die wir gerade haben an der Spitze dieser Frage. Wieder, Menschen sind willkommen, um zu diskutieren Theorie, aber wenn Sie verdienen wollen das Kopfgeld, geben Sie mir Lösungen.
ein Prozess
... (ich hasse dieses Wort) InformationsquelleAutor der Frage Bob Murphy | 2010-03-05
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gegen die Allgemeine Meinung, ich denke, dass mit einem DVCS ist eine ideale Wahl für ein Unternehmen einstellen, weil Sie es ermöglicht sehr flexible workflows. Ich werde sprechen über die Verwendung von ein DVCS vs. CVCS first, best-practices und dann über git im besonderen.
DVCS vs. CVCS in einem enterprise-Kontext:
Ich werde nicht sprechen Sie über die Allgemeinen vor - /Nachteile hier, sondern konzentrieren Sie sich auf Ihren Kontext. Es ist die gemeinsame Vorstellung, dass mit einem DVCS erfordert eine diszipliniertere team, als mit einem zentralen system. Dies ist, weil ein zentralisiertes system bietet Ihnen eine einfache Möglichkeit, um durchzusetzen Ihren workflow, mit Hilfe eines dezentralen Systems erfordert mehr Kommunikation und Disziplin zu bleiben, die etablierten Konventionen. Während dieses scheinen kann, wie es induziert overhead, sehe ich den Vorteil in der erhöhten Kommunikation erforderlich ist, damit es ein guter Prozess. Ihr team benötigen, um die Kommunikation über code, über Veränderungen und über Projekt-status im Allgemeinen.
Andere dimension im Zusammenhang mit der Disziplin ist die Förderung Verzweigung und Experimente. Hier ist ein Zitat aus Martin Fowlers jüngsten bliki-Eintrag auf Version Control Tools, er hat eine sehr prägnante Beschreibung für dieses Phänomen.
DVCS ermöglicht flexible workflows, da Sie changeset tracking über weltweit eindeutige Bezeichner, die in einem gerichteten azyklischen graph (DAG) statt einfacher textueller diffs. Dies ermöglicht Ihnen, transparent verfolgen die Herkunft und Geschichte einer änderungsmenge, die kann sehr wichtig sein.
Workflows:
Larry Osterman (eine Microsoft-dev arbeiten auf der Windows-team) hat eine große blog-post über den workflow, die Sie beschäftigen, auf der Windows-team. Vor allem Sie haben:
Wie man sehen kann, mit jedem dieser repositories Leben auf Ihrem eigenen, können Sie entkoppeln die verschiedenen teams schreitet unterschiedlich. Auch die Möglichkeit zu implementieren eine flexible quality gate system unterscheidet DVCS von einem CVCS. Können Sie lösen Ihre Probleme mit Berechtigungen auf dieser Ebene zu. Nur eine Handvoll Menschen erlaubt sein sollte, den Zugang zu den master-repo. Für jede Stufe der Hierarchie, haben ein separates repo mit den entsprechenden access-Richtlinien. In der Tat, dieser Ansatz kann sehr flexibel auf die team-Ebene. Sie sollten lassen Sie es bis zu jedem team, zu entscheiden, ob Sie freigeben möchten Ihre team-repo unter sich oder, wenn Sie wollen eine mehr hierarchische Ansatz, wo nur das team führen kann, verpflichten sich die team-repo.
(Das Bild ist geklaut von Joel Spolsky ' s hginit.com.)
Eins zu sagen bleibt an diesem Punkt aber:- obwohl DVCS bietet tolle Zusammenführen von Fähigkeiten, das ist nie einen Ersatz für die Verwendung von Continuous Integration. Auch an diesem Punkt haben Sie ein hohes Maß an Flexibilität: CI für die Stamm-repo, das CI-team repos, Q&A-repos etc.
Git im enterprise-Kontext:
Git ist vielleicht nicht die ideale Lösung für eine Unternehmens-Kontext, wie Sie schon hervorgehoben haben. Wiederholen einige deiner Bedenken, ich denke, vor allem Sie sind:
Noch etwas unreif-Unterstützung unter Windows (bitte korrigieren Sie mich, wenn das vor kurzem geändert)Jetzt windows hat github-windows-client , tortoisegit , SourceTree von atlassianIch nicht anfangen wollen, ein git vs. hg flamewar hier, Sie haben bereits das richtige getan Schritt durch die Umstellung auf ein DVCS. Mercurial-Adressen einige der oben genannten Punkte und ich denke, es ist daher besser geeignet, in einem Unternehmen Kontext:
Kurz gesagt, wenn Sie mit DVCS in einer Firma, in der ich denke, es ist wichtig, wählen ein Werkzeug, das eine Einführung in die am wenigsten Reibung. Für den übergang erfolgreich zu sein, ist es besonders wichtig, die unterschiedlichen Fähigkeiten zwischen den Entwicklern (in Bezug auf VCS).
Reduzierung der Reibung:
Ok, da Ihr scheinbar wirklich stecken mit der situation, gibt es zwei Möglichkeiten bleiben IMHO.
Es gibt kein tool, um git weniger kompliziert; git ist kompliziert. Entweder Sie konfrontieren dieses oder arbeiten rund um git:-
Um ehrlich zu sein, ich denke, Sie haben wirklich ein problem Personen eher als ein Werkzeug-problem. Was kann getan werden, um zu verbessern, auf diese situation?
InformationsquelleAutor der Antwort Johannes Rudolph
Ich bin der SCM-Techniker für einen einigermaßen großen Entwicklung, Organisation, und wir wandelten auf git-svn über das Letzte Jahr oder so. Wir verwenden es in einer zentralisierten Weise.
Verwenden wir gitosis host für die repositories. Wir brachen unsere monolithischen svn-repositories in viele kleinere git-repositories wie git - branching-Einheit ist im Grunde das repository. (Es gibt Möglichkeiten, um dieses, aber Sie sind umständlich.) Wenn Sie wollen pro-Zweig Arten von Zugriffskontrollen, gitolite möglicherweise ein besserer Ansatz. Es gibt auch ein inside-the-firewall-version von GitHub wenn Sie sich sorgen um das Geld. Für unsere Zwecke, gitosis ist in Ordnung, weil wir haben ein ziemlich offenes Berechtigungen auf unserer repositories. (Wir haben Gruppen von Menschen, die Schreibzugriff haben, um Gruppen von repositories, und jeder hat lesenden Zugriff auf alle Repositorys.) Wir verwenden gitweb für ein web-interface.
Als für einige Ihrer besonderen Anliegen:
Wechselten wir zu git, weil wir haben viele remote-Entwickler, und da hatten wir viele Probleme mit Subversion. Wir Experimentieren noch mit workflows, aber im moment nutzen wir es faktisch die gleiche Art, wie wir verwendet, um die Verwendung von Subversion ab. Eine andere Sache, die wir daran gefallen hat, war, dass es eröffnet andere mögliche workflows, wie der Einsatz von staging-repositories für code-review und Freigabe von code in kleinen Gruppen. Es ist auch ermutigt, eine Menge Leute zu starten die Verfolgung Ihrer persönlichen Skripte und so weiter, weil es so einfach zu erstellen eines Repositorys.
InformationsquelleAutor der Antwort ebneter
Tatsächlich, Linus argumentiert, dass zentralisierte Systeme, die einfach nicht arbeiten kann.
Und, was ist falsch mit der Diktator-und-lieutenants workflow?
Erinnern, git ist ein verteilt system; versuchen Sie nicht, verwenden Sie es wie eine zentrale.
(aktualisiert)
Meisten Ihrer Probleme werden verschwinden, wenn Sie nicht versuchen, zu nutzen git als wenn Sie "svn auf Steroiden" (weil es nicht).
Statt mit einem bare-repository als zentralen server, wo jeder drücken kann (und potenziell Schraube), setup-ein paar-integration-Manager, der Griff verschmilzt, so dass nur Sie können push-to-bare repository.
In der Regel diese Menschen sollte das team führt: jeder leader integriert seine eigenen team-Arbeit und schiebt es auf die Heilige repository.
Sogar noch besser, jemand anderen (z.B. Diktator) zieht aus dem Teamleiter und integriert Ihre änderungen in den seligen repository.
Wenn die Integratoren keine Zeit haben, code zu prüfen, ist das in Ordnung, aber Sie müssen noch zu haben, Leute zu integrieren, dass die Zusammenführungen von allen.
Tun git zieht nicht viel Zeit.
git hat Ersatz für menschliche Zeit und Aufmerksamkeit, das ist, warum es geschrieben wurde in den ersten Platz.
Gui-tools, kann mit den basic-Sachen ziemlich gut.
Erweiterte Funktionen erfordern einen coder/nerdy Einstellung (z.B. ich bin komfortables arbeiten von der Befehl Linie). Es dauert ein wenig Zeit zu begreifen, die Konzepte, aber es ist nicht so schwer.
Dies ist nicht ein problem, es sei denn, Sie haben viele unfähige Entwickler mit voller schreib-Zugriff auf die "central repository".
Aber, wenn Sie setzen Ihren workflow, so dass nur wenige Menschen (Integratoren) schreiben zu den "gesegneten" - repository, das wird nicht das problem sein.
Git macht es nicht einfach zu Schraube führt.
Wenn es merge-Konflikte, git wird deutlich zu Kennzeichnen das widersprüchliche Linien, so dass Sie wissen, welche änderungen die Ihre sind und welche nicht.
Es ist auch leicht zu verwischen, anderer Leute code mit svn oder andere (nicht-dsitributed) - tool. In der Tat, es ist viel leichter, mit diesen anderen tools, weil Sie neigen dazu, "sitzen auf Veränderungen" für eine lange Zeit und irgendwann verschmilzt bekommen kann furchtbar schwierig.
Und da diese Programme nicht wissen, wie Sie verschmelzen, Sie am Ende immer zu verschmelzen, die Dinge manuell. Zum Beispiel, sobald jemand macht einen commit für eine Datei, die Sie Bearbeiten lokal, es wird so markiert werden, dass ein Konflikt muss manuell gelöst; jetzt , dass ist ein Wartungs-Albtraum.
Mit git, die meisten der Zeit, wird es keine merge-Konflikte, weil der git tatsächlich zusammenzuführen. In dem Fall, wo ein Konflikt Auftritt, git, wird deutlich, markieren Sie die Zeilen, damit Sie wissen genau die änderungen werden Ihnen und die änderungen werden von anderen Menschen.
Wenn jemand vernichtet, die anderen Menschen die änderungen beim auflösen von merge-Konflikten nicht durch Fehler: es wird entweder weil es notwendig war, für die Konfliktlösung sind, oder weil Sie nicht wissen, was Sie tun.
Diese Probleme verschwinden, wenn Sie aufhören zu versuchen, zu verwenden git als ob es ein zentralisiertes system.
Urteil rufen.
Welche Art von Projekten haben Sie?
Zum Beispiel: ist x version.y-Projekt-Einer davon abhängen, genau w version.z Projekt B so, dass jedes mal Sie prüfen x.y-Projekt Sie auch haben, zur Kasse w.z von Projekt B, weil es sonst nicht bauen? Wenn ja, würde ich sowohl Projekt A und Projekt B in das gleiche repository, da Sie offensichtlich zwei Teile eines einzigen Projekts.
Die beste Praxis hier ist verwenden Sie Ihr Gehirn
Ich bin mir nicht sicher, was du meinst.
InformationsquelleAutor der Antwort hasen
Empfehle ich http://code.google.com/p/gerrit/ für Unternehmen arbeiten. Es gibt Ihnen Zugriff auf control plus einem eingebauten review-basierten workflow. Authentifizierung gegen beliebige LDAP-system. Sie können es Haken bis zu Hudson mit http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin, so dass Sie erstellen und testen Sie die änderungen, während Sie sich noch "under review", es ist eine wirklich eindrucksvolle Einrichtung.
Wenn Sie sich entscheiden, gerrit, empfehle ich versuchen zu halten, einen ziemlich linearen Verlauf, nicht eine verzweigte Geschichte, wie einige der open-source-Jungs mögen. Gerrit Phrasen diese als "allow fast-forward-ändert sich nur." Dann können Sie verwenden, verzweigen und Zusammenführen in mehr die Art und Weise, die Sie es gewohnt sind, für releases und so weiter.
InformationsquelleAutor der Antwort Russell Mull
Bin ich der Beantwortung dieser Frage basiert auf meiner Erfahrung als Entwickler und manager in einem großen Telekommunikationsunternehmen, wo wir angenommen Git in 2010
Du, die haben ganz andere Probleme hier:
Workflows
Wir erfolgreich angenommen ein zentrales repository-Modus: was haben wir in unserer enterprise-Projekt (ein großes portal für einen 5-Millionen-Nutzer-Basis) ist ein de-facto-central-repository erzeugt die offiziellen builds dann ergriffen werden, durch die Lieferung Prozess (der in unserem Fall aus drei-level-Tests und zwei-Bereitstellungen). Jeder Entwickler verwaltet seine eigenen repo, und wir arbeiten auf einem Zweig-pro-Funktion basis.
Client-tools
Gibt es nun mehrere Optionen zur Verfügung, das ist jetzt eine sehr überfüllten Bereich. Viele Entwickler sind erfolgreich mit IntelliJ Idea und Eclipse mit dem Git-plugin, ohne irgendwelche anderen Sachen. Auch die meisten Linux-Entwickler sind mit CLI git-client, ohne jedes problem. Einige Mac-Entwickler erfolgreich mit Git-Tower. Bitte beachten Sie, dass keiner dieser Kunden können verhindern, dass Benutzer zu "versauen" mit dem zentralen repository: server-side control mechamism benötigt wird
Server-Zugriffskontrolle und der integration
Wenn Sie möchten, um zu vermeiden Entwickler "verhunzen" Sie Git-repository, die Sie wirklich brauchen, eine Lösung zu wählen, dass:
Gibt es nicht so viele ready-to-use server-side-Lösungen, die helfen kann, ich schlage vor, Sie Auschecken einer von diesen:
Hoffe, das hilft!
InformationsquelleAutor der Antwort Bruno Bossola
Auf dem tools, MacOS-X-Anwender finden GitX (http://gitx.frim.nl/) sehr einfach und effektiv. Nachteil ist, dass keine Unterstützung für Git-Client hooks (die, die unter $GIT_ROOT/.git/hooks).
Insgesamt bin ich stark an, wählte ein Werkzeug, das unterstützt fine-grained access control auf:
- äste (um zu trennen die stabile release-Zweigen, die mit den strengen Sicherheits-aus dem Thema-Filialen, braucht mehr Beweglichkeit und Flexibilität)
- Identität der Vollstreckung (Autor /- committer). Dies ist der SCHLÜSSEL für SOX
- git-Befehle Beschränkungen
- audit-trail. Dies ist der SCHLÜSSEL für SOX
Diejenigen, die ich erfolgreich eingesetzt haben, mit diesen Eigenschaften sind:
P. S. nicht unterschätzen, SOX, CMMI compliance: oft gibt es begrenzte Reihe von Wahl, die Sie haben, ist diktiert durch Ihr Unternehmen Enterprise-Richtlinien auf Sicherheit.
Hoffe, das hilft.
Luca.
InformationsquelleAutor der Antwort lucamilanesio
Wir haben vor kurzem den Wechsel von svn zu git. Da git-daemon funktioniert nicht mit msysgit entschieden wir uns für einen zentralen repository-Ansatz, der auf einem Linux-server mit gitosis.
Zur Beseitigung der Möglichkeit zu vermasseln master wir einfach delted. Stattdessen bereiten wir alle releases durch die Zusammenlegung der Niederlassungen ausgewählt werden, für die Prüfung und tag der Zusammenführung. Wenn es die tests besteht, wird das commit tagged mit der version und in Betrieb genommen.
Um dies zu umgehen haben wir eine rotierende Rolle release-manager. Der release manager ist verantwortlich für die überprüfung jeden Zweig, bevor es bereit ist zum test. Dann, wenn der Produkt-Besitzer entscheidet, es ist Zeit zu bündeln, die genehmigt Zweige gemeinsam für eine neue test-Version der release-manager führen Sie den Seriendruck.
Haben wir auch eine rotierende Rolle der 2 ' ND-level-help-desk-und zumindest für uns-das Arbeitspensum ist, so dass es möglich ist, beide Rollen zur gleichen Zeit.
Als Vorteil, dass es nicht ein master ist es nicht möglich, beliebigen code auf dem Projekt-ohne den Umweg über die release-manager, so dass wir direkt entdeckt, wie viel code, dass war leise Hinzugefügt, um das Projekt vor.
Den review-Prozess beginnt mit der Niederlassung Eigentümer bezwingend das diff zu reviewboard und aufstellen ein grünes post-it auf dem whiteboard mit dem branch-Namen (wir haben eine Kanban-basierten workflow) unter "abgeben" ist, oder ob es Teil einer abgeschlossenen user story, verschieben Sie die ganze Geschichte Karte "abgeben" und das postit auf. Der Release manager ist der, der sich bewegt, Karten und post-its auf "ready for test" und dann product owner wählen können, welche zu incled in die nächste test-release.
Wenn dabei die Zusammenführung der release-manager stellt auch sicher, dass der merge-commit hat eine sinnvolle commit-Nachricht, die verwendet werden können im changelog für den product owner.
Wenn ein release gebracht worden ist, in der Produktion das tag verwendet wird als die neue Basis für Filialen und alle vorhandenen Niederlassungen sind mit Ihr verschmolzen ist. Auf diese Weise alle Zweige hat, die einem gemeinsamen übergeordneten Element, das macht es einfacher zu handhaben verschmilzt.
InformationsquelleAutor der Antwort John Nilsson
Es klingt wie Ihr problem ist, dass Sie noch nicht beschlossen bzw. eingeleitet, die einen workflow. Git ist flexibel genug, um es wie svn oder andere VCS, aber es ist so mächtig, dass wenn Sie nicht Regeln, die jeder befolgen muss, dann sind Sie nur gonna am Ende mit einem Durcheinander. Ich würde empfehlen, die Diktator-Leutnant workflow, dass jemand erwähnt, aber kombiniert mit dem branching-Modell beschrieben Vincent Driessen. Für mehr info sehen Sie diese screencasts von David Bock, und diese durch Mark Derricutt.
InformationsquelleAutor der Antwort Guillermo Garza
Werde ich hinzufügen, in einem "haben Sie als" post zu.
Einer der großen Dinge über Bazaar ist seine Flexibilität. Dies ist, wo es schlägt alle anderen verteilten Systemen. Sie können Sie bedienen Basar im zentralisierten Modus "verteilten Modus", oder dieses: beide (d.h. Entwickler können wählen, welches Modell Sie sind komfortabel mit, oder was funktioniert am besten für Ihre Arbeitsgruppe). Sie können die Verbindung auch trennen, ein zentralisiertes repository, während Sie auf der Straße und schließen Sie es, wenn Sie wieder zu bekommen.
Oben, die hervorragende Dokumentation, und etwas, was machen Sie Ihr Unternehmen happy: kommerzieller support verfügbar.
InformationsquelleAutor der Antwort wadesworld
InformationsquelleAutor der Antwort retronym
Bezüglich der Punkte 3 & 4 (pro Benutzer, pro Abschnitt, pro-branch-Berechtigungen), müssen Sie einen Blick auf gitolite (bedeckt das Pro Git-Buch: http://progit.org/book/ch4-8.html).
Politik oder nicht-Git ist so gut, eine Wahl des DCVS wie jede andere. Wie jedes mächtige Werkzeug, es lohnt sich, ein wenig Zeit im Vorfeld, um zu verstehen, wie das Werkzeug ist entworfen, um zu arbeiten, und zu diesem Zweck empfehle ich das Pro Git-Buch. Ein paar Stunden damit verbracht, mit ihm sparen Sie viel frustration auf lange Sicht.
InformationsquelleAutor der Antwort Jeet
GUI: In dem moment, TortoiseGit v1.7.6 sollte in Ordnung sein für die meisten täglichen arbeiten.
Log Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Stellungswechsel, Tag, Export, Stash, Submodul Hinzufügen, etc...
Unterstützt x64 nativ zu
InformationsquelleAutor der Antwort linquize
Um git verwenden, das effizient in ein Entwicklungs-team mit vielen Entwicklern, die ein CI-system, baut und testet ständig erforderlich ist. Jenkins bietet ein solches Fahrzeug und ich sehr empfehlen. Die integration Stück hat zu tun, egal was und es ist viel billiger zu tun, dass früher und häufiger auf.
InformationsquelleAutor der Antwort William Cheung
Mehr geeignet für collabrative Entwicklung als gitosis oder gitolite aber open-source ist Gitorious. Es ist eine Ruby on Rails Anwendung übernimmt die Verwaltung der repositories und Zusammenführen. Es sollte sich eine Lösung für viele Ihrer Probleme.
InformationsquelleAutor der Antwort Milliams
Git ermöglicht das erstellen von privaten äste. Dieser Entwickler dazu ermutigen, zu Begehen, so oft zu brechen, änderungen in kleinen verpflichtet. Wenn der Entwickler bereit ist, mit der Veröffentlichung seiner änderungen, schiebt er zum zentralen server. Er kann machen Verwendung von pre-commit scripts zu überprüfen, sein code, wenn nötig.
InformationsquelleAutor der Antwort linquize
NXP ist die Verwaltung von Git-und Subversion-mit einer gemeinsamen Plattform (enterprise-Skala), Integration von mobilen Android-Entwicklung mit traditionellen software-Projekte: http://www.youtube.com/watch?v=QX5wn0igv7Q
InformationsquelleAutor der Antwort Lothar Schubert