¿Debo crear cuentas de trabajo y personales de GitHub separadas? [cerrado]

Soy bastante nuevo en programación, y he estado trabajando en muchos proyectos personales, lo que me preocupa puede parecer tonto y poco profesional. El tipo de proyectos que tengo son Reddit Image Downloader y una herramienta para que los GM los usen en juegos de rol.

Quiero comenzar a construir una cuenta de GitHub para proyectos en mi campo de análisis de datos elegido , pero no estoy seguro de cómo organizar proyectos en mi cuenta de GitHub. ¿Debería crear un GitHub "profesional", que contenga principalmente diferentes scripts analíticos y tener una cuenta "personal" separada para pequeños proyectos míos divertidos? ¿O simplemente estoy pensando demasiado en esto y debo mantener una sola cuenta?

github

— Casi seguro
fuente

Personalmente, solo tengo una cuenta para proyectos profesionales y personales. Mientras no haya nada ofensivo en su cuenta, no veo ninguna razón para usar la misma para ambos propósitos. En todo caso, solo muestra que te gusta hacer el trabajo y no te estás limitando a un tipo específico de aplicación.

— Dylan Ribb

Esto realmente no pertenece aquí, ya que está pidiendo asesoramiento profesional, pero puedo decir que cuando he entrevistado, los proyectos personales son activos para los candidatos, no importa cuán "tontos" sean. (Suponiendo que no estamos hablando de una aplicación de pedo o algo así). Los proyectos que mencionas definitivamente serían algo que consideraría digno de mencionar.

— Gort the Robot

eliminó las secciones de consejos de carrera y lo hizo más sobre github (incluido el cambio de etiquetas).

— Michael Durrant

@AlmostSurely: ¿tiene permiso para poner trabajo real en github? Es posible que su empleador no esté muy contento con esto, incluso si hace que esos proyectos sean privados.

— Marjan Venema

Poner cualquier código de su empleador en GitHub sin su consentimiento, incluso en un proyecto privado, podría considerarse un robo. Sé que si pongo el código de mi empleador en GitHub sin su consentimiento expreso, estaría en serios problemas. Y no he firmado un NDA. Lo mismo si trabaja por cuenta propia y coloca el código que creó para un cliente en GitHub. El código no es tuyo para ponerlo allí.

— Marjan Venema

Respuestas:

¡Yo digo que también puedes comer el pastel! Presentación de las organizaciones de GitHub .

Use su cuenta de GitHub para sus proyectos personales y cree una organización para sus proyectos profesionales. La página de inicio de la organización mostrará los proyectos profesionales que desea presentar, y tendrá un enlace a su cuenta personal que muestra todas las cosas que ha hecho en GitHub.

Beneficios:

Tendrá la separación limpia que desea mientras mantiene una relación entre su actividad personal y profesional de GitHub.
Podrás controlar todo desde una sola cuenta. No es necesario volver a iniciar sesión solo para abrir un repositorio en la cuenta profesional; todo lo que tiene que hacer es seleccionar la organización cuando abra un nuevo repositorio.
¡No es necesario administrar dos claves SSH diferentes en la misma computadora!
Puede agregar otros usuarios de GitHub a su organización e incluso transferirles la propiedad de la organización si es necesario. Cada usuario tendrá su propia cuenta, por lo que no necesita compartir la contraseña de una cuenta profesional con otras personas. Como beneficio adicional, diferentes cuentas pueden tener diferentes permisos en función de su rol real en el equipo, algo que no podría hacer con una cuenta compartida de GitHub para proyectos profesionales.

Básicamente, este enfoque le brinda los beneficios de ambos enfoques. El único inconveniente es si tiene algunos proyectos personales que no tiene a nadie que los relacione con su cara pública profesional. Sin embargo, estos criterios generalmente involucran cosas ilegales que no querría poner en GitHub en primer lugar, por lo que no debería ser un problema.

— Idan Arye
fuente

Te recomiendo que los mantengas juntos.

mostrar proyectos personales adecuados es a menudo una gran ventaja, ya que muestra su pasión e iniciativa
más simple de administrar lo que pasa con el tiempo.
solo 1 conjunto de claves ssh para administrar
no es necesario iniciar / cerrar sesión de uno a otro.
le permite tener 1 github a 1 correo electrónico personal principal, también más simple.

Creo que una respuesta a lo que quieres (y a lo que hago) es tener una cuenta paga (creo que cuesta $ 7 al mes por 5 privados) que permite más repositorios privados. Por lo tanto, mantenga los trabajos / juegos que desea que sean públicos como públicos y mantenga los demás como privados.

— Michael Durrant
fuente

mostrar proyectos personales es a menudo una gran ventaja , tal vez con la misma frecuencia, una gran desventaja, cuando alguien más roba tu idea ... puedes hablar sobre otras cosas que estás haciendo con compañeros de trabajo y superiores (sin tomar mucho tiempo para hacerlo), a pesar de que no están en Github, eso muestra pasión e iniciativa sin dar a los demás las "llaves del castillo". Eso es lo que siempre he hecho y me ha ayudado en mi trabajo: más de una vez me han asignado tareas interesantes: "Oye, escuché que estabas jugando mucho con JSON ... tal vez puedas abordar este nuevo proyecto" re planificación ... "etc ...

