Historia de Git
Git es una de esas herramientas tan fáciles de usar que a menudo no aprendes muchos matices. Terminas clonando un repositorio de Internet y eso es todo. Si realiza cambios, es posible que los esté rastreando y, si está realmente en lo correcto, puede crear una solicitud para devolver el proyecto. Pero puedes hacer mucho más. Por ejemplo, ¿sabía que Git puede rastrear documentos de Word colaborativos? ¿O administrar sus archivos de inicio en varias cajas de Linux?
Git pertenece a una familia de productos de software que controlan las revisiones (o versiones). La idea es que pueda desarrollar programas (por ejemplo) y realizar un seguimiento de cada revisión. Los buenos sistemas tienen disposiciones que permiten que muchas personas trabajen en un proyecto al mismo tiempo. Por lo general, también hay alguna forma de dividir un proyecto en diferentes partes. Por ejemplo, podría dividirse para desarrollar una versión del producto para otro mercado o probar una función experimental sin romper el desarrollo normal. En algunos casos, eventualmente devolverá esa división a la línea principal.
Aunque en la próxima entrega te daré algunos usos extraños de Git que pueden resultarle útiles, esta publicación es principalmente la historia de cómo se creó Git. El desarrollo de código abierto es conocido por sus guerras ardientes y hay al menos algunas en esta historia. Y según un verdadero hacker, el héroe de la historia decide que no le gustan las herramientas que usa de esa manera ... bueno, ¿qué harías tú?
Controladores de la guerra de versiones
Históricamente, muchos programas que realizaban esta función tenían una mentalidad de servidor central. Es decir, el código residía en alguna parte de la red. Cuando desee procesar un archivo, lo marca. Esto solo funcionó si nadie más lo controlaba. Por supuesto, si tuvo éxito, nadie más podría verificar sus archivos hasta que los restaure. Si estaba lejos de la red y quería trabajar en algo, es una pena.
Sin embargo, las herramientas más modernas relajan algunas de estas limitaciones. Idealmente, una herramienta podría proporcionarle una copia local de un proyecto y mantener automáticamente otras copias actualizadas a medida que publica cambios. De esa manera, no se perdía ninguna copia central, se podía trabajar en cualquier lugar y no era necesario coordinar el trabajo en varias cosas con otros compañeros de equipo.
Herramienta cerrada
Un equipo distribuido muy grande está desarrollando el kernel de Linux. A finales de 1998, el equipo luchó con la gestión de revisiones. Programador central, [Larry McVoy], tenía una empresa que producía un producto de control de versiones distribuido escalable llamado BitKeeper. Aunque era un producto comercial, existía una licencia comunitaria que le permitía usarlo, siempre que no trabajara en una herramienta competitiva mientras usaba el producto y durante un año después. La restricción se aplicó tanto a la competencia comercial como a la de código abierto. Aunque el producto almacenaba la mayoría de los datos en su máquina, era un elemento del servidor, por lo que la empresa podía rastrear su uso del producto.
En 2002, el equipo del kernel de Linux adoptó BitKeeper. [Linux Torvalds] fue uno de los proponentes del nuevo sistema. Sin embargo, otros desarrolladores (y a los interesados les gusta [Richard Stallman] preocupado por usar su propia herramienta para desarrollar código abierto. BitMover, la compañía detrás de BitKeeper, agregó algunas puertas de enlace para que los desarrolladores que quisieran usar un sistema diferente pudieran hacerlo hasta cierto punto.
En su mayor parte, las cosas se calmaron con solo ocasionales escaramuzas en llamas aquí y allá. Eso es hasta 2005 cuando [McVoy’s] La empresa ha anunciado que interrumpirá la versión gratuita de BitKeeper. Aparentemente, la razón se debió a que un usuario estaba desarrollando un cliente que agregó características desde la versión comercial a la gratuita.
Nuevas herramientas
Como resultado, surgieron dos proyectos para desarrollar un reemplazo. Mercury era uno y Git, por supuesto, era el otro. [McVoy] contactó a un cliente comercial exigiendo que su empleado [Bryan O’Sullivan] dejar de contribuir a Mercurial, lo cual hizo. Por supuesto, tanto Mercurial como Git se realizaron, y Git se convirtió no solo en el sistema de control de versiones del equipo central, sino también en el sistema para muchas otras personas.
Nacimiento de Git
[Linus] de hecho buscó otro sistema inmediato. Entonces nadie tenía el rendimiento o las características que serían apropiadas para el equipo de desarrollo central. Diseñó un git para la velocidad, la simplicidad y para evitar hacer las mismas cosas que hizo CVS (un programa de control de versiones insultado).
Según los informes, el desarrollo inicial duró unos días. Desde el lanzamiento de la versión 1.0 a finales de 2005, el software ha creado más de un sitio web principal y se ha convertido en el sistema elegido por muchos desarrolladores, tanto de código abierto como comerciales.
Hombre repo
El diagrama de flujo muestra el secreto de cómo git maneja muchos desarrolladores a la vez: repositorios o repositorios. Cada desarrollador tiene una copia completa de todo el proyecto (el repositorio local). De hecho, si no le importa compartir, ni siquiera necesita un repositorio remoto. Tu rap privado es un proyecto de git tan completo como cualquier otro, incluso el remoto, que probablemente esté en GitHub u otro servidor web. Realiza los cambios en la carpeta de trabajo, escenifica lo que "terminó" (por ahora) y se lo entrega a su rap. Cuando llega el momento, presiona los cambios en el control remoto y se fusiona con otros cambios.
Curiosamente, git no solo funciona con archivos de texto (te mostraré más sobre eso en la próxima entrega). Sin embargo, funciona mejor en archivos de texto, ya que es lo suficientemente inteligente como para notar cambios en archivos que no se superponen y fusionarlos automáticamente. Entonces, si soluciono un error con un bucle for en algún código y cambias algunos mensajes de error, git ordenará todo cuando nuestro código se combine.
Eso no siempre funciona, por supuesto. Esto provoca conflictos que debe resolver manualmente. Pero a menos que tenga dos personas tocando exactamente las mismas partes del código, git generalmente hace un buen trabajo al resolver la diferencia. Por supuesto, los archivos binarios generalmente no tienen ese lujo. No se puede diferenciar exactamente un ícono para ver a una persona tirando de un bigote y otra persona comenzar a poner verde el fondo. Sin embargo, técnicamente, si pudieras descubrir el algoritmo, podrías agregarlo a git.
Conexión
Si desea aumentar su conocimiento de git más allá de simplemente hacer un clon, podría hacer algo peor que dedicar 15 minutos a este tutorial. Si ya conoce los conceptos básicos, puede encontrar cosas nuevas en un tutorial más avanzado o ver el video de un discurso. [Linus] le dio a Git algo de tiempo.
En 2016, por cierto, BitKeeper anunció que se trasladarán a la licencia Apache, que por supuesto es de código abierto. Un poco irónico, ¿no?
https://www.youtube.com/watch?v=8ET_gl1qAZ0
Créditos fotográficos:
- Soldado Tux, de [Sharkey], CC BY-SA 3.0
- [Linus Torvalds] de la revista Linux, CC BY-SA 3.0
- Diagrama de flujo de [Lbhtw], CC BY-SA 3.0
nsayer dice:
https://xkcd.com/1597/
John dice:
Sí, soy yo. 🙂
¿Quién es Linux Torvalds? (Eso es un poco como Homer con "cuál es la parrilla" en la construcción de un episodio de barbacoa, pero aún así. 🙂
yeti dice:
> https://xkcd.com/1597/
¡En realidad!
He estado usando Git durante años, pero con poca frecuencia y una vez más arruinando mis repositorios locales o remotos ... pero afortunadamente no ambos al mismo tiempo ... 😉 ... ¡así que no es ragnarök!
Ricardo dice:
Sí, yo también. Aunque usar GitKraken hace la vida más fácil.
thejonarnold dice:
GitKraken ha cambiado seriamente la vida en mi empresa. Git pasó de ser una herramienta arcana con la que todos temían enojarse, a un sistema de colaboración significativo. Siempre he sido un tipo git / bash, pero honestamente es tan fácil de usar que incluso me he convertido en una GUI ... su herramienta de gestión de proyectos cuerpo a cuerpo AxoSoft tampoco es demasiado miserable.
W dice:
http://ohshitgit.com/
nsayer dice:
+1. Aprendí algo nuevo.
jcamdr dice:
"Nadie más podía comprobar sus archivos hasta que los restaurara". Esto nunca fue cierto, ni siquiera con el RCS ahora obsoleto. De la documentación de RCS:
El bloqueo asegura que usted, y solo usted, pueda verificar la próxima actualización y evitar problemas desagradables si varias personas están trabajando en el mismo archivo. Incluso si una revisión está bloqueada, aún se puede verificar su lectura, compilación, etc. Todo lo que evita el bloqueo es el registro de cualquier otra persona que no sea el casillero.
dinamodan dice:
Técnicamente cierto, sí. Pero git maneja este "bloqueo" automáticamente por diferentes medios. Los depósitos con acceso de solo lectura le permiten cambiar todo lo que desee e incluso enviar cambios a otro repositorio. Pero si desea que sus cambios se fusionen con el repositorio y la rama que marcó, envíe una solicitud para "extraer" (así es como lo hace github). Parece que me he encontrado con complementos de git que también tienen permisos por rama en los repositorios.
Mate dice:
Hay muchos programas que bloquean las descargas. Simulador de circuito de cadencia, por ejemplo.
jcamdr dice:
Parece ser un caso muy inusual para mí, quizás por otras razones técnicas. Hay otros programas de cadencia que utilizan un candado normalmente. Por ejemplo, de un sitio web de soporte de cadencia:
"Los archivos Design Entry HDL (DEHDL o ConceptHDL) .lck se crean cuando un diseñador abre una página de esquema. Si otro diseñador intenta abrir la misma página de esquema, recibirá una advertencia de que la página está en modo de solo lectura y no poder escribir en esa página ".Steven Gann dice:
También SolidWorks.
BioSehnsucht dice:
Recuerdo que tuvimos problemas con esto en Litestep el día (antes de 2000). Quiero decir, ¿usamos CVS? Para obtener puntos extra, se alojó en una cuenta universitaria de un colaborador en Sudáfrica, por lo que para casi todos los involucrados fue muy lento.
pelrun dice:
Muchos VCS comerciales han hecho esto, por lo que "nunca es cierto" está mal. ClearCase de IBM es el que tuve la desgracia de encontrar hace unos años.
Alan Hightower dice:
¡Predigo que este artículo solo obtendrá 5 respuestas!
Me preocupan los administradores de rap en un entorno corporativo / corporativo que insisten en usar git en lugar de una herramienta central como una subversión debido a alguna doctrina religiosa justa. Luego se preguntan por qué los desarrolladores están haciendo nuevas extracciones para un entorno limitado local de proyectos muy grandes: los proyectos muy antiguos requieren horas o incluso días para obtener todo y consumir GB o TB de ancho de banda de red, multiplicado por cientos de desarrolladores. Hay formas de mitigar esto en git, sin embargo, no es intuitivo para la mayoría (por ejemplo) socavar. Si bien no puedo culpar a la herramienta, ciertamente puedo culpar a su fácil uso.
jcamdr dice:
Como git ahora se usa en proyectos cada vez más grandes, se optimizará gradualmente para esa carga de trabajo. Algunas grandes empresas no usan git debido a problemas de escalado, pero en su mayoría usan algunas otras herramientas modernas en lugar del respetable debilitamiento.
dinamodan dice:
Bueno, no sé si SVN (reversión como mencionaste) funciona muy bien como herramienta escalable. Los he usado todos, CVS, SVN y git con organizaciones grandes con bases de código de computadora grandes y grandes, y solo git parece escalar bien. La palabra clave aquí es DISTRIBUIDA. Ni CVS ni SVN tienen ningún concepto de distribución. Eso es una diferencia escalable clave entre estos sistemas. Git se puede centralizar si lo desea. Pero no tiene por qué serlo, y eso no lo limita. Cuéntanos cómo funcionaría github con SVN en general. Luego dígale a github que su sistema no es escalable. No tiene nada de religioso.
magasparel dice:
De hecho, me encanta Git, pero solo quería aclarar algunas cosas.
GitHub admite SVN
https://help.github.com/articles/support-for-subversion-clients/Microsoft necesitaba crear herramientas personalizadas para usar git a gran escala
https://github.com/Microsoft/GVFSjcamdr dice:
Un problema de Microsoft estaba más relacionado con el rendimiento de NTFS deficiente y la incapacidad de dividir realmente un gran repositorio en subproyectos coherentes.
man-x86 dice:
Solía transferir repositorios dentro de las máquinas a través de un archivo de almacenamiento (a veces, las memorias USB eran más rápidas que usar la red), que era mucho más rápido que svn o git para clonar rap.
Git, svn o incluso rsync transmiten datos de la misma manera, con una enorme hoja de cálculo para verificar y mantener el historial de revisiones. Es muy eficaz para sincronizaciones diarias o semanales, pero es increíble cuando hay muchos cambios en ambos lados del rap.
No soy "racista" entre las herramientas de sincronización / control de versiones, aunque ciertamente estoy de acuerdo contigo sobre la facilidad de uso de git ...Andy Dodd dice:
No veo cómo socavar es mejor en este sentido, porque DEBE sincronizar desde el servidor CADA VEZ.
También una de las cosas que impulsa fundamentalmente a las personas a los sistemas de VC distribuidos (incluso si su modelo de desarrollo está en gran parte centralizado): cada vez más personas trabajan con computadoras portátiles que pueden no tener conexiones de red el 100% del tiempo.
SVN se vuelve inútil si la red falla, solo eso lo hace inútil en los tiempos modernos.
Alan Hightower dice:
Es un intercambio. La mayoría de los entornos empresariales tienen conectividad a Internet el 100% del tiempo.
Cuando esté trabajando en un producto con 480 repositorios de proyectos de git y miles de desarrolladores contribuyendo todos los días, verifique el historial de ese código cuando todo lo que realmente desea es la última entrega, puede llevar algún tiempo. Hay formas inteligentes de administrar un VC distribuido con grandes proyectos con grandes protocolos de puesta en marcha, pero la mayoría de la gente lee el capítulo 1 de HOWTO y, por defecto, git pull. Se necesita una comprensión y una atención más profundas para trabajar con git en ese entorno y eso no siempre funciona con una combinación del 75% de picos amarillos que se encuentran en la mayoría de las grandes empresas.
Jeff dice:
clon de git –depth = 1
nitePhyyre dice:
"La mayoría de las configuraciones empresariales tienen conectividad de red el 100% del tiempo".
La mayoría de las empresas nunca tienen a nadie que viaje por trabajo y las personas nunca tienen vacaciones y necesitan hacer algo mientras están fuera.¿Te importa al menos / compartir / lo que fumas?
MacSimsky dice:
Mmm. eso me convierte en el quinto encuestado. Está bien
Simón dice:
clon de git - profundidad 1
No, gracias.
jcamdr dice:
“Sin embargo, las herramientas más modernas aflojan algunas de estas limitaciones. Idealmente, una herramienta podría proporcionarle una copia local de un proyecto y mantener automáticamente otras copias actualizadas a medida que publica cambios. "Palabras confusas.
Incluso el antiguo RCS te da una copia local donde puedes hacer lo que quieras. El bloqueo solo existe para evitar que más de una persona modifique un archivo solo en el lado del servidor. Ningún sistema de control que conozca, incluso git, mantiene otras copias actualizadas mientras otras publican cambios, y no creo que sea una característica deseable. Una actualización es siempre un comando explícito.
eriklscott dice:
ClearCase lo hizo. Fue grandioso. También costaba $ 5K por usuario, requería Monster Hardware para el servidor, y con ~ 45 desarrolladores teníamos que tener un administrador de tiempo completo y un administrador de versiones de ClearCase. Nuevamente, también mantuvimos algunas ramas personalizadas allí (porque no pudimos exponer ninguna parte del código habitual de ningún cliente a los otros usuarios, y Java se compila muy bien). IBM terminó poseyéndolo, por lo que probablemente ya esté casi muerto.
eriklscott dice:
Oh, Dios mío, IBM todavía lo admite. Parece que han funcionado un poco. Tuvieron algunos clientes excelentes en el día, por lo que tal vez algunas grandes tiendas todavía lo estén usando. No.
Culpa general dice:
Odiaba cada segundo cuando tenía que usar ClearCase o cualquier otra herramienta que IBM compró a Rational y no cambió durante años. Perforce sin embargo fue muy agradable y simple. Aunque pusieron los botones "Retorno" y "Reparar" (creo) uno al lado del otro en el menú contextual de Windows, lo que una vez causó una pérdida de trabajo de mi parte.
W dice:
Todavía usamos ClearCase (¡y ClearQuest para acompañar!) En el trabajo, para una base de código de ~ 10MLOC. Empezando a recuperarlo ahora a favor de git.
ClearCase tiene una curva de aprendizaje infernal para hacer incluso cosas muy básicas, pero la forma en que le permite combinar componentes en líneas de base y luego desarrollarlos por separado (y rastrear todo correctamente) es mucho más poderosa que cualquier otra herramienta de CM que hayamos probado. , incluido git. Por supuesto, más poder es más una oportunidad para romper su depósito, por lo que es difícil de hacer.
darronb dice:
¿Genial? Craptastic, en mi opinión. Esperar a que llegara increíblemente lento y verificar los archivos fue la base para jugar a crear mi propio RCS. Eso básicamente se detuvo en seco la segunda vez que encontré Perforce. Perforce es la herramienta de alto rendimiento que debe ser RCS. Funcionó, hace 15 años, aproximadamente tres veces más rápido de forma remota a través de mi conexión lenta a Internet que ClearCase / ClearQuest en la LAN local de mi empleador.
Clovis Fritzen dice:
No entiendo esto: ¿cuál es la relación entre Git y GitHub? Quiero decir, la página git-scm real (https://git-scm.com/) parece estar alojada en gitHub, entonces ¿es gitHub el sistema "principal" utilizado por Git o no? El artículo menciona gitHub solo una vez (CTRL + F'ed it).
Tuetuopay dice:
GitHub es solo una colección de repositorios remotos disponibles gratuitamente. Puede crear un proyecto allí y enviar su repositorio local allí para que otras personas lo clonen.
git-scm no está alojado en GitHub por sí mismo (github no maneja solicitudes http), pero su código fuente está alojado en github, ya que GitHub es el "facebook de los desarrolladores": tiene la mayoría de las funciones "sociales" en la interfaz de usuario de su sitio web . Esto se hace para ayudar a las personas a modificar este sitio.
GitHub no se une a Git en sí, ya que los desarrolladores de git usan algún otro repositorio para él. Además, el repositorio "git / git" (https://github.com/git/git) es, como dijeron los desarrolladores, solo un espejo de su propio repositorio remoto.METRO dice:
De hecho, ¡puedes alojar un sitio web de git rap en GitHub! https://pages.github.com
METRO dice:
GitHub es un proveedor de alojamiento para repositorios de git en la nube. El proyecto git los usa para alojar su código y su sitio web como muchos otros proyectos de código abierto.
dinamodan dice:
Github es un servicio de git alojado. Así como puede alojar su propio sitio web, puede alojar su propio repositorio de git. O puede pagar a Github para que lo aloje (y gratis para proyectos de código abierto). También proporciona algunas características de "código social" como solicitudes de extracción y pistas comerciales y gráficos de contribución.
Hay un montón de proveedores de git alojados que hacen cosas similares como Github: Kiln / Fogbugz, Bitbucket / Jira, Gitlab, etc. Una cosa que me gusta de Kiln / Fogbugz es que cuando hace referencia a un número de caso en su mensaje de comisión a Kiln, automáticamente registra una entrada en ese caso en Fogbugz. Jira probablemente hace lo mismo. Creo que probablemente Github también. Entonces, hay características de "valor agregado" como la de Github y otras. Creo que incluso puede haber algunos programas de alojamiento de git de código gratuito que tienen rastreadores problemáticos que hacen cosas similares.
LATA dice:
Encuentro que Gitlab tiene un error sorprendente.
Una de las buenas características es que puede mencionar “Número fijo # 314” en las comisiones y no solo hará referencia, sino que cerrará esa cosa.
Además, hay muchas cosas buenas como la marca y los grupos.
Gregkennedy dice:
¿Te acuerdas de Sourceforge? Github es el nuevo calor.
Jarek319 dice:
Nunca entendí git hasta que vi ese diagrama
¡Gracias!
Jim Shortz dice:
Lo siento Al, no estoy de acuerdo con que tu caracterización de git sea "tan simple de usar". Sí, clonar un repositorio y comenzar la construcción es fácil, pero cuando comienzas a cambiar, trabajas en sucursales y (lo peor de todo) intentas revertir las cosas, se vuelve complicado rápidamente.
Ejemplo: ¿Cómo deshago un malentendido local? El comando "revertir" solo funciona en cambios decididos. En su lugar, utiliza el comando "pago" con un incomprensible guión doble. Este es el mismo comando que también usa para cambiar ramas o crear una nueva. ¡Imagínate!
Revertir los cambios realizados suele ser sencillo. Sin embargo, cuando llegue el momento de reemplazarlo, será mejor que invierta lo contrario. Si solo fusiona la rama original, felizmente ignorará su cambio y usted no es el más sabio desde que terminó la fusión.
¿Qué sucede si quiero revertir PARTE de un cambio realizado? ¡Obtén tu doctorado para averiguarlo!
magasparel dice:
Totalmente de acuerdo. Busque en cualquier lugar los pros y los contras de git, y definitivamente le resultará "difícil de aprender" en la mayoría de ellos
invitado dice:
Prueba git cola https://git-cola.github.io/
Hace que sea más fácil ver los cambios y decidir qué revertir (por ejemplo, mediante líneas seleccionadas) y la operación real a revertir. También tiene muchas otras características.No puedo imaginar volver a socavar ahora.
Traumflug dice:
Parece que te confundiste con la redacción de Git. Equivalente a 'svn revert' no es 'git revert', sino 'git reset'. El conjunto controlado de archivos se restaura a lo que está en el repositorio. También existe "git revert", pero esto hace algo más.
¿Verificando una versión anterior de un archivo, ignorando lo que hay en la confirmación más reciente? Solo dile a Git esta versión: 'git checkout HEAD ^ myfile.c'. (HEAD es la confirmación más reciente / actual, HEAD ^ es la anterior)
¿Deshacer parte de un compromiso? Mire la versión anterior, luego hágalo con '-amend'. Se puede hacer para archivos completos, o incluso con piezas (partes de archivos) con la opción '-pag'.
Creo que el secreto de Git es ejecutar "gitk-all" todo el tiempo y volver a cargar ese gráfico con frecuencia. Tan pronto como uno puede ver lo que sucede después de cada comando, toda la niebla se despeja repentinamente y aparece el brillo de esta herramienta.
daniel_h dice:
Cuando inicias 'git status', te dice qué hacer:
# Cambios no arreglados para la acción:
# (use "git add ..." para actualizar lo que se hará)
# (use "git checkout - ..." para descartar los cambios en el directorio de trabajo)> ¿Qué pasa si quiero revertir PARTE de un cambio realizado? ¡Obtén tu doctorado para averiguarlo!
Regresar no es especial; 'git revert' es solo una abreviatura de una nueva confirmación que hace lo contrario de la confirmación original. Puede verificar los archivos en la revisión anterior a la que introdujo los cambios que desea revertir:
git checkout revertir ^ ruta / a / archivo
luego agregue el contenido original:
git agregar - ruta del paquete / a / archivo
Aunque haría una rebase interactiva para dividir la confirmación en dos confirmaciones separadas y luego procesarlas.
Un dron dice:
Hmm ... ¿GIT es realmente DVCS? ¿Quizás una fusión de tecnología GIT y Blockchain como almacenamiento y / o auténtico?
GRAMO dice:
Dejé de leer en "Git es una de esas herramientas tan sencillas de usar que ..."
Ricardo dice:
Jajaja. Encontré una página web que la promocionaba como la guía fácil para git. Fueron varias páginas de instrucciones. Fallar ....
svn commit
actualización svntodo lo que necesito recordar.
git, bueno, ¿qué es? agregar, etapa luego presionar luego cargar luego sincronizar o si se fusionó, agregó o empujó y tiró, o tiró y luego empujó ...
ajford dice:
git agregar ruta / a / archivo / o / dir /
git commit
git pushParece que puede ser un comando más que svn.
Oh, espera, puedes hacerlo
git commit -a
git pushAhora son iguales. También estoy bastante seguro de que si comienza a hacer otras cosas con un sistema de control de versión A, puede enumerar otros comandos, pero su ejemplo es tan inventado como puedo imaginar.
Ahora sí, tienes un empujón contra el tirón, pero vamos, si quieres tu código ahí, es un empujón. Si desea que el código aquí esté aquí en su copia, es un tirón. Eso no es exactamente un giro del cerebro.
magasparel dice:
Creo que git es la herramienta más nítida. Me gustó la simplicidad de svn, pero cuanto más aprendí con git, más pensé "¿cómo diablos haría esto con SVN?"
jcamdr dice:
Realmente cierto. Buen analisis.
Traumflug dice:
Es posible que aún no hayas reconocido que Git es mucho más que un bote de basura para códigos antiguos. Si está satisfecho con solo un compromiso, también puede usar una herramienta de respaldo de archivos común.
Git se trata de manejar, remezclar y refinar los cambios de código. Los usuarios experimentados de Git están a cargo primero, luego prueban su código. Debido a que las transferencias se pueden refinar en cualquier momento, simplemente use '-amend'.
me dice:
Cada conjunto de instrucciones o tutoriales en Git fue increíble. ¿Cómo empieza la gente esto?
Sigo el tutorial try.github.io vinculado a esta página.Todo parecía bien hasta la 1.10 - depósitos remotos.
Entonces ... en este punto creé un repositorio local, agregué algunos archivos, hice algunas validaciones y verifiqué el estado.
¿Ahora es cuando agrego la URL remota? ¿Cómo funciona esto? Entonces ... el tutorial me ordena escribir GitHub-url. De acuerdo, perdonaré la falta de instrucciones sobre la instalación de mi propio servidor remoto, ya que supongo que eso no es algo para empezar. Sin embargo, ¿de dónde viene esta URL? ¡El tutorial lo saca de entre las mejillas aparentemente!Supongo que la parte "/ try-git /" se refiere a la cuenta de GitHub de alguien. Entonces "try_git.git" debe ser el nombre del repositorio creado por el usuario. Entonces ... ¿simplemente arma un nombre único y luego abre un nuevo repositorio para usted en GitHub (asumiendo que tiene una cuenta llamada try-git)? O necesita ir al servidor (GitHub.com) y crear un archivo .git esquelético o en blanco con ese nombre de antemano. ¿Qué pasa si ya tiene un repositorio de prueba try-git.git en su cuenta de GitHub? ¿Lo reemplazará? ¿Fusionarlos? ¿Cometer un error?
¿Qué pasa con la autenticación? GitHub no permite que nadie cargue nada con el nombre de otra persona, ¿verdad? ¿Pasamos por una parte donde el programa real pedía una contraseña o algo así?
En cuanto a "origen". De donde vino eso?
¡¡¡Demasiada magia !!!
Ahora 1.11 - Empuje lejos
Todavía me pregunto de dónde vino el "origen". Ahora también tengo curiosidad por "maestro". Está bien ... esos nombres tienen sentido para mí. El repositorio remoto es su copia maestra. El lugar donde originalmente empezó todo es, por tanto, el origen. Está bien ... pero cómo se llamaban. Más importante aún ... Cuando descargo esto en una segunda máquina, o lo hace una segunda persona, o creo una rama ... ¿¡¿cómo se llamarán?!?
¿Por qué incluso tengo que especificar un origen? Estoy en el directorio de origen. ¿Qué más empujaría? Y por qué especifico "maestro". ¿Dónde más podría enviar ... la copia local de algún otro desarrollador? ¡¿Cómo funcionaría ?!
1.12 - Retirar
De acuerdo ... Estamos sacando cambios del repositorio remoto al local, ¿no? Supongo que esto tiene sentido. Este solía hacerme tropezar mucho más que ahora. "Git pull origin master". Mi cerebro de habla inglesa dice "Git, lleva las cosas originales al maestro". todo lo contrario de lo que sucede. Estudié alemán. De acuerdo ... entonces es un orden de palabras diferente en términos de idioma ... ... lo tengo. Apuesto a que tiene mucho sentido para un hablante nativo de sueco. Está bien, pero los manuales y tutoriales en inglés serían una buena manera de explicar esto explícitamente. Quizás algo así como un "git pull". Los ejemplos son buenos y todo, pero a veces estas descripciones de uso aún ayudan.
1.17 - Deshacer
¿Qué tiene que ver la restauración de octocat.txt con la eliminación de octodog.txt?1.19 - Cambio de sucursales
Esto da miedo. Parece que estoy descargando una rama al directorio local del repositorio. Estoy haciendo eso? ¿Estoy reemplazando mi trabajo no involucrado en la rama actual? ¿No solo mantengo diferentes ramas en varios directorios y cambio entre ellas a través de cd (línea de comando) o navegando en la interfaz gráfica de usuario?
1.23 - Preparación para la fusión
Bien, recuperé mis archivos cuando volví a la rama principal, pero todos los archivos se eliminaron mientras tanto. ¿Acabo de perder algún cambio incomprendido? ¿Eso fue un alijo? Eso parece fácil de olvidar. ¿Por qué querría trabajar así cuando solo puedo insertar ramas separadas en directorios locales separados conectados por un repositorio remoto compartido? El disco duro espacial hoy en día no es tan raro y valioso. Arriesgarme a perder mucho trabajo me parece injusto.
Bueno ... esto es lo más lejano que he hecho a través de un tutorial de Git antes de levantar mis manos, llorar WTF y navegar para leer algo más. Y sin embargo ... sigo pensando ... ¿WTF?
abad dice:
Sí, es un poco difícil de aprender.
Sin embargo, el 95% del tiempo solo necesita agregar, comprometer y presionar.Puedo ayudar con cualquiera de sus preguntas.
1,10
El comando "git remote add origin https://github.com/try-git/try_git.git" es el lugar donde se asigna el nombre "origen" (al enlace de github). No estoy seguro si necesita crearlo en github primero o si este comando lo hace por usted (primero los creé en el sitio de github)El tutorial interactivo omite el paso auténtico.
1,11
> el nombre de la sucursal local predeterminado es maestrousted maestro / origen intercambiado en su modelo mental (puedo ver por qué, origen es un nombre engañoso cuando comienza localmente y luego empuja a una distancia).
1.12
"Git, lleva las cosas originales al maestro". Sí, eso es correcto.1,17
> ¿Qué tiene que ver octocat.txt con la eliminación de octodog.txt?No está directamente relacionado. En ~ 1.10, realizó un cambio en octocat.txt. Desde entonces has estado haciendo trampa con octodog.txt pero ahora quieres borrar cualquier evidencia de eso. El comando aquí especifica octocat.txt porque queremos:
> Continúe y elimine todos los cambios desde la última confirmación de octocat.txt
1,19
Una rama es solo una etiqueta. Le dices a git "hey, este trabajo que estoy haciendo, quiero separarlo del código principal". No se descarga nada del control remoto. No reemplazará los cambios incomprendidos (acabo de probarlo).1,23
¿Pierdes los cambios incomprendidos cuando corres? Si. El caso le dice a git "por favor reemplace mis archivos de trabajo con los de un maestro". Si desea conservar los cambios, debe realizarlos. Ejecute "git status" antes del pago para confirmar que no perderá nada.Piénselo de esta manera: tener solo un conjunto válido de archivos en su computadora también es un riesgo. Tienes que hacerlo a menudo.
No creo que se haya mencionado alijo en el tutorial. No lo usé yo mismo, pero parece una rama temporal.Si desea tener múltiples copias locales, una a la vez, definitivamente puede trabajar con git, funcionará como esperaba (cada copia sabrá en qué rama funciona).
TL; DR: Sí, git es complejo porque es poderoso. Para proyectos de una persona, probablemente solo necesite una rama, confirmar y empujar (este último solo si le importa la copia de seguridad).
Traumflug dice:
Ejecute 'gitk -all' todo el tiempo y actualice (Shift-F5) este gráfico después de cada comando. Ver lo que pasa tiene mucho sentido. Gitk es parte de Git y viene con la distribución estándar.
JIm B dice:
He utilizado unos cinco sistemas de control de versos durante los últimos 30 años. Actualmente mi empleador usa forzosamente, y en casa yo uso subversión (con un depósito local). Por todo lo que he visto, GIT tiene una reputación de complejidad y un modelo difícil de entender. Sí, no es difícil comenzar y simplemente usar los comandos vudú para verificar archivos, pero tan pronto como algo salga mal, debe profundizar o pedirle a un experto que le diga qué pasos arcanos debe tomar para arreglar las cosas.
Para uno de mis proyectos de emulación, una persona entusiasta me rogó que me cambiara a github para que pudieran ayudarme a desarrollarlo. (Por lo general, desarrollo usando svn localmente, luego a veces publico un archivo zip de toda mi fuente en mi sitio web). De mala gana, aprendí lo suficiente como para ponerlo en github, la persona hizo una prueba (espacio agregado a un comentario o algo) para asegurarse de que todo funcionaba. Luego desaparecieron.
dinamodan dice:
Por favor, no renuncies a git tan fácilmente. Usé CVS, luego SVN, luego git, en ese orden. En Windows está TortoiseSVN y creo que Turtle * también para los demás, con una buena integración de shell. Pero es mejor saber lo suficiente sobre la CLI para hacer lo básico. No conozco casi todos los comandos y funciones de git, pero lo adopto de todo corazón sobre los demás (también usé mercurial, que se parece más a git que a los demás). También uso y recomiendo encarecidamente los comandos git gui y gitk, Funciona tanto en Windows como en Linux y puede ayudar a las personas (como yo) que están más orientadas a la interfaz gráfica de usuario.
Como cualquier sistema poderoso, hay mucho que saber, y sí, puede parecer vudú hasta que domines los conceptos básicos.
jcamdr dice:
Usé RCS hace 20 años, luego CVS, luego Subversion y luego git. Git puede ser complejo solo porque puede hacer que algunas características muy complejas sean inusuales para la mayoría de los programas de versiones de control. Claro, puedes irte al infierno si haces algunos comandos por cable, pero por otro lado, porque al igual que cambiar un identificador de git, lo hace bastante resistente a la pérdida de datos. También hay una comunidad muy motivada que comparte habilidades increíbles, incluso en una situación muy difícil.
Detective de FOSS dice:
Esta semana, al menos cuatro proyectos de software libre recibieron solicitudes similares, "Migre a GitHub / CMake". Sin embargo, estos proyectos ya usan cmake y / o alojan el git rap para estar libres de cosas como Source Forge (sin embargo, cualquiera puede clonar en github).
Tal vez sea una nueva tendencia en el trolling.
Dhavenith dice:
Creo que podría ser una nueva forma de spam de enlaces. Recibí una solicitud de extracción de alguien que estaba realizando cambios menores (cambiando el texto de la licencia en README). Luego noté que esta persona está haciendo solicitudes muy similares en muchos repositorios en github y ahora todos los repositorios que han fusionado su cajón lo mencionan como colaborador.
Se ve bien en tu currículum, supongo ...
magasparel dice:
Básicamente, comienzas por aprender a transmitir, luego aprendes qué es un control remoto y cómo empujar y tirar. Luego coges algo y Google cómo solucionarlo. Con el tiempo, se siente cómodo y comienza a comprender lo poderosa y flexible que es una herramienta. Ese fue mi viaje de todos modos
Jeff dice:
A los usuarios de MIHO, SVN les resulta difícil ver el poder porque están acostumbrados a los límites de SVN. Vine de CVS a git, omitiendo SVN, pero las ramas y la conservación son muy fáciles con git, y es rápido tener múltiples versiones activas y saltar entre ellas, sin ninguna conexión al servidor. Las pocas veces que trabajé en SVN, las ramas fueron tan dolorosas que me di cuenta de que se usaban para bifurcaciones grandes y dolorosas en proyectos, no solo para temas.
Dicho esto, si usted mismo está trabajando en un proyecto, entonces realmente no importa tanto. El control de la revisión es del 90% sobre lo que sucede cuando hay un conflicto y del 10% sobre la calidad de la historia.
Alex Rossie dice:
Linus dice que siempre llama a sus proyectos solo, de ahí el nombre git.
Redhatter (VK4MSL) dice:
De hecho, lo llamó "git" porque lo considera un "administrador de contenido de directorio estúpido (pero extremadamente rápido)":
https://github.com/git/git/blame/e83c5163316f89bfbde7d9ab23ca2e25604af290/README
Alex Rossie dice:
Estos llegaron después de que se decidió el nombre.
https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27Git.27_name.3F
Elliot Williams dice:
Es divertido llamar a esto una "historia". Lo recuerdo como si fuera ayer ...
Hubo un tiempo (¿2004?) Cuando SVN era compatible con Canonical / Ubuntu y Git aún era joven cuando parecía que SVN se convertiría en el "estándar" de control de versiones de código abierto. Pero no se distribuyó y era demasiado lento con muchos archivos como el del kernel. Y Git se volvió bastante bueno bastante rápido.
Mercurial siempre ha sido una especie de tercera rueda, en mi opinión, sin patrocinadores a gran escala pero con una base de usuarios decente. Y luego están los bichos raros. ¡Manos arriba por DARCS!
James dice:
Realmente desearía que los darcs tuvieran más tracción, las ideas detrás de esto son realmente geniales, pero la implementación práctica es pita.
Toda la idea de "cherry picking" suena a que en Darcs sería algo encantador y eso me atrajo a darcs hace 6 o 7 años, donde en mi flujo de trabajo es muy común el cherry picking - "Quiero este parche, pero no este un parche "suena como algo para darcs, pero con el tiempo pronto descubrí que esa no es la realidad, la realidad es" Quiero este parche "y darcs dice" claro, pero también debes tomar TODOS estos que son implícitamente dependientes , aunque de hecho solo ha cambiado 1 línea en 1 archivo en ese parche "
Aún me encantaría usar darcs si a alguien se le ocurriera un sistema de resolución / reemplazo de conflictos, por lo que podrías decir "Solo quiero este parche, solo dame las dependencias que faltan como un conflicto y déjame descubrir cómo resolverlo".
Dicho esto, el rendimiento era un problema con los repositorios grandes.
Don Wills dice:
"Mercury siempre ha sido una especie de tercera rueda, en mi opinión, sin patrocinadores a gran escala ..."
¿Facebook no es un mecenas a gran escala?
FWIW, encuentro a Git incomprensible y Mercurial intuitivo y muy fácil de entender y maniobrar.
Ostraco dice:
Sería bueno si hubiera una verificación de revisión para objetos binarios.
Cierto dice:
Un archivo binario sin información útil sobre el formato interno requeriría cantidades masivas de análisis de correlación cruzada. La grabación de archivos puede tardar bastante. No desea grabar un archivo binario grande y aún esperar a que su solicitud regrese horas más tarde. Es el mismo problema que tiene la duplicación de disco, y lo que se hace ahí, los archivos se tiran en el disco tal cual y el servidor, si es inútil intenta identificar y clasificar los archivos y si es posible utilizar información binaria de nuevo creada por las empresas de almacenamiento. para reducir el almacenamiento. No digo que sea imposible, pero los algoritmos de coincidencia de patrones no son tan eficientes y el resultado final habitual es una gran cantidad de energía desperdiciada, se encuentran coincidencias mínimas o no se encuentran y el archivo se guarda como un BLOB (Binary Large OBJECT).
La comparación de archivos ASCII suele ser mucho más fácil, ya que una línea tiene un limitador fácilmente localizable [DOS uses carriage return and line feed (“rn”) and UNIX just uses a line feed (“n”)] que divide el texto en líneas rápidamente comparables para los cambios. La velocidad de procesamiento difiere en muchos acordes debido a esta limitación en los archivos de texto, generalmente los 80 caracteres dan o reciben.
Traumflug dice:
Git maneja bien los archivos binarios.
Si desea manejar archivos binarios en todas las plataformas, debe decirle a Git qué archivos son binarios; de lo contrario, intentará ajustar las terminaciones de línea para cada plataforma.
mi dice:
Parodia de guitarra obligatoria de Downfall:
amigo dice:
No importa cuántos tutoriales mire, o las pautas que lea, o lo que sea, simplemente no puedo entender git. Tengo una pequeña idea de lo que tiene que hacer, pero en realidad, simplemente no tiene sentido para mí. He disparado mi pie tantas veces que lo he estropeado por completo y por completo que ya no me molesto con un idiota. No vale la pena la molestia de nunca estar seguro de que lo que estoy haciendo es lo que estoy asumiendo.
También sé que si preguntas sobre git en StackOverflow, y no estás 100% agradecido por todas las ofertas de git, serás rechazado por git mob. Si su pregunta muestra la cantidad adecuada de respeto y obtiene una respuesta, obtendrá media docena de respuestas diferentes y no tendrá idea de quién es válido. La única respuesta que intentarás será la que empeore todo.
jcamdr dice:
En comparación con la versión de software anterior, git crea un conjunto de archivos en lugar de solo un archivo por marca. Primero encontré este aspecto confuso.
El comando git add debe seleccionar los archivos en el estado de intercambio, y luego el comando git commit ejecuta consistentemente todos los archivos ingresados en una sola transferencia. La gran ventaja de crear un conjunto de archivos es que hace que el conjunto sea atómico desde el punto de vista de los demás usuarios. No más preocuparse por una actualización que contiene solo algunos de los archivos que otro está revisando actualmente uno tras otro.
Además, un flujo de trabajo de git local simple es fácil: 'git init'; luego ciclo: 'git add' [repeat as needed], 'git commit -m'
Peter Burkimsher dice:
¿Es posible simplemente transferir los cambios a un archivo (por ejemplo, un archivo de texto de diccionario), en lugar de reemplazar el archivo completo?
También agregué accidentalmente muchos archivos enormes a un repositorio de github, y ahora están almacenados en el árbol de objetos y nunca se pueden eliminar.
Honestamente, no me gusta mucho Git por estas razones. Lo uso para comprometerme con github, pero desearía poder enviar mis archivos por FTP allí para que la gente los encuentre. Sin embargo, es el mejor anfitrión gratuito.
Traumflug dice:
Git siempre maneja archivos completos y, en general, eso es algo bueno. Las diferencias se crean solo para su visualización.
Para eliminar archivos más antiguos, use "rebase interactivo". Por ejemplo, "git rebase -i HEAD ~ 10" le brinda una lista de las últimas 10 validaciones y le permite editarlas, eliminarlas o triturarlas (fusionar dos validaciones en una, eliminando la versión intermedia). Después de que los archivos se hayan eliminado en el rap local, presione esa rama con '-f' y también desaparecerá en el rap remoto.
oohal dice:
> Git siempre maneja archivos completos y eso generalmente es algo bueno. Las diferencias se crean solo para su visualización.
¿Estás seguro de eso? Hasta donde yo sé, una gran parte de lo que hace que git funcione es que simplemente mantiene las diferencias. Los archivos completos se guardan solo cuando detecta que el archivo se ha reescrito (casi) por completo.
Traumflug dice:
> Uh, ¿estás seguro de eso?
Si.
jcamdr dice:
Así es. Y esa es exactamente la razón por la que git es bastante resistente a la pérdida de datos. Si elimina las referencias a cualquier versión intermedia de su árbol, solo se elimina la referencia, no el directorio real hasta que optimice su repositorio. Y debido a que solo necesita el hash del contenido para acceder a él, solo lo necesita para recuperar las referencias eliminadas, incluido todo el contenido asociado.
Traumflug dice:
Se sobrepasa un poder subestimado en gran medida de Git. Para fusionar dos ramas de desarrollo con sistemas de control de versiones anteriores, solo se pueden fusionar y esperar resolver todos los conflictos correctamente.
Git también puede fusionarse, pero esta debería ser una estrategia del pasado. Rebasar a los afiliados antes de unirse a ellos es una estrategia mucho más segura para obtener buenos resultados. Otra estrategia es valorar una elección transfiriendo de una rama a otra, esencialmente repitiendo la historia de esa otra rama, revisando el resultado después de cada paso.
Con ambas estrategias, los conflictos se pueden abordar en piezas mucho más pequeñas y atómicas, facilitando tales fusiones. Apenas esta semana logré unir dos sucursales que inicialmente tenían una diferencia de 750.000 líneas. ¿Resolver tal diferencia con una sola fusión? Ninguna posibilidad. Al anular con pequeños pasos, Git resolvió la mayoría de ellos automáticamente.
La charla de Git sobre esto es "trabajar con ramas temáticas". Rebase y cherry son control de versiones de próxima generación.
jerga dice:
una cosa esa debe aprender con git y rápido, es cómo efectuar transferencias aisladas y bien formadas. Una vez que esa práctica se profundiza, trabajar con git es muy fácil. Trate el código como espaguetis y tendrá un viaje rocoso ...
Hal H dice:
¿Podrías hacer uno de estos para Mercurial? Me pregunto por qué “perdió” alguno cuando algunos proyectos lo usaron (Mozilla fue uno, si mal no recuerdo). Git tenía el núcleo, por lo que obtuvo muchos programas automáticamente y luego sucedió el día humano en GitHub y eso es todo lo que escribió, pero me pregunto por qué la gente todavía lo elige hoy que otros.
Don Wills dice:
Aquí hay un buen resumen de por qué Facebook eligió Mercurial.
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
nitePhyyre dice:
tl; versión dr: Ambos eran desagradables, pero Mercurial parecía más fácil de reescribir, por lo que Facebook fue con ellos y lo reescribió. : D
Evert dice:
¿No se menciona Plastic SCM?
DVD completos con interfaz de usuario fácil de entender, buena integración de estudio visual. Y funciona con git, por lo que no tengo que aprender otra herramienta para varios proyectos.
Tampoco es caro
..Jan Hieber dice:
¡Su nombre es Linus, no Linux!
Amigo dice:
Camarada aquí de nuevo, aproximadamente un año después. Nuevamente, cometí un error en la confirmación, intenté revertir y perdí todos mis cambios, ¡y esto usa Github Desktop! Este puede ser el décimo aniversario de mi exposición a git, y no estoy más cerca de entenderlo. Cada vez que necesito hacer algo más que los cuatro pasos habituales, me equivoco. Todo lo que hago para arreglarlo, lo cago aún más.
No soy una persona estúpida, escribí una falla tolerante del sistema operativo en tiempo real en tiempo real, un editor WYSIWYG en C / C ++ y un sistema OLAP distribuido y multiproceso en medios idiomas. Pero he llegado a la conclusión de que soy fundamentalmente incapaz de entender git, y siempre dependeré de las copias de seguridad completas locales y la clonación en lugar de todo lo que git intentará hacer.
