Ist es ratsam, Mitarbeiter zu bitten, GitHub-Konten für die Arbeit zu erstellen?

Ich habe alle Git-Repositorys unseres Unternehmens in GitHub verschoben und möchte nun Mitarbeiter zu den Projekten hinzufügen. Da die meisten Mitarbeiter bereits über persönliche GitHub-Konten verfügen, überlege ich, ob ich sie bitten soll, ein GitHub-Konto für die Arbeit zu erstellen . Der Grund, warum ich darüber nachdenke, besteht darin, die Wahrscheinlichkeit zu verringern, dass Unbefugte auf unsere Codebasis zugreifen, da ihre persönlichen Konten durch ihre persönlichen Aktivitäten auf der Website möglicherweise gut bekannt gemacht werden und die Wahrscheinlichkeit für gezielte Angriffe steigt. Darüber hinaus bedeutet eine Gefährdung des persönlichen Kontos nicht, dass der Hijacker auf den gesamten Buchungskreis zugreifen kann. Da dies die Belastung mit sich bringt, zwei Konten für die Mitarbeiter zu führen, frage ich mich, ob es der richtige Ansatz ist und ob es überhaupt Sinn macht.

Update Vielen Dank für alle nützlichen Erkenntnisse. Ich werde eine Antwort aufgrund der subjektiven Natur der Frage / der Antworten nicht als akzeptiert festlegen und da ich die besten Punkte aus mehreren unterschiedlichen Antworten gezogen habe.

Ich habe mich für diesen Weg entschieden: Ich möchte die Mitarbeiter daran erinnern, dass arbeitsbezogene GitHub-E-Mail-Benachrichtigungen aus praktischen Gründen an ihre geschäftlichen E-Mail-Konten gesendet werden müssen. Daher wäre es sinnvoller, GitHub-Accounts zu erstellen. Wenn sie bereit sind, ihre persönlichen GitHub-Konten zu verwenden und sie mit ihren geschäftlichen E-Mail-Konten zu verbinden, ist das in Ordnung. Auf jeden FallMitarbeiter müssen sich schriftlich mit einer Reihe von Bedingungen einverstanden erklären, die an die Nutzung von GitHub geknüpft sind. Dies hängt mit der Kontosicherheit zusammen: Wählen Sie ein sicheres Passwort mit einem sicheren Zufallspasswortgenerator, der nicht mit einem anderen Konto verwendet wird, greifen Sie nicht über Computer auf GitHub zu, die nicht Eigentum oder von ihnen verwaltet werden Entscheiden Sie selbst, ob ein Arbeitskonto für sie sinnvoller ist oder nicht.

Wenn es einen Nutzen gäbe, wäre es nur schmerzhaft. Aber nichts ist schlimmer als schmerzhaft und sinnlos. Habe nur den einzigen persönlichen Account. Zwei Gründe:

• Github verfügt in seinen Organisationen über eine unglaublich gute Zugriffskontrolle. Wenn ein Mitarbeiter das Unternehmen verlässt, können Sie seinen Zugriff sofort entfernen. Wenn sie ein Unternehmenskonto hätten, müssten Sie das Konto irgendwie zurückfordern, um die angegebenen Vorteile zu erhalten. In der Praxis würden Sie wahrscheinlich nur den Kontozugriff entfernen, so als ob sie ein persönliches Konto hätten.

• Mehr als ein Konto zu haben, ist schmerzhaft. Das Anmelden und Abmelden zwischen Konten schadet und das Hinzufügen von Kommentaren, Folgen und allen sozialen Dingen, wenn Sie verschiedene Konten verwenden.

Referenzen: Ich erstelle einen CI-Server mit GitHub-Integration , habe also eine Menge Testkonten und habe mit Kunden über alle möglichen seltsamen Konfigurationen gesprochen, einschließlich separater Arbeits- und persönlicher Konten. Es führt immer zu Ärger.

Befindet sich der Code Ihres Unternehmens in öffentlichen oder privaten Repositories? Wenn sie (oder zumindest einige) öffentlich sind und Sie Ihren Mitarbeitern erlaubt haben, ihre eigenen GitHub-Konten zu verwenden, wäre dies ein Anreiz für sie, guten Code zu schreiben. Ihr Name würde buchstäblich öffentlich damit verbunden sein. Ich gehe jedoch davon aus, dass alle Ihre Repositorys privat sind.