— Vector

y muchos empleadores no querrán el riesgo de contaminación cruzada entre su propiedad corporativa y algunos proyectos de pasatiempo ...

— comenzando

Si no puede mantener los proyectos separados, no importa si son privados o públicos. Nunca he visto esta "contaminación cruzada" en la práctica. En mi trabajo en este momento tengo que usar 20 repositorios y no mezclarlos.

— Michael Durrant

Vector - por eso digo que use repositorios privados para tales proyectos.

— Michael Durrant

Incluso si pone trabajo en proyectos privados, el empleador puede no estar exactamente contento con tener lo que considera su código "abierto" (no controlado por sus propias políticas de seguridad) y mostrárselo a otras compañías durante las entrevistas. Incluso ponerlo en GitHub en un proyecto privado podría considerarse un robo. Sé que si pongo el código de mi empleador en GitHub sin su consentimiento expreso, estaría en serios problemas. Y no he firmado un NDA.

— Marjan Venema

Creo que deberías mantener las cuentas separadas.

En casi todos los casos, el trabajo que crea como resultado de su empleo en una empresa es propiedad de la empresa. No es de su propiedad. Cuando abandonas la empresa, la empresa conserva todo ese trabajo y ya no tienes ningún derecho.

Si mantiene sus cuentas personales y laborales separadas, esto lo hace mucho más fácil. Cuando te vas, simplemente entregas la cuenta de trabajo y ellos se apropian. No necesitaría separar sus proyectos de los proyectos de la compañía, y no necesitaría intentar eliminar los proyectos de su cuenta. El empleo en cualquier empresa es efímero, y cuanto más enredes tus cosas personales con las cosas de la empresa, es más difícil cuando te separas.

Esta es mi regla general, y ciertamente las organizaciones individuales tendrán su propia opinión al respecto. Pude ver que algunas compañías deciden que no tienen ningún problema con que guardes una copia de estas cosas una vez que dejas la compañía, siempre y cuando tengan una copia también. Por otro lado, la compañía en la que trabajo mantiene un control muy estricto sobre las cosas y probablemente me despedirán si pongo el producto de trabajo de la compañía en github.

— Alan Shutko
fuente

Trabajo para una organización sin fines de lucro que forma parte de una Fundación más grande. He hablado con mis superiores, y estuvieron bien conmigo hospedando los archivos de código abierto en mi github, para poder compartir nuestro progreso con el resto de la Fundación, y este parece ser el método para otras organizaciones en la Fundación. Entiendo lo que está diciendo acerca de lo que es la compañía, pero para ser honesto, me gustaría dar crédito por este trabajo en mi currículum. Dicho esto, tal vez debería mantener una cuenta de trabajo separada y solo tener los proyectos en mi currículum sin vincularlos al github.

— Casi seguramente

@AlmostSurely - +1 en esta respuesta - Creo que tit es la correcta. Mantener sus asuntos privados, ya sean técnicos o de otro tipo, es siempre la mejor política, por los motivos aquí mencionados y muchos otros también. Sin embargo, puede incluir sus proyectos privados en su currículum e incluso vincularlos a su repositorio privado de github para mostrar lo que ha estado haciendo. Si necesita pasar a otro trabajo, hacer cosas por su cuenta fuera del trabajo para ampliar sus horizontes y aprender nuevas habilidades puede (pero no siempre ...) ser una ventaja: muestra que ama su trabajo, está ambicioso y enérgico, etc.

— Vector

también evita / reduce la amenaza real de que piensen que un código similar en sus proyectos personales es robado del trabajo que hicieron por ellos. Muchos empleadores exigen la propiedad de todo el código que escribe durante su empleo, incluso el código que escribe en su tiempo libre que no está relacionado con el trabajo. No puedo decir si tal reclamo se mantendrá en el tribunal (y dependería de las leyes locales de todos modos) pero es algo común y desea evitar complicaciones como esa si termina en una disputa laboral de cualquier tipo.

— Jwenting

incluso el código que escribes en tu tiempo libre que no está relacionado con el trabajo , sí. He firmado NDA que esencialmente les dio propiedad sobre mi materia gris de programación. No puedo decir si tal reclamo se mantendrá en la corte , no creo que lo hagan en un tribunal de los EE. UU., Así que nunca me preocupé demasiado por eso, pero lo presentaron allí para que usted no "ponerse lindo" - factor de intimidación.

— Vector

Los proyectos de la empresa deben mantenerse bajo una organización separada. entonces es fácil ver qué proyectos son suyos y cuáles son de la compañía. cuando se vaya, no necesita entregar su cuenta, ya que solo puede dar acceso a la organización a otra persona de la empresa.

— eMBee