Soy novato en el sistema de control de versiones Git y he usado Tortoise Svn, VSS. Pensé en contribuir con mi código como trabajo de código abierto en github [Moving by crowds voice], abrí una cuenta y creé un repositorio para el proyecto. Solo más tarde supe que los principiantes tuts / Comenzando en Github usaron la línea de comando y hombre, esa no es la forma en que me gustaba que fuera el sistema de control de fuente, así que me dirigí a SO para obtener respuestas, obtuve muchas y me di extensión GUI para administrarlo pero aún ¿Qué sigue? ¿Cómo propongo mi nuevo proyecto a Git a través de Gui y qué pasa con el archivo Léame, tiene que ser realmente un ReadMe.MDarchivo? El tipo de proyecto son extensores personalizados, controles personalizados en asp.net (c #) Me gustaría que la gente descargara el dll [resultado final del proyecto]pero debería ser yo quien decida quién se une a mí en el proyecto y creo que esto es lo que significa github por Repositorios privados [Ninguno para una cuenta gratuita]. Así que mi pregunta se reduce a dos puntos,
¿Este tipo de proyecto necesita ser un repositorio privado? [No es una respuesta de tipo sugerencia/encuesta, quiero que alguien me informe sobre los problemas que enfrentaron al hacer tal cosa y los beneficios]
¿Cómo empiezo? Google no me dio respuestas completas a esto. Hay fragmentos tirados por todas partes con poca información. Dame una fuente
En primer lugar, recomendaría ver "Linus Torvalds on Git" , una charla técnica de Google del creador de git. Dura una hora, pero es una maravillosa introducción a la filosofía detrás del control de versiones distribuidas, especialmente git. No es un instructivo, y ni siquiera es particularmente técnico. En realidad, se trata principalmente de gestión de proyectos, y es bastante entretenido.
El principio central a entender es que todos tienen su propia copia del repositorio . Las personas colaboran enviando y recibiendo conjuntos de cambios. Tomar un conjunto de cambios de alguien e incorporarlos a su repositorio se denomina "extracción". Enviar un conjunto de cambios desde su repositorio a otro se llama "empujar".
¿Este tipo de proyecto necesita ser un repositorio privado?
En una cuenta gratuita de GitHub, el código fuente de su proyecto y su historial son públicos y cualquiera puede verlos. Cualquiera puede hacer clic en el botón "Fork" y hacer su propia copia de su proyecto de GitHub. Su copia estará claramente etiquetada como una bifurcación de su original. (Por ejemplo, eche un vistazo a la esquina superior izquierda de esta página , dice "daxelrod/pod-pseudopod", y luego debajo, "forked from allisonrandal/pod-pseudopod".)
De forma predeterminada, usted es el único que puede enviar cambios a su copia del proyecto. Si alguien más ha realizado una mejora en su copia del proyecto, puede enviarle una solicitud de extracción ; es decir, una solicitud para que incorpore su mejora en su copia del proyecto. Es enteramente su decisión si acepta una solicitud de extracción.
Como administrador de su copia del repositorio, puede agregar colaboradores, si lo desea. Un colaborador es una persona específica en la que confía para enviar cambios directamente a su copia del proyecto. Esto es completamente opcional y la mayoría de los proyectos de GitHub no tienen colaboradores; simplemente aceptan solicitudes de extracción.
Una cuenta paga de GitHub le brinda la posibilidad de crear repositorios privados. Un repositorio privado solo puede ser visto y bifurcado por personas específicas que haya elegido como colaboradores privados.
¿Qué pasa con el archivo Léame, tiene que ser realmente un archivo Léame.MD?
Es suficiente enviar un archivo de texto sin formato llamado README . Si quiere ser elegante con el formato, puede crear un archivo README.md y usar Markdown en él; la misma sintaxis que usa para dar formato a las preguntas de desbordamiento de pila.
Google no me dio respuestas completas a esto, hay fragmentos tirados por todas partes con poca información en ellos. Dame una fuente
Permítanme editorializar por un momento. Git es, en el fondo, un programa de línea de comandos, por lo que la mayor parte de la referencia que verá implica interactuar con él desde la línea de comandos. Personalmente, te recomiendo que aprendas git usando la línea de comandos. De esa forma, comprenderá lo que sucede y podrá utilizar la gran mayoría de la ayuda y la documentación. Solo recomiendo usar una GUI una vez que sepa cómo usar Git desde la línea de comandos.
Si desea aprender git de línea de comandos, Pro Git es un recurso fantástico. Está disponible como libro o gratis en línea. Honestamente, incluso si no está aprendiendo Git de línea de comandos, puede ser una buena introducción a los conceptos y flujos de trabajo.
Sin embargo, si insiste en una GUI, eche un vistazo a Una guía ilustrada de Git en Windows , que usa git-gui. Si hace esto , ¡no se asuste con la documentación o los tutoriales que usan la línea de comando ! Sus principios aún se aplican, excepto que está haciendo clic en los comandos en lugar de escribirlos. (Y sí, sé que es una simplificación excesiva).
Su flujo de trabajo inicial de GitHub para crear un proyecto, confirmar su primer cambio y enviarlo, se detalla aquí , nuevamente, con instrucciones de línea de comando. La idea básica es que tenga un repositorio en GitHub y un clon del mismo en su disco duro local. Confirmas los cambios en tu repositorio local, luego los envías al de GitHub cuando estés listo para compartirlos.
I create a local read-me and push it to repoo viceversa
daxelrod
Tecnologías profundas
daxelrod