Insgesamt klingt es so, als würden Sie es vorziehen, wenn die Konten Ihrer Mitarbeiter in GitHub nicht öffentlich sichtbar sind. Leider verdienen sie Geld mit dem Verkauf von GitHub Enterprise, daher kann ich mir vorstellen, dass dies ein Grund ist, warum Sie keine privaten Konten für Organisationen erstellen dürfen. In beiden Fällen ( im Wesentlichen) Locked-Down Arbeit Konten wären wirklich kontraintuitiv nach einer sehr sozialen Seite der Auswahl Ihrer Repositories zu hosten.

Stellen wir uns vor, Sie haben Arbeitskonten für Ihre Mitarbeiter eingerichtet. Würden Sie die Verwendung dieser Konten einschränken? Würden Sie ihnen erlauben, Code für arbeitsfreie Projekte zu Arbeitszwecken beizutragen? In diesem Fall werden ihre Konten öffentlich sichtbar, und Sie kehren zu Ihrer anfänglichen Besorgnis zurück. Sie könnten ihnen einfach erlauben, die Beiträge mit ihren persönlichen Konten zu leisten, aber dann schaffen Sie einen logistischen Schmerzpunkt für sie. Persönlich würde ich meine Mitarbeiter ermutigen, Code für andere Projekte als sich selbst beizutragen. Dies gibt ihnen nicht nur einen Vertrauensschub, sondern ermöglicht ihnen auch, wertvolle Erfahrungen zu sammeln und ihre Glaubwürdigkeit zu stärken.

Ich glaube jedenfalls nicht, dass es die Mühe wert ist, Arbeitskonten zu haben. Über die GitHub-Oberfläche können Sie auf einfache Weise steuern, wer Zugriff auf was hat, sodass das Entfernen des Zugriffs in beiden Fällen einfach ist. Ich denke auch nicht, dass separate Accounts wirklich eine Grenze zwischen persönlichen und geschäftlichen Projekten ziehen, so wie es die GitHub-Oberfläche bereits tut.

Denken Sie auch daran, wie Sie damit umgehen wollen, wenn Ihr Unternehmen wächst. Sind die von Ihnen festgelegten Richtlinien nun in Bezug auf die Verwaltung skalierbar? Das Verwalten von 5 Konten im Moment mag in Ordnung sein, aber was passiert, wenn Sie 20 oder 50 werden? Wenn Sie an diesem Punkt angelangt sind, ist GitHub Enterprise möglicherweise eine ansprechbare Lösung. In diesem Fall würde ich überlegen, ob GitHub-Konten auf GitHub Enterprise-Installationen migriert werden können. Wenn ja, kann ich sehen, dass dies ein positiver Grund ist, Arbeitskonten zu haben.

Nicht ausgeschlossen, und eigentlich eine ziemlich gute Idee.

Wie bedauerlich es auch sein mag, Sie müssen planen, dass Ihre Mitarbeiter das Unternehmen zu einem bestimmten Zeitpunkt im Unternehmen verlassen. Wie werden Sie zu diesem Zeitpunkt ihre persönlichen Konten aus dem Repository des Unternehmens extrahieren?

Was machen Sie, wenn der Mitarbeiter schlecht abreist? In einer idealen Welt wird alles professionell bleiben und es wird keine Feindseligkeit zwischen der Firma und dem ehemaligen Mitarbeiter geben. Es ist ratsam, nicht ideale Umstände zu planen.

Die Führung von zwei Konten ist zwar mühsam, Ihre Mitarbeiter sollten die Gelegenheit jedoch begrüßen. Es bietet eine sauberere Grenze zwischen dem, was ihnen gehört und dem, was das Unternehmen ist.

Bearbeiten: An dieser Stelle geht es darum, eine klare Trennung zwischen den persönlichen Beiträgen des Mitarbeiters zu Projekten X, Y, Z usw. und seiner bezahlten Arbeit an Ihrem Unternehmensprodukt herzustellen. Die Verwendung eines separaten Arbeitskontos bietet die notwendige Abgrenzung, um festzustellen, wem welches geistige Eigentum und damit verbundene Urheberrechte gehören.

