Должен ли я создавать отдельные рабочие и личные учетные записи GitHub? [закрыто]

Закрыто. Этот вопрос не по теме . В настоящее время не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он соответствовал теме разработки программного обеспечения в стеке.

Закрыто 5 лет назад .

Я довольно новичок в программировании, и я работал над многими личными проектами, которые, как мне кажется, могут показаться глупыми и непрофессиональными. Мои проекты - это Reddit Image Downloader и инструмент для гроссмейстеров, который можно использовать в ролевых играх.

Я хочу начать создавать учетную запись GitHub для проектов в выбранной мной области анализа данных , но я не уверен, как организовать проекты в моей учетной записи GitHub. Должен ли я создать «профессиональный» GitHub, в основном содержащий различные аналитические скрипты и иметь отдельную «личную» учетную запись для моих забавных маленьких проектов? Или я просто обдумываю это и должен ли я поддерживать один аккаунт?

github

— Почти наверняка
источник

Лично у меня есть только одна учетная запись для профессиональных и личных проектов. Пока в вашем аккаунте нет ничего оскорбительного, я не вижу причин использовать один и тот же для обеих целей. Во всяком случае, это просто показывает, что вам нравится выполнять работу, и вы не ограничиваете себя каким-то конкретным видом приложения.

— Дилан Рибб

Это на самом деле не относится к этому вопросу, поскольку требует совета по вопросам карьеры, но я могу сказать, что, когда я брал интервью, личные проекты - это активы для кандидатов, какими бы глупыми они ни были. (Предполагая, что мы не говорим о пердящем приложении или о чем-то подобном.) Упомянутые вами проекты определенно будут тем, о чем я бы хотел упомянуть

— Gort the Robot

удалил разделы с советами по карьере и сделал больше о github (включая переключение тегов).

— Майкл Даррант

@AlmostSurely: у вас есть разрешение на фактическую работу на github? Ваш работодатель может быть не очень доволен этим, даже если вы делаете эти проекты частными.

— Марьян Венема

Размещение любого кода от вашего работодателя на GitHub без их согласия - даже в частном проекте - может считаться кражей. Я знаю, что если я размещу код своего работодателя на GitHub без их явного согласия, у меня будут серьезные проблемы. И я не подписал NDA. То же самое, если вы работаете не по найму и поместили код, который вы создали для клиента, на GitHub. Код не ваш, чтобы положить туда.

— Марьян Венема

Ответы:

Я говорю, что вы можете съесть торт, у него тоже есть! Представляем GitHub Организации .

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

Выгоды:

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

По сути, этот подход дает вам преимущества обоих подходов. Единственным недостатком является то, что если у вас есть какие-то личные проекты, которые вы никому не можете связать с вашим профессиональным публичным лицом. Тем не менее, эти критерии обычно включают в себя нелегальные вещи, которые вы не хотели бы помещать на GitHub, поэтому это не должно быть проблемой.

— Идан Арье
источник

Я рекомендую вам держать их вместе.

показ подходящих личных проектов часто является большим плюсом, поскольку он показывает вашу страсть и инициативу
Проще управлять тем, что идет куда со временем.
только 1 набор ключей SSH для управления
нет необходимости входить / выходить из одного в другой.
позволяет вам иметь от 1 GitHub до 1 основной личной электронной почты, также проще.

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

— Майкл Даррант
источник

показ личных проектов часто является большим плюсом - возможно, таким же большим минусом, когда кто-то другой крадет вашу идею ... вы можете говорить о других вещах, которые вы делаете с коллегами и начальством (не тратя много времени на сделайте так), даже если они не в github - это показывает страсть и инициативу, не давая другим "ключи от замка". Это то, что я всегда делал, и это помогало мне в моей работе - не раз мне давали интересные задания: «Эй, я слышал, что вы много дурачились с JSON ... возможно, вы можете заняться этим новым проектом, который мы» повторное планирование ... "и т.д ...

— Вектор

и многие работодатели не хотят риска перекрестного заражения между их корпоративной собственностью и некоторыми проектами хобби ...

— jwenting

Если вы не можете разделить проекты, не имеет значения, являются ли они частными или общедоступными. Я никогда не видел такого "перекрестного загрязнения" на практике. В своей работе сейчас я должен использовать 20 репозиториев, а не перепутывать их.

— Майкл Даррант

Вектор - вот почему я говорю использовать частные репо для таких проектов.

— Майкл Даррант

Даже если вы размещаете работу в частных проектах, работодатель может быть не совсем доволен тем, что его код «открыт» (не контролируется их собственной политикой безопасности) и демонстрируется другим компаниям во время интервью. Даже размещение на GitHub в частном проекте можно считать воровством. Я знаю, что если я размещу код своего работодателя на GitHub без их явного согласия, у меня будут серьезные проблемы. И я не подписал NDA.

— Марьян Венема

Я думаю, что вы должны держать счета отдельно.

Практически во всех случаях работа, которую вы создаете в связи с работой в компании, принадлежит компании. Это не ваша собственность. Когда вы покидаете компанию, компания сохраняет всю эту работу, и у вас больше нет на нее никаких прав.

Если вы держите свой личный и рабочий аккаунты отдельно, это значительно упрощает эту задачу. Когда вы уходите, вы просто передаете рабочий аккаунт, и они вступают во владение. Вам не нужно будет отделять свои проекты от проектов компании и не нужно пытаться удалять проекты из своей учетной записи. Работа в любой компании мимолетна, и чем больше вы связываете свои личные вещи с корпоративными, тем сложнее становится, когда вы расстаетесь.

Это мое практическое правило, и, конечно, отдельные организации будут иметь свое мнение по этому поводу. Я видел, как некоторые компании решали, что у них нет проблем с тем, чтобы вы хранили копию этого материала после того, как вы покинете компанию, если у них тоже есть копия. С другой стороны, компания, в которой я работаю, держит очень жесткий контроль над вещами, и они, вероятно, уволят меня, если я положу рабочий продукт компании на github.

— Алан Шутко
источник

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

— почти наверняка

@AlmostSurely - +1 на этот ответ - я думаю, что синица - правильный. Хранение ваших личных вопросов, будь то технических или иных, всегда является наилучшей политикой по причинам, указанным здесь и многим другим. Вы можете поместить свои частные проекты в свое резюме, и даже ссылку на свой частный репозиторий GitHub, чтобы показать, что вы были до. Если вам действительно нужно перейти на другую работу, делать что-то самостоятельно вне работы, чтобы расширить свой кругозор и освоить новые навыки, может (но не всегда ...) быть плюсом: это показывает, что вы любите свою работу, вы амбициозный и энергичный и т. д.

— Вектор

также избегает / уменьшает реальную угрозу того, что они думают, что похожий код в ваших личных проектах украден с работы, которую вы для них сделали. Многие работодатели требуют владения всем кодом, который вы пишете во время работы, даже кодом, который вы пишете в свободное время, не связанным с работой. Я не могу сказать, будет ли такая претензия подана в суд (и все равно это будет зависеть от местных законов), но это обычное дело, и вы хотите избежать подобных осложнений, если в итоге вы столкнетесь с каким-либо трудовым спором.

— января

даже код, который вы пишете в свободное время, это не связано с работой - Ага. Я подписал соглашение о неразглашении, которое фактически дало им право владеть моим серым веществом программирования. Будут ли такие претензии иметь силу в суде, я не могу сказать - я не думаю, что они будут поддерживаться в суде США, поэтому я никогда не беспокоился об этом слишком сильно - но они поместили его там, чтобы вы не «получить мило» - фактор устрашения.

— Вектор

Проекты компании должны храниться в отдельной организации. тогда легко увидеть, какие проекты ваши, а какие - компании. когда вы уходите, вам не нужно передавать свою учетную запись, поскольку вы можете просто предоставить доступ к организации кому-то еще в компании.

— eMBee