Чи варто створювати окремі робочі та особисті облікові записи GitHub? [зачинено]


28

Я досить новачок у програмуванні, і працюю над багатьма особистими проектами, які мене турбують, можуть наштовхнутися на дурні та непрофесійні. Проекти, які у мене є, є Reddit Image Downloader та інструмент для використання в GM в рольових іграх.

Я хочу розпочати створення облікового запису GitHub для проектів у вибраній галузі аналізу даних , але я не впевнений, як організувати проекти на моєму акаунті GitHub. Чи варто мені створити "професійний" GitHub, що містить в основному різні аналітичні сценарії та мати окремий "особистий" акаунт для маленьких цікавих проектів? Або я просто переосмислюю це, і я повинен просто підтримувати один обліковий запис?


4
Особисто я просто маю один рахунок як для професійних, так і для особистих проектів. Поки у вашому обліковому записі немає нічого образливого, я не бачу причин використовувати те саме для обох цілей. Якщо що-небудь, це просто показує, що вам подобається виконувати роботу, і ви не обмежуєте себе певним видом додатків.
Ділан Рібб

3
Це насправді не належить до цього, оскільки він просить проконсультуватися у кар’єрі, але можу сказати, що коли я брав інтерв'ю, особисті проекти є активом для кандидатів, незалежно від того, наскільки "дурним". (Якщо припустити, що ми не говоримо про додаток про пердеть або щось подібне.) Проекти, про які ви згадуєте, безумовно, будуть чимось, що я вважаю вартим згадати.
Gort the Robot

вилучив розділи з профорієнтації та детальніше розповів про github (включаючи вимикання тегів).
Майкл Дюрант

1
@AlmostSurely: у вас є дозвіл на те, щоб розмістити фактичну роботу на github? Ваш роботодавець може бути не надто задоволений цим, навіть якщо ви зробите ці проекти приватними.
Мар'ян Венема

1
Розміщення будь-якого коду вашого роботодавця на GitHub без їх згоди - навіть у приватному проекті - може вважатися крадіжкою. Я знаю, що якби я поставив своїм роботодавцям код на GitHub без їхньої прямої згоди, я би зазнав серйозних проблем. І я не підписав NDA. Те саме, якщо ви самозайняті і розміщуєте код, створений для клієнта, на GitHub. Код не ваш.
Мар'ян Венема

Відповіді:


25

Я кажу, що ви можете з'їсти торт у нього теж! Представляємо організації GitHub .

Використовуйте свій обліковий запис GitHub для своїх особистих проектів та створіть організацію для своїх професійних проектів. На домашній сторінці організації будуть показані професійні проекти, які ви хочете представити, і на ній буде посилання на ваш особистий обліковий запис, де відображаються всі речі, які ви зробили в GitHub.

Переваги:

  • У вас буде чиста розлука, яку ви хотіли, зберігаючи зв’язок між вашою особистою та професійною діяльністю GitHub.
  • Ви зможете контролювати все з одного облікового запису. Не потрібно перероблятись, щоб відкрити сховище в професійному обліковому записі - все, що вам потрібно зробити, це вибрати організацію, коли ви відкриєте новий сховище.
  • Не потрібно керувати двома різними ключами SSH на одному комп’ютері!
  • Ви можете додати інших користувачів GitHub до своєї організації та навіть передати право власності на організацію, якщо вам навіть потрібно. У кожного користувача буде свій власний обліковий запис, тому вам не потрібно ділитися паролем професійного облікового запису з іншими людьми. Як бонус, різні облікові записи можуть мати різні дозволи, виходячи зі своєї фактичної ролі в команді - те, що ви не могли зробити зі спільним обліковим записом GitHub для професійних проектів.

В основному такий підхід дає переваги обом підходам. Єдиним недоліком є ​​те, якщо у вас є якісь особисті проекти, які ви ні в кого ніколи не пов'язуєте з вашим професійним суспільним обличчям. Однак, ці критерії, як правило, стосуються незаконних речей, які ви б не хотіли ставити в першу чергу на GitHub, тому це не повинно бути проблемою.


18

Я рекомендую вам тримати їх разом.

  • показ відповідних особистих проектів часто є великим плюсом, оскільки він показує вашу пристрасть та ініціативу
  • простіше керувати тим, що йде куди з часом.
  • лише 1 набір клавіш ssh для управління
  • не потрібно входити / виходити з одного в інший.
  • дозволяє мати 1 github до 1 основної особистої електронної пошти, також простіше.

Я думаю, що одна відповідь на те, що ви хочете (і що я роблю), - це мати платний рахунок (я думаю, що його 7 доларів на місяць для 5 приватних осіб), що дозволяє отримати більше приватних сховищ. Тож зберігайте ті, які ви хочете, щоб вони були загальнодоступними, а інші - як приватні.


показ особистих проектів часто є великим плюсом - можливо так само часто, як і великий мінус, коли хтось інший вкраде вашу ідею ... ви можете поговорити про інші речі, які ви робите з колегами та начальством (не забираючи багато часу, щоб зробити це), навіть якщо вони не в Github - це виявляє пристрасть та ініціативність, не даючи іншим "ключі від замку". Це те, що я завжди робив, і це допомагало мені в моїй роботі - не раз мені давали цікаві завдання: "Ей, я чув, що ти багато дуриш з JSON ... можливо, ти можеш вирішити цей новий проект ми" перепланування ... "тощо ...
Вектор