Wenn ein Mitarbeiter beispielsweise sein persönliches Konto verwendet und sowohl zum Unternehmen als auch zu Project X beiträgt, wie können Sie feststellen, in welcher Rolle der Mitarbeiter zu diesem Zeitpunkt war? War der Beitrag zu X im Namen Ihres Unternehmens oder nach eigenem Ermessen? Besitzt der Mitarbeiter oder das Unternehmen das Copyright für diese Arbeit, die X übertragen wurde? Wenn Sie externe Beiträge für die Arbeit Ihres Unternehmens zulassen, wie unterscheiden Sie dann, ob der Mitarbeiter ein Mitarbeiter oder ein freiwilliger Beitrag war?

Nehmen wir im weiteren Sinne an, Sie haben einen Mitarbeiter, der durch Beiträge zu anderen Projekten einen Ruf aufbaut, der im Namen des Unternehmens handelt. Wie geben Sie an, dass das persönliche Benutzerkonto nicht mehr mit Ihrer Firma verknüpft ist, wenn dieser Mitarbeiter das Unternehmen verlässt? Schwerwiegende Markenprobleme können auftreten, ohne dass klar definiert ist, wofür ein bestimmtes Konto gedacht ist.

Es ist ziemlich einfach, eine Spur von Eigentums-, Marken- und Urheberrechtsbedenken aufzulösen, wenn Sie anfangen, über die möglichen Szenarien nachzudenken. Durch die Verwendung separater Arbeitskonten wird ein Teil dieser Mehrdeutigkeit beseitigt. Das Unternehmen muss in der Lage sein, Ansprüche auf im Namen des Unternehmens geleistete Beiträge geltend zu machen.

Es geht nicht um die technischen Aspekte der Trennung des Benutzerkontos, sondern um die rechtlichen Fragen, die Sie stören können.

Beachten Sie, dass dies ein strittiger Punkt sein kann, wenn alle Produkte Ihres Unternehmens als Open Source unter genehmigten Lizenzen veröffentlicht werden und / oder Sie sich keine Gedanken über potenzielle Branding-Probleme machen.
(Hutspitze an Paul Biggar für die Anforderung dieser Änderung)

Da sich offenbar alle darin einig sind, dass der Arbeitgeber nicht beide trennen muss, habe ich nach kurzer Erfahrung versucht, mein persönliches Konto für berufliche Projekte und Open-Source-Beiträge im Zusammenhang mit der Arbeit zu verwenden.

Nur um den Kontext zu vervollständigen: Ich wurde nicht nach Accounts gefragt, tatsächlich ist GitHub den meisten Leuten an meinem Arbeitsplatz unbekannt. Ich war einfach in der Lage, grünes Licht für das Open Source-Projekt zu bekommen, an dem ich arbeiten werde, und ging mit dem geringsten Arbeitsaufwand, dh mit meinem persönlichen Konto, um.

Aus Sicht eines Mitarbeiters hasse ich eines wirklich: Benachrichtigungen in meiner persönlichen E-Mail für berufliche Angelegenheiten.

Aufgrund dieser Beobachtung wurde mir klar, dass dies ein offensichtlicher Bruch der beruflichen / persönlichen Schranke ist: Wenn ich in meiner Freizeit zu einem Projekt beitragen möchte, erhalte ich dennoch alle Aktualisierungen meiner Arbeitsprojekte… Und dies kann Verwirrung bei externen Mitarbeitern stiften , der Sie kontaktieren könnte, ohne zu wissen, dass Sie von diesem Projekt ausgeschlossen sind.

Dann ist natürlich eine Balance zu finden mit der Tatsache, dass Ihr persönlicher Ruf von Ihren Arbeitsbeiträgen profitieren kann. Andererseits könnte es umgekehrt sein, wenn Ihr Name mit einem schlechten Projekt in Verbindung gebracht wird…

Letztendlich, da die Frage aus Sicht des Arbeitgebers und unter Berücksichtigung aller anderen Antworten gestellt wird: Ich würde sagen, es macht wahrscheinlich nicht viel Sinn, die Verwendung von arbeitsspezifischen Konten durchzusetzen . Aber Sie sollten es nicht verbieten, damit Mitarbeiter, die es vorziehen, die persönliche Barriere zu erhöhen, dies tun und vielleicht auf diese Risiken hinweisen ...?

Als Randbemerkung, was die Sicherheit betrifft, da es in anderen Antworten eine leichte Entlassung zu geben scheint:

Natürlich wäre ein "Arbeits" -Konto nicht mehr oder weniger sicher als ein "persönliches" Konto in Bezug auf Passwörter. Wenn Sie jedoch GitHub verwenden, dürfen Sie mit einem SSH-Schlüssel pushen. Und dieser Schlüssel liegt normalerweise in einer Sitzung… Das persönliche Konto kann also alle Arbeitsspeicher mit einem einfachen PC-Diebstahl (ohne Kennwortkenntnisse) gefährden, wohingegen ein dedizierter Arbeitskonto seinen Schlüssel wahrscheinlich nur auf der Arbeitsmaschine haben würde, wodurch er erstellt wird physisch sicherer (hoffentlich).

Ich würde mit "Nein" stimmen. Es ist ein ziemlicher Aufwand für Ihre Entwickler und gibt Ihnen Sicherheit durch Unklarheit: Wenn jemand aktiv auf Ihre Entwickler zielt, gibt es viele andere Angriffsmethoden, mit denen jemand Ihren Code abrufen kann.

Außerdem wäre es für ein Startup-Unternehmen peinlich, schrecklich und widerlich, wenn es nicht viele magische Geheim-Soße-Algorithmen im Spiel hätte, jemanden zu finden, der seinen Code erhält, der jedoch keinen erheblichen Wettbewerbsvorteil erzielen sollte (wer könnte Ihren rechtmäßig nutzen?) Code?) oder dazu führen, dass Sie Ihr Geschäft aufgeben.

Eine so niedrige Auftragswahrscheinlichkeit im Vergleich zur Entwicklerproduktivität? Ich würde Entwicklerproduktivität nehmen, aber das ist mein Kalkül. :)

Ich würde sagen, das sollte dem Mitarbeiter überlassen bleiben. Eine Sache, die ich sagen würde, ist, sie nicht zu zwingen, ihren persönlichen Github-Account zu benutzen, wenn sie nicht wollen. Ich war in einer Firma, die GitHub verwendete, und obwohl dies keine Voraussetzung war, wollte ich persönlich ein separates Konto erstellen. Der Hauptgrund war, meine persönlichen Projekte zu schützen. Ich wollte nicht, dass die Firma versucht, zu sagen, eines meiner persönlichen Projekte gehöre ihnen, weil es unter demselben Github-Konto lag, das für ihre Unternehmensprojekte verwendet wurde (ich bin mir nicht sicher, ob das jemals vor Gericht Bestand haben würde, aber ich habe nicht viel Vertrauen in der Rechtsordnung, wenn es um solche Dinge geht). Ich denke, dass eine saubere Trennung eine gute Sache sein kann.

Wir machen das in unserer Firma. Ich möchte keine Diskussion darüber beginnen, "was sicherer ist, Github oder ein Server unter Ihrem Tisch, auf den jeder Root-Zugriff hat, nicht sicher, ob das Backup funktioniert usw.". Unser Ansatz war:

• Jeder Entwickler muss ein neues Konto erstellen, das nichts mit seinem persönlichen Github-Konto zu tun hat
• Es sollte die Firmen-E-Mail verwenden.
• Es sollte unseren Sicherheitsregeln entsprechen (Login-Name und Passwort erforderlich).
• Sie können keine öffentliche Aktivität zeigen / haben.
• Es ist Firmeneigentum. Nicht sein / ihr Konto.
• Alle Konten sind mit einer Firma verbunden, auch mit einem zufälligen Namen. Keine öffentliche Aktivität.

Ich erkenne, dass diese Fragen und Antworten ein paar Jahre alt sind. Vielleicht war sie vorher nicht verfügbar, aber in den Unterschieden zwischen Benutzer- und Organisationskonten heißt es ausdrücklich :

Es kann verlockend sein, mehr als ein Benutzerkonto zu haben, beispielsweise für den persönlichen und geschäftlichen Gebrauch, aber Sie benötigen nur ein Konto.

GitHub hat gute Tools zum Aktivieren / Deaktivieren von Benachrichtigungen durch das Repository und mehr noch, es scheint, dass das Kombinieren von Personal / Work am sinnvollsten ist.

Die Menschen müssen den Cloud-basierten Quellservern noch vertrauen. In Github sind viele New-Age-Webfirmen registriert, aber in Wirklichkeit haben die meisten Leute ihre eigenen Server, um den Quellcode zu pflegen. Nach meiner Erfahrung verwenden die meisten von ihnen entweder Clear-Case oder SVN. Git ist noch in einer Unternehmensumgebung anzupassen. Sogar die Mailserver des Unternehmens werden außerhalb des Unternehmensgeländes nicht wirklich geschätzt.