2
і багато роботодавців не захочуть ризику перехресного забруднення між корпоративною власністю та деякими хобі-проектами ...
jwenting

1
Якщо ви не можете тримати окремі проекти, не має значення, приватні вони чи державні. Я ніколи не бачив цього «перехресного зараження» на практиці. Зараз у своїй роботі я повинен використовувати 20 сховищ, а не змішувати їх.
Майкл Дюрант

Вектор - ось чому я кажу, використовуйте приватні репости для таких проектів.
Майкл Дюрант

1
Навіть якщо ви працюєте в приватних проектах, роботодавець може не бути задоволений тим, що він вважає своїм кодом «на відкритому повітрі» (не контролюється їх власною політикою безпеки) і показує його іншим компаніям під час співбесіди. Навіть розміщення його на GitHub в приватному проекті може вважатися крадіжкою. Я знаю, що якби я поставив своїм роботодавцям код на GitHub без їхньої прямої згоди, я би зазнав серйозних проблем. І я не підписав NDA.
Мар'ян Венема

10

Я думаю, вам слід тримати окремі рахунки.

Практично у всіх випадках робота, яку ви створюєте у зв'язку зі своїм працевлаштуванням у компанії, належить компанії. Це не ваша власність. Коли ви виходите з компанії, компанія зберігає все, що працює, і ви більше не маєте на це жодних прав.

Якщо ви зберігаєте свої особисті та робочі рахунки окремо, це значно спрощує. Коли ви виходите, ви просто здаєте робочий рахунок і вони приймають право власності. Вам не потрібно буде відокремлювати свої проекти від проектів компанії, і не потрібно буде намагатися видалити проекти зі свого облікового запису. Зайнятість у будь-якій компанії швидкоплинна, і чим більше ви заплутуєте свої особисті речі, тим складніше, коли ви розлучаєтесь.

Це моє правило, і, безумовно, окремі організації матимуть свою думку з цього приводу. Я міг бачити, як деякі компанії вирішують, що вони не мають жодних проблем з вами зберігати копію цього матеріалу, як тільки ви покинете компанію, якщо вони теж мають їх копію. З іншого боку, компанія, в якій я працюю, тримає дуже жорсткий контроль над речами, і вони, швидше за все, звільнять мене, якщо я поставлю робочий продукт компанії на github.


Я працюю над окремою некомерційною організацією, яка є частиною більшого Фонду. Я розмовляв з моїми вищими версіями, і вони прекрасно зі мною розміщували файли з відкритим кодом на моєму github, щоб я міг поділитися нашим прогресом з рештою Фонду, і це, здається, є методом для інших організацій у Фонд. Я розумію, що ви говорите про те, що компанія - це компанія, але, якщо чесно, я хотів би подякувати цій роботі за своє резюме. Попри це, можливо, я повинен вести окремий робочий рахунок і просто мати проекти у своєму резюме, не посилаючись на github.
Майже точно

1
@AlmostSurely - +1 на цю відповідь - я думаю, що синиця правильна. Збереження Ваших приватних справ, будь то технічних чи інших, завжди є найкращою політикою з причин, зазначених тут та багатьох інших. Ви можете розміщувати свої приватні проекти у своєму резюме незалежно і навіть посилатися на своє приватне сховище github, щоб показати, що ви хотіли. Якщо вам потрібно перейти на іншу роботу, займатися самостійно поза роботою, щоб розширити свій кругозір та навчитися новим навичкам може бути (але не завжди ...) плюсом: це показує, що ви любите свою роботу, ви амбітні та енергійні тощо
Вектор

2
також уникає / зменшує дуже реальну загрозу, коли вони думають, що подібний кодовий код у ваших особистих проектах викрадений з роботи, яку ви зробили для них. Багато роботодавців вимагають право власності на весь код, який ви пишете під час роботи, навіть код, який ви пишете у вільний час, це не пов'язано з роботою. Чи буде така позов затримана в суді, я не можу сказати (і все одно залежатиме від місцевих законів), але це звичайна річ, і ви хочете уникнути подібних ускладнень, якщо ви опинитесь в будь-якому трудовому спорі.
14:12

навіть код, який ви пишете у вільний час, це не пов'язано з роботою - Yup. Я підписав NDA, які по суті дали їм право власності на мою програмну сіру речовину. Чи буде така позов затримана в суді, я не можу сказати - я не думаю, що вони затримаються в суді США, тому я ніколи надто не хвилювався з цього приводу - але вони подали її туди, щоб ви не "отримати мило" - фактор залякування.
Вектор

1
Проекти компанії повинні утримуватися в окремій організації. тоді легко зрозуміти, які проекти є твоїми, а які - компанією. коли ви виходите, не потрібно здавати свій рахунок, оскільки ви можете просто надати доступ до організації іншому в компанії.
eMBee
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.