Hogar › Internet › Conceptos básicos de trabajar con git. Usar yesos en lugar de parches. Cambiar entre sucursales

Conceptos básicos de trabajar con git. Usar yesos en lugar de parches. Cambiar entre sucursales

Trabajar con repositorios Git

¿Por qué Git?

Respuesta corta: porque no hay retrasos al trabajar con un sistema de control de versiones.

Git almacena todo localmente, incluido el historial, las ramas, las confirmaciones y le permite cambiar entre todo sin acceder a la red.

GIT facilita el trabajo con ramas sin cambiar el diseño del repositorio, y la vista de árbol de cambios le permite ver qué proviene de cada rama.

Información general sobre Git

Puede leer más sobre cómo trabajar con Git y qué es en el Libro de Git en http://book.git-scm.com/

En el VCS (Sistema de control de versiones) clásico (CVS, SVN), la copia de trabajo almacena el estado actual del repositorio y una copia base de la revisión actual. Todas las revisiones se almacenan en el servidor en forma de cambios con respecto a la anterior, o en la forma copias completas cada revisión con cálculo de la diferencia bajo pedido. Todas las revisiones están numeradas en orden comenzando desde la primera.
En el caso de CVS, los cambios se almacenan y numeran para cada archivo de forma independiente; en el caso de SVN, los cambios en el repositorio se numeran.
Dado que SVN sólo almacena cambios en todo el repositorio, las ramas se implementan mediante una organización especial de archivos en el repositorio. Clásicamente, esto es /trunk/ para último código, /rama/algúnnombre/ para ramas. Para crear una rama, se realiza una copia de /trunk/ en /branch/somename/, en la que el desarrollador ya está trabajando.
Al mismo tiempo, con cada confirmación, hay una llamada al repositorio central, para guardar el cambio, los scripts se procesan en el servidor, los cambios se numeran continuamente, una solicitud de historial también requiere una llamada al servidor, etc.

Git pertenece a la clase DVCS (Sistema de control de versiones distribuido). Al mismo tiempo, la copia de trabajo contiene todos los commits, historial, ramas, todo lo necesario para el desarrollo sin acceder a ningún servidor. Para sincronizar cambios entre diferentes copias del repositorio, en momento correcto pull se realiza para copiar los cambios del repositorio remoto a usted mismo, o push se realiza para copiar cambios locales a un repositorio remoto. En el caso de Git, cada confirmación tiene una identificación única en forma de hash que contiene todos los archivos relacionados con ella.

Cada confirmación tiene una confirmación principal y posiblemente una confirmación de fuente de fusión. Por tanto, las confirmaciones son un árbol de colecciones de archivos. Una "rama" es un puntero a una confirmación. Por lo tanto, para crear una rama, sólo necesita nombrar una confirmación. Para fusionar dos ramas, una de las cuales comienza al final de la otra, simplemente puede mover el puntero de la segunda rama a la nueva confirmación (esto se llama avance rápido).

Para mantener una rama maestra "plana", se utiliza la técnica de rebasar las ramas antes de fusionarlas y fusionarlas sin avance rápido.

Rebase significa cambiar el padre de una rama a una nueva confirmación. Cuando cambia la base, todos los cambios realizados en una rama determinada se revierten y se guardan como cambios realizados en cada confirmación; después de lo cual el puntero de la rama se mueve al nuevo comienzo y los cambios se le aplican secuencialmente. Si no hay conflictos, los cambios se aplican automáticamente, después de lo cual la rama es un conjunto de cambios relativos al nuevo comienzo.

Si ahora fusionamos esta rama con la original, el puntero principal de la rama original simplemente se moverá a una nueva ubicación y perderemos información de que la nueva rama existió. Es por eso que se utiliza la fusión sin avance rápido. En este caso, incluso si una nueva rama comienza desde el final de la anterior, se crea una confirmación de fusión especial que contiene información de que la rama actual se está fusionando con una adicional. este punto.

Algoritmo para trabajar en una tarea.

El algoritmo estándar para trabajar en cualquier tarea tiene este aspecto:

Se crea una rama basada en última copia rama maestra. El nombre de la nueva rama contiene la clase de tarea, breve descripción, número de tarea en BT. Por ejemplo característica/sessions_add_datetime_filter.5503
Todos los cambios se realizan dentro de esta rama. Para cada cambio lógico atómico (por ejemplo, se agregó un complemento, se confirmó la adición; se corrigió la API de una función en todos los lugares, se confirmó, etc.), se crea su propia confirmación. Esto le permite separar los cambios que se realizaron, lo que facilita la lectura y la verificación de errores en el proceso de desarrollo.
Una vez finalizado y depurado el código de la rama, se confirman todos los cambios, esta rama se reestructura en relación con último maestro, y se envía al repositorio central.
Una segunda persona que trabaja en el mismo proyecto se queda con el repositorio central. Si ya ha mirado, elimina su copia local de la rama y luego cambia a la rama especificada. Lee el código, verifica su funcionalidad y luego lo envía para revisión si se encuentran problemas, o lo vuelve a basar sobre el maestro y fusiona la rama con el maestro.
Después de fusionarse con el maestro, el revisor empuja nuevo maestro al repositorio central, elimina la rama de tareas local, envía al maestro para eliminar la rama de tareas.
El desarrollador elimina la rama local de la tarea después de cerrarla y transferir los cambios al maestro.

Reglas para mantener compromisos limpios

Todas las confirmaciones que van a la rama central deben seguir las siguientes reglas:

El desarrollador debe estar registrado como autor: nombre, apellido, correo electrónico del trabajo.
El texto del comentario debe contener una breve descripción del cambio. Para proyectos extranjeros, la descripción debe estar en Inglés, para proyectos de brunch rusos es aceptable comentar en ruso.
Una confirmación no debe contener archivos que no estén relacionados con cambios. Si su IDE, sistema operativo, algún complemento para cualquier software utilizado durante el desarrollo crea archivos tecnicos, agréguelos a .gitignore, no los agregue a la confirmación o elimínelos antes de la confirmación.
El compromiso no debe agregar/eliminar lineas vacias, cambiar espacios a tabulaciones y viceversa, cambiar el número de espacios, etc. en cualquier lugar, excepto en casos relacionados con la esencia del compromiso. Es decir, esto es normal al refactorizar, pero si su editor cambió los espacios en todo el archivo a pestañas o viceversa, cambie la configuración del editor o devuelva todo a "como estaba" antes de confirmar.
Estilo código fuente y la sangría debe coincidir con el texto que la rodea. Es decir, si se utilizan tabulaciones para sangrar en todo el archivo, no debe insertar otra mayúscula llena de espacios.
Minimizar los conflictos. Al agregar código, debe intentar formatear el código de manera que modificarlo genere un mínimo de conflictos de fusión.

Trabajando bajo Windows

La forma más cómoda de trabajar con Git en Windows es utilizar TortoiseGit. Sin embargo, debes saber que para 2017 hay más herramienta útil- SmartGit.

Preparándose para el trabajo

Instalar masilla desde la página. http://www.chiark.greenend.org.uk/~sgtatham/putty/
lo mejor es poner paquete completo, con todos los programas. Necesitará al menos plink, puttygen.
Instalando msysGit desde el proyecto http://code.google.com/p/msysgit/
Seleccione las opciones al instalar "Agregar "Git Bash aquí"", "Ejecutar Git desde el símbolo del sistema de Windows", "Usar finales de línea de estilo Windows", cuando se le solicite, proporcione la ruta a plink.exe
Instalando TortoiseGit desde el proyecto http://code.google.com/p/tortoisegit/
Después de la instalación, vaya a TortoiseGit → Configuración → Git → Config, asegúrese de que la ruta a msysgit esté configurada y que las opciones AutoCRLF y SafeCRLF estén configuradas, y que el nombre, apellido y correo electrónico del desarrollador estén configurados.
Usando puttygen, se crea un par de claves pública y privada.
La clave pública se envía a los administradores para que la agreguen al acceso de los repositorios y servidores.
La clave privada se agrega a pagent mediante un clic. clic derecho→ agregar clave.

Obteniendo el repositorio

En la carpeta donde se ubicarán todos los proyectos de trabajo, haga clic en
Haga clic derecho → TortoiseGit → Clonar, ingrese la dirección del repositorio central
ssh://git@ SERVIDOR: PUERTO/REPOSITORIO.git
En el campo "Cargar clave de Putty", seleccione la ruta a la clave privada.

Cuando trabaje, use cualquiera utilidades de consola, similar a Linux, o interfaz gráfica.

Procedimientos operativos estándar

“Comenzar a trabajar en una tarea”

,
Rama: maestro
Menú → TortoiseGit → Tirar
Menú → TortoiseGit → Crear rama
Nombre Sucursal: nombre de la nueva sucursal
Base en: HEAD (maestro)
[x] Cambiar a nueva sucursal
“Encomienda otro trabajo”

Menú → Git commit -> “nombre de rama”
Marcar archivos solo necesarios para esta confirmación específica
Asegúrese de hacer clic en "Ver parche" y asegurarse
de acuerdo con las reglas para mantener compromisos limpios
En el mensaje, ingrese una descripción del cambio que coincida con las reglas.
Menú → TortoiseGit → Empujar
En Local, primero seleccionamos master, luego nuestra rama actual.
El control remoto se completa automáticamente.
El nombre de la sucursal remota debe ser idéntico al local.
"Rebase en el Maestro"
Se realiza antes de cargar una tarea completada en el servidor, cuando ya se han confirmado todos los cambios.
Menú → Sincronización de Git
Sucursal local: maestro
Rama remota: maestra
Flecha hacia abajo hacia la derecha en el primer botón (Extraer de forma predeterminada), Obtener
Menú → TortoiseGit → *Rebase
Sucursal: sucursal actual
Upstream: maestro
Si hay conflictos, resuélvalos a través de la pestaña "Archivo de conflictos"
Para elegir, haga clic derecho en el archivo, utilidad
Editar conflictos: le permite seleccionar para cada discrepancia
usar qué versión de bloque
Resolver conflictos utilizando
suyo – use la versión del asistente
mío: usa la versión actual de la rama
Abrir: abrir en un editor y editar manualmente
Después de arreglarlo, resuelve
Después de corregir todos los conflictos, haga clic en Confirmar
Después de la rebase, haga clic en Listo
"Ahorro a corto plazo del cambio de estado"

Menú → TortoiseGit → Guardar alijo
Después de esto, el árbol está limpio, puede cambiar a otra rama/maestro y así sucesivamente, trabajar y luego restaurar el estado si vuelve a la rama de trabajo y hace
Menú → TortoiseGit → Stash Pop
"Retención a largo plazo del estado de cambio"

Menú → Git Commit -> “rama”
Marcar todos los cambios (Seleccionar/Deseleccionar todo)
En el texto del mensaje escriba "Compromiso parcial"
Posteriormente, para volver al mismo estado que antes, cambiamos a la rama de trabajo y hacemos
Menú → TortoiseGit → Mostrar registro
Seleccione la confirmación que va en el árbol inmediatamente antes de "Compromiso parcial"
Haga clic derecho → Restablecer<ветка>a esto
Tipo de reinicio: Mixto
"Revisión del hilo"

Menú → TortoiseGit → Cambiar/Pagar
Rama: maestro
Menú → TortoiseGit → Tirar
Menú → TortoiseGit → Cambiar/Pagar
Rama: remotos/origen/rama necesaria
[x] Crear nueva rama: rama deseada
[x]Fuerza
[x] Pista
[x] Anular rama si existe
Menú → TortoiseGit → *Rebase
Sucursal: sucursal necesaria
Upstream: maestro
La rama debe estar "actualizada" o se cambiará de base sin conflictos.
== Analizamos los cambios viendo el registro de cambios a través de
Menú → TortoiseGit → Mostrar registro
y mira los cambios desde el maestro hasta el último
== Veamos cambio general con respecto al maestro
Menú → TortoiseGit → Diferencia con la versión anterior
Versión 1: CABEZA
Versión 2: maestro
== si todo está bien, lo hacemos
Menú → TortoiseGit → Cambiar/Pagar
Rama: maestro
Menú → TortoiseGit → Fusionar
De: sucursal necesaria
[x] Sin avance rápido
No editamos el mensaje.
Menú → TortoiseGit → Empujar
Y eliminar ramas:
Shift + Menú → TortoiseGit → Referencia del navegador
en el árbol de la izquierda Referencias => cabezas => busque la rama, haga clic derecho, Eliminar rama
en el árbol de la izquierda controles remotos => origen => busque la rama, haga clic derecho,
Eliminar rama remota

Trabajando bajo Linux

Preparándose para el trabajo

Los paquetes del sistema ssh-client y git están instalados
Se crea una clave privada:
ssh-keygen -t dsa -C "Iván Petrov "
Se configuran el nombre completo y el correo electrónico del autor:
git config --global nombre.usuario "Ivan Petrov"
git config --global usuario.correo electrónico trabajo@correo"
El archivo ~/.ssh/id_dsa.pub se envía al administrador para registrar el acceso a los repositorios y servidores.

Obteniendo el repositorio

Vaya al directorio de trabajo y ejecute

git clone ssh://git@SERVIDOR:PUERTO/REPOSITORIO.git

Funciones principales utilizadas

Actualizando la rama actual desde el repositorio central:
git tirar
Enviar la rama actual al repositorio central:
nombre de rama de origen de git push
Cambiando a alguna sucursal:
nombre de sucursal de git checkout
Si cambia a una sucursal que aún no está en el repositorio local, se creará una sucursal local que estará vinculada a la remota.
Crear una nueva rama basada en la actual
git checkout -b nombre de sucursal
Eliminando ramas
git rama -d nombre de rama == eliminar una rama local ya fusionada
git rama -D nombre de rama == eliminación forzada sucursal local
git push origin:branchname == eliminar una rama del repositorio central
Fusionar una sucursal con la actual
git merge --no-ff nombre de rama
Vea qué archivos se han modificado en el directorio actual:
estado de git
Ver cambios actuales:
diferencia git
Guardar los cambios actuales:
git agregar nombres de archivos== agregar archivos/directorios modificados/creados
nombres de archivos git rm == agregar eliminar archivo/directorio
git commit == guarda los cambios agregados. Se abrirá un editor para ingresar un comentario para la confirmación.
git commit -a == guarda todos los cambios agregados y todos los archivos modificados. Le permite guardar todos los cambios si no se agregaron archivos.

Procedimientos operativos estándar

"Empiece a trabajar en una tarea".
Se realiza antes de comenzar a trabajar en una tarea. El árbol debe permanecer sin cambios.
maestro de pago de git
git tirar
git checkout -b nombre de sucursal
"Encomienda otro trabajo".
Se realiza después de realizar un determinado cambio, cuya esencia es holística.
# comprobar qué archivos han cambiado hasta ahora
# eliminar si algo está completamente fuera de lugar
estado de git
# mira el texto de los cambios para comprobar su cumplimiento.
# reglas para mantener confirmaciones limpias. Retírelo si entra algún residuo.
diferencia git
# si algún archivo no debe confirmarse (por ejemplo,
# se refiere a otro cambio atómico.)
# luego marque solo aquellos archivos cuyos cambios deben guardarse
git agregar...
git rm...
# ahorrar. -m se puede omitir, luego comentar a través del editor
git commit -m "Algún mensaje de confirmación"
# si todo está encendido momento actual los cambios creados deben guardarse, luego
# usa git add para agregar nuevos archivos y guarda todo lo demás usando
git commit -a -m "Algún mensaje de confirmación"
"Enviar una rama al repositorio central"
Se realiza después de finalizar el trabajo, o al final de cada día (para que haya una copia de seguridad en el servidor), o si necesita mostrar algunos cambios a un colega.
nombre de rama de origen de git push
No debes presionar después de cada confirmación, ya que esto requerirá acceso antes servidor remoto y, en consecuencia, pérdida de tiempo.
"Rebase en relación con el maestro".
Ejecutado antes de cargar una tarea completada en el servidor, cuando ya se han confirmado todos los cambios:
maestro de pago de git
git tirar
nombre de sucursal de git checkout
maestro de rebase de git
Si surgen conflictos, es necesario:
(*)
git status == busca archivos que tengan conflictos no resueltos.
Editamos el primer archivo con el conflicto: encontramos en él “<<<<<». То, что между <<<<< и ==== – содержит копию текста из master ветки, то что между ===== и >>>>> contiene texto de nuestro hilo. Necesitamos dejar una única versión en este punto, que contenga el código común tanto del maestro como de nuestra rama.
git agregar archivo_modificado
ir a (*)
Después de corregir los conflictos en todos los archivos, ejecute
git rebase --continuar
Si los conflictos son incompatibles con una mayor continuación de la rebase
git rebase --abort == aborta la rebase y revierte la rama al original
estado (antes del inicio de la rebase)
Después del rebase, actualizamos el estado de la sucursal en el repositorio central.
git push origen nombre de rama -f
"Persistencia a corto plazo de un estado de cambio".
Se realiza si necesita pausar temporalmente el trabajo en la rama actual por un período breve (por ejemplo, para una revisión o para completar alguna tarea de dos minutos).
git alijo guardar
Después de esto, el árbol está limpio, puede cambiar a otra rama/maestro y así sucesivamente, trabajar y luego restaurar el estado usando
git checkout rama original
git alijo pop
Restaurando así el estado de cambio.
“Mantenimiento a largo plazo de un estado de cambio”.
Se realiza al final de la jornada laboral para que se respalden incluso los cambios parciales; o, si es necesario, pase urgentemente a resolver otra tarea, lo que puede llevar mucho más de 5 a 10 minutos.
git agregar.
git commit -m "Compromiso parcial"
nombre de rama de origen de git push
Posteriormente, para volver al mismo estado que antes, ejecute
nombre de sucursal de git checkout
git reset --soft CABEZA^
git restablecer CABEZA.

¡Importante! Después de dicho procedimiento de guardar/restaurar, la próxima vez
nombre de rama de origen de git push
Se emitirá una advertencia sobre el cambio inconsistente. Para forzar el envío de cambios, debe agregar la opción -f.
git push -f origen nombre de rama
Importante: no siempre debes agregar -f, ya que esto te evitará errores tipográficos accidentales en el nombre de la rama, por ejemplo.
"Revisión del hilo".
Realizado en un árbol limpio, guarde temporalmente los cambios según el punto 5, si es necesario.
maestro de pago de git
git tirar
git rama -D nombre de rama
nombre de sucursal de git checkout
git rebase master == la rama debe superponerse sin conflictos
git diff master == estudiar la diferencia con el maestro o una diferencia general, o
git log master..HEAD == ver qué confirmaciones hubo entre la rama maestra y la actual
Si todo está bien hacemos:

maestro de pago de git
git merge --no-ff nombre de rama
maestro de origen de git push
origen de git push: nombre de rama
git rama -d nombre de rama

Es natural que la gente se resista al cambio. Si no conoció Git cuando comenzó a trabajar con sistemas de control de versiones, probablemente se sienta más cómodo con Subversion (SVN).

La gente suele decir que Git es demasiado difícil para los principiantes. Sin embargo, discrepo en esto.

En este tutorial te mostraré cómo usar Git en tus proyectos. Digamos que estás creando un proyecto desde cero y quieres administrarlo usando Git. Revisar la lista de comandos básicos le dará una idea de cómo alojar su código en la nube usando GitHub.

En este artículo, hablaremos sobre los conceptos básicos de Git: cómo inicializar sus proyectos, cómo administrar archivos nuevos y existentes y cómo almacenar su código en la nube.

No tocaremos las partes relativamente complejas de Git, como la ramificación, ya que este tutorial está destinado a principiantes.

Instalación de Git

En el sitio web oficial de Git hay información detallada sobre instalarlo en Linux, Mac y Windows. En nuestro caso, usaremos Ubuntu 13.04 para fines de demostración, donde instalaremos Git usando apt-get:

sudo apt-get instalar git

Configuración inicial

Creemos un directorio dentro del cual trabajaremos. Alternativamente, puedes usar Git para administrar uno de tus proyectos existentes; en este caso no necesitarás crear un directorio de demostración como el siguiente:

mkdir mi_git_project cd mi_git_project

El primer paso es inicializar Git en el directorio. Esto se puede hacer usando el comando init, que crea un directorio .git que contiene toda la información relacionada con Git para su proyecto.

git config --global usuario.nombre "Shaumik" git config --global usuario.correo electrónico " [correo electrónico protegido]" git config --global color.ui "automático"

Es importante tener en cuenta que si no proporciona su nombre y dirección de correo electrónico, se utilizarán los valores predeterminados. En nuestro caso, los valores predeterminados serían el nombre de usuario donny y la dirección de correo electrónico donny@ubuntu.

También configuramos el color de la interfaz de usuario en auto, lo que hará que la salida de los comandos de Git esté codificada por colores.

El prefijo --global antes de los comandos es para evitar tener que ingresar estos comandos de configuración la próxima vez que ejecutemos un proyecto Git en nuestro sistema.

Preparando archivos para confirmar

El siguiente paso es crear los archivos en el directorio. Puedes utilizar, por ejemplo, el editor de texto Vim. Tenga en cuenta que si va a agregar Git a un directorio ya existente, no necesita realizar este paso:

Verificar el estado del repositorio

Ahora que tenemos algunos archivos en nuestro repositorio, echemos un vistazo a cómo los maneja Git. Para verificar el estado actual del repositorio, debe usar el comando git status:

Agregar archivos a Git para seguimiento

No tenemos ningún archivo para rastrear con Git en este momento. Necesitamos agregar archivos específicamente a Git para decirle a Git qué rastrear.

Agregue archivos usando el comando agregar:

Al verificar nuevamente el estado del repositorio, podemos ver que se ha agregado un archivo:

Para agregar varios archivos, puede utilizar la siguiente entrada de comando (tenga en cuenta que agregamos un archivo más con fines de demostración):

git agregar miarchivo2 miarchivo3

Puedes usar git add de forma recursiva, pero ten cuidado con este comando. Hay ciertos archivos (como archivos compilados) que normalmente se almacenan fuera de un repositorio de Git.

Si usa el comando agregar de forma recursiva, agregará todos esos archivos si existen en su repositorio.

Eliminar archivos

¡Pero ejecutar un simple comando git rm no solo eliminará el archivo de Git, sino también de su sistema de archivos local! A

Git ha dejado de rastrear el archivo, pero el archivo permanece en su sistema local; ejecute el siguiente comando:

git rm --en caché

Confirmar cambios

Una vez que haya alojado sus archivos, puede enviarlos a Git. Piensa en una confirmación como capturar un momento específico al que puedes regresar para acceder a tu repositorio en ese punto.

Puede adjuntar un mensaje a cada confirmación, que se agrega usando el prefijo -m:

git commit -m "Mi primer compromiso"

Proporciona mensajes útiles a tus confirmaciones porque esto te ayudará a identificar lo que cambiaste en esa confirmación.

Evite mensajes demasiado generales como " Errores solucionados" Si tiene un rastreador de tareas, puede agregar mensajes como " Error solucionado #234».

Es una buena práctica utilizar el nombre de la rama o el nombre de la función como prefijo del mensaje de confirmación. Por ejemplo, " Gestión de activos: función agregada para generar archivos PDF de activos”es un mensaje significativo.

Git identifica las confirmaciones agregando un número hexadecimal largo a cada confirmación. Como regla general, no es necesario copiar la línea completa; los primeros 5 o 6 caracteres son suficientes para identificar su confirmación.

Tenga en cuenta que en la captura de pantalla nuestra primera confirmación está definida por el código 8dd76fc.

Compromisos adicionales

Ahora cambiemos algunos archivos después de nuestra primera confirmación. Después de cambiarlos, veremos que como resultado de ejecutar el comando git status, Git ha detectado cambios en los archivos que monitorea:

Puede verificar los cambios en los archivos rastreados realizados en la última confirmación usando el comando git diff. Si desea ver los cambios en un archivo específico, use el comando git diff :

Debe agregar estos archivos nuevamente para realizar cambios en los archivos rastreados para la próxima confirmación. Puede agregar todos los archivos rastreados ejecutando el comando:

Puede evitar el uso de este comando usando el prefijo -a al comando git commit, que agregará todos los cambios a los archivos rastreados.

Este proceso, sin embargo, es muy peligroso ya que puede perjudicar el proyecto. Por ejemplo, digamos que abrió un archivo y lo cambió por error.

Si coloca archivos de forma selectiva, notará cambios en cada archivo. Pero si agrega el prefijo -a a su confirmación, todos los archivos se confirmarán y no podrá detectar posibles errores.

Una vez que haya colocado sus archivos, puede comenzar a confirmar. Mencioné que cada confirmación puede tener un mensaje asociado, que ingresamos usando el prefijo -m.

Sin embargo, es posible ingresar un mensaje en varias líneas usando el comando git commit, que abre un formulario de escritura interactivo:

Gestión de proyectos

Para ver el historial de su proyecto, puede ejecutar el siguiente comando:

Esto mostrará el historial completo del proyecto, que es una lista de todas las confirmaciones e información sobre ellas. La información de confirmación incluye el hash de confirmación, el autor, la hora y el mensaje de confirmación. Hay varias opciones para git log que puedes explorar una vez que hayas dominado el concepto de rama en Git.

Para ver información detallada sobre una confirmación específica y los archivos que se cambiaron, ejecute el siguiente comando:

mostrar git

Dónde este es el número hexadecimal asociado con la confirmación. Dado que este tutorial está dirigido a principiantes, no cubriremos cómo volver al estado de una confirmación específica o cómo administrar ramas.

Código de hosting en la nube

Ahora que ha aprendido cómo administrar el código en su sistema, es hora de alojar el código en la nube.

Dado que Git no tiene un servidor central como Subversion, debes agregar cada fuente para interactuar con las demás. Aquí es donde entra en juego el concepto de control remoto. remoto significa la versión remota de su repositorio.

Si desea alojar su código en la nube, puede crear un proyecto en GitHub, GitLab o BitBucket e insertar su código existente en un repositorio.

Esperamos que sepas qué sistema operativo tienes. Y advertiremos inmediatamente a los recién llegados: no confundan git y GitHub: son cosas diferentes. Estamos interesados en git, y GitHub (o servicios similares como Bitbucket o GitLab) básicamente aloja proyectos que utilizan git.

Repositorio

Entonces, ahora tienes git. Ahora necesitamos crear una tienda de versiones para ello. Recuerde, este almacenamiento se llama repositorio (repositorio en inglés)- si es necesario, puedes insertar esta palabra en algún lugar. Dependiendo del shell que tengas, el comando apropiado crear un nuevo directorio, ábrelo(en la línea de comando, también conocida como shell, no Explorer ni nada por el estilo) y hacer:

inicio de git

Eso es todo, el repositorio local se ha creado en esta carpeta. Lo que actualmente está almacenado aquí será una copia de seguridad, por lo que para no estropearlo, crearemos una copia de trabajo. (Consulta en inglés) versión local:

clon de git

¿Dónde está la ruta al repositorio clonado? Ahora estamos viendo el caso en el que crea una copia de trabajo de su propio repositorio, por lo que aquí debe especificar la ruta al directorio para el que ejecutamos git init.

Pero si eres un tipo genial y ya estás trabajando con un servidor remoto, entonces este comando será perfecto para ti:

Git clone nombre de usuario@host:/ruta/al/repositorio

bosque git

Un poco de teoría. Git opera gestionando tres estructuras llamadas árboles. El primero es el directorio de trabajo, almacena los archivos con los que estás trabajando en este momento. Bueno, está funcionando, eso es lógico. El segundo es Index, una especie de punto de control que te permite realizar cambios sin estropear nada. Y el tercero es HEAD, que apunta al último compromiso que hiciste. (Para que no te confundas con la terminología: confirmar (compromiso en inglés)- esto es guardar el estado del proyecto en el repositorio. En resumen, considérelo una nueva versión).

Entonces, para no perderse en estos tres pinos, recuerde dos comandos interesantes: agregar y confirmar. Permitirán que su trabajo deambule silenciosamente por Git, guardándolo donde sea necesario. Si se le ocurre algo brillante e inmediatamente realiza un cambio en la copia de trabajo del proyecto, ¡no se apresure a realizarlo de inmediato! Primero pruébalo en Index, para hacer esto ejecuta:

Git agregar [nombre de archivo]

si realizó un cambio en un solo archivo, o

Git agregar *

Si trabajabas duro, cambiabas varias fuentes a la vez. ¿Los cambios son positivos? ¿Lo probaste bien? Entonces más bien comprometerse:

Git commit -m "Mensaje de confirmación"

Eres, por supuesto, un mal tipo y no dejas comentarios en tu código. Pero git es un asunto diferente. No seas perezoso en dejar mensajes explicativos: ten la seguridad de que tendrás suficientes problemas además de descubrir qué ha cambiado en esta confirmación en comparación con la versión anterior.

Por cierto, aquí tenéis una imagen explicativa:

Los archivos ahora están firmemente establecidos en el HEAD de su copia local de trabajo. No puedes sacarlos de allí, pero todavía no están en tu repositorio remoto. ¡Pongámoslos allí también! Usar:

Maestro de origen de git push

Simplemente en lugar de master, escribe el nombre de la rama deseada. Ah, sí, todavía no sabes qué ramas son. Bien, recuerda este lugar por ahora y cuando leas sobre la bifurcación, vuelve aquí.

Oh, sí, para los tipos geniales que trabajan con servidores (es apropiado hablar de GitHub, por ejemplo), el comando será así:

Git agregar origen remoto [servidor]

Derivación

En ingles esto se llama derivación- Es mejor profundizar en este tema y leer con más detalle sobre la ramificación, simplemente se lo presentaré. Derivación se utiliza para el desarrollo simultáneo e independiente de diferentes funciones (bueno, o acumulación de más errores, porque hay más código fuente). La rama principal es maestro- aparece al crear un repositorio. Otras ramas son sandboxes, cuando hayas jugado suficientes, fusionalas en un solo todo en master. Ahora explicaré cómo se hace esto.

Creando una nueva sucursal

Entonces decidiste trabajar en alguna característica nueva. Crea una nueva rama para ello:

Git pago -b [nueva_rama]

Oh, sí, tu imaginación probablemente esté funcionando al máximo, pero moderala cuando se trata de nombrar ramas: solo puedes nombrar una rama con un nombre que sea aceptable para una variable en tu idioma favorito.

Cambiar entre sucursales

¿Debería tomarme un descanso del trabajo en esta función y cambiar a otra rama? Utilice (si está trabajando con un repositorio local, no necesita especificar su nombre):

Git checkout [repositorio]/[sucursal]

Bueno, si no quieres trabajar con él en absoluto, elimínalo por completo:

rama de git -d [rama]

Puedes hacer cualquier obscenidad con tu rama: nadie la verá hasta que la envíes al repositorio remoto con el comando:

Origen de Git Push [rama]

Fusionando sucursales

Para fusionar una rama con la que está trabajando actualmente, use:

fusión de Git [rama]

Pero, por supuesto, todo esto genera conflictos. Y este es un verdadero problema. Intente arreglar todo manualmente directamente en el directorio del repositorio. En ese momento, no olvides marcar que los “filtraste”:

Git agregar [nombre de archivo]

Por cierto, se pueden comparar las ramas:

Git diff [una_branch] [otra_branch]

Entonces, ahora tomemos medidas más decisivas. Actualizaremos nuestro repositorio de acuerdo con la última confirmación. Es muy fácil de hacer (pero no es muy fácil volver a colocarlo, así que piénsalo dos veces antes de cometer este terrible error):

git tirar

Por supuesto, entiendo que eres demasiado genial para dejar notas para el futuro (mantén todo en tu cabeza), pero aun así te recomiendo que dejes etiquetas. Y este no es mi invento, mucha gente hace esto:

Etiqueta de Git [primeros_diez_caracteres del_compromiso_correspondiente]

¿No sabes cuáles son los primeros caracteres del nombre de la confirmación deseada? No hay problema, mira el historial del repositorio: su registro:

Hay un montón de parámetros diferentes para usar este útil artilugio, continúe y búsquelos en Google usted mismo. Ah, sí, por cierto, ya escribimos sobre eso una vez.

Un sistema de control de versiones, o VCS, puede facilitar enormemente el trabajo de los desarrolladores que intentan analizar cambios y contribuciones al código compartido. En pocas palabras, un sistema de control de versiones es un elemento clave en la gestión de personalizaciones de software que satisfacen las necesidades de un proyecto. Los VCS brindan la capacidad de asignar valores alfabéticos o numéricos a cambios/revisiones/actualizaciones específicas. También pueden proporcionar información sobre marcas de tiempo y la identificación de la persona que realizó los cambios. En esta guía, le informaremos sobre el sistema de control de versiones más utilizado: GIT. Aprenderás qué es GIT y qué ventajas tiene respecto a otros VCS, y también hablaremos sobre la instalación de GIT en diferentes sistemas y su correcto uso.

En 2005, Linus Torvalds (el hombre conocido por ser el hombre detrás de la creación del kernel del sistema operativo Linux) desarrolló GIT para el control de versiones del kernel de Linux, pero un poco más tarde fue apoyado por otra persona, el ingeniero de software japonés Junio Hamano. Hoy en día, GIT es uno de los sistemas de control de versiones de código abierto más famosos, en el que confían millones de proyectos en todo el mundo (incluidos proyectos comerciales y gratuitos). GIT es un software completamente gratuito que admite muchos sistemas operativos como Mac, Linux, Windows y Solaris. Puede descargar las distribuciones correspondientes desde el sitio web oficial de GIT. Aquí hay algunas funciones de GIT dignas de mención:

GIT, un sistema de control de versiones distribuido, sigue el principio de igual a igual: de igual a igual(peer to peer) a diferencia de otros sistemas como Subversion (SVN), que se basa en el cliente-servidor(cliente-servidor).
GIT permite a los desarrolladores tener muchas ramas de código completamente independientes. Crear, eliminar y fusionar estas ramas se realiza sin problemas y requiere mucho tiempo.
En GIT, todas las operaciones son atómicas; esto significa que cualquier acción puede ser completamente exitosa o fracasar (sin ningún cambio). Esto es realmente importante porque en algunos sistemas de control de versiones (como CVS), donde las acciones no son atómicas, algunas operaciones pendientes en todo el repositorio pueden dejarlo en un estado inestable.
A diferencia de otros VCS como SVN o CVS donde los metadatos se almacenan en carpetas ocultas (.cvs, .svn, etc.), en GIT todos los datos se encuentran en directorios .git.
Utiliza un modelo de datos que ayuda a garantizar la integridad criptográfica de todo lo presente en el repositorio. Cada vez que se agregan o confirman archivos, se generan sus sumas de verificación; un proceso similar ocurre cuando se extraen.
Otra característica excelente presente en GIT es su índice. Dentro del índice, los desarrolladores pueden formatear las confirmaciones y revisarlas antes de aplicarlas.

Entonces, quizás hayamos respondido a la pregunta "¿Qué es GIT?".

Es bastante fácil de usar. Para comenzar, puede crear un repositorio nuevo o agregar uno existente. Una vez instalado, el comando git-init le ayudará a configurar un nuevo repositorio, o el comando git clone le ayudará a configurar un usuario para una copia en ejecución del repositorio local.

Paso 1: instalar GIT

Esta parte de la guía le mostrará las formas más sencillas de instalar GIT en diferentes sistemas operativos:

Opción 1: instalar GIT en Windows

Instalar GIT en Windows es tan fácil como instalar cualquier otra aplicación; descargue el instalador y ejecútelo. Siga estos pasos para instalar GIT en Windows:

Visite este sitio y descargue el instalador GIT para Windows.
Después de la descarga, inicie la instalación haciendo doble clic con el mouse. Sigue las instrucciones en pantalla, sigue presionando Próximo y finalmente Finalizar (Finalizar) para completar la instalación exitosamente.

Inicie el símbolo del sistema e ingrese los siguientes comandos en la terminal:

¡NOTA! No olvides cambiar Juan Smith Y [correo electrónico protegido] a sus propios datos personales. Cualquier confirmación creada posteriormente se asociará con estos datos.

Eso es todo lo que necesitas para instalar GIT en Windows.

Opción 2: instalar GIT en Mac

Hay muchas formas de instalar GIT en Mac, e incluso existe la posibilidad de que GIT ya esté instalado en su computadora. Si tiene XCode instalado; Ejecute el siguiente comando en la terminal para verificar:

Git-versión

Si su resultado es similar a esta versión git 2.7.0 (Apple Git-66), entonces puede comenzar a trabajar con GIT de manera segura; de lo contrario, siga estos pasos:

Visite y descargue el último instalador para Mac.
Siga las instrucciones del instalador y complete la instalación.

Utilice el comando git –version nuevamente para confirmar que la instalación se realizó correctamente.

git config --global usuario.nombre "John Smith" git config --global usuario.correo electrónico " [correo electrónico protegido]"

¡NOTA! No olvides cambiar Juan Smith Y [correo electrónico protegido]

Opción 3: instalar GIT en Linux

Si es un usuario de Linux, debería poder instalar programas y paquetes en su computadora usando los simples comandos apt-get o yum install; Bueno, instalar GIT no es diferente:

Para usuarios de Debian/Ubuntu (apt-get):

Abra una terminal y ejecute el siguiente comando:

sudo apt-get actualizar sudo apt-get instalar git

Verifique que la instalación sea correcta usando el comando git –version.
Ejecute los siguientes comandos en una terminal para configurar su nombre de usuario y dirección de correo electrónico, que se asociarán con su cuenta GIT:

git config --global usuario.nombre "John Smith" git config --global usuario.correo electrónico " [correo electrónico protegido]"

¡NOTA! No olvides cambiar Juan Smith Y [correo electrónico protegido] a tus propios datos. Cualquier confirmación futura creada estará vinculada a ellos.

Fedora (mmm/dnf):

Puede obtener paquetes GIT usando yum y dnf.

Abra una terminal y ejecute los siguientes comandos:

sudo dnf instalar git sudo yum instalar git

Verifique que la instalación sea correcta usando git –version.
Ejecute los siguientes comandos en una terminal para configurar su nombre de usuario y dirección de correo electrónico, que se asociarán con su cuenta GIT:

git config --global usuario.nombre "John Smith" git config --global usuario.correo electrónico " [correo electrónico protegido]"

¡NOTA! No olvides cambiar Juan Smith Y [correo electrónico protegido] a tus propios datos. Cualquier confirmación futura creada estará vinculada a ellos.

Paso 2: usar GIT

Ahora que GIT está configurado en su dispositivo Windows/Mac/Linux, aprendamos los conceptos básicos de GIT y cómo comenzar a utilizarlo.

Crear/configurar/clonar un repositorio:

Un repositorio es una de las herramientas más poderosas de cualquier proyecto de control de versiones. Para convertir cualquier directorio en un repositorio GIT, un simple comando git init le ayudará<каталог>. Después de ejecutar el comando, debería aparecer un directorio llamado .git en el lugar donde se ejecutó el comando.

Si ya tiene un directorio y desea agregarlo (clonarlo), use el comando clon de git. Para clonar un repositorio local, use el siguiente comando:

Clon de Git /ruta/al/local/repositorio

Si planea clonar un repositorio remoto, utilice:

Git clone nombre de usuario@host:/ruta/al/remoto/repositorio

Si tiene una cuenta de Hostinger, puede clonar y administrar fácilmente su repositorio a través de la herramienta en Paneles de control → GIT. Por ejemplo, desea clonar un repositorio GIT, simplemente ingrese su dirección, seleccione la rama, la ruta de instalación y haga clic en el botón Crear.

Una vez completada la creación, puede administrar su repositorio haciendo clic en el botón Control.

Flujo de trabajo:

Ahora que el repositorio está configurado, hablemos de su estructura. Cada repositorio local consta de tres árboles: directorio de trabajo– que consta de archivos, índice– que desempeña el papel de un lugar donde tienen lugar todos los cambios antes de su aplicación y CABEZA– que es un puntero a la última confirmación del usuario. El flujo de trabajo en sí se puede explicar de esta manera: el usuario agrega un archivo o cambia del directorio de trabajo al índice, luego, después de verlo y analizarlo, se aplica a CABEZA.

Agregar y confirmar comandos:

Los cambios o archivos propuestos se agregan al índice usando el comando agregar. Aquí hay un comando simple para agregar cualquier archivo:

git agregar<имя_файла>

Si tiene la suficiente confianza en el cambio como para comprometerse a hacerlo CABEZA, puedes usar el comando de confirmación. Para hacer esto, use el siguiente comando:

Git commit –m “Agregue aquí cualquier mensaje que describa el compromiso”

¡NOTA! Una vez que se ejecuta el comando de confirmación (desde el directorio de trabajo), el archivo se enviará a CABEZA, sin embargo, no se enviará al repositorio remoto; para esto se utiliza un comando separado.

Mayor promoción de cambios:

Una vez que se hayan confirmado los cambios (y si están listos para enviarse al repositorio original), puede usar el comando push.

Después de ejecutar el comando git push origin master desde el directorio de trabajo, todos los cambios presentes en CABEZA se enviará al repositorio remoto. En el comando anterior, el valor maestro debe cambiarse por el nombre de la rama para la que desea realizar cambios.

Sin embargo, si el repositorio existente aún no ha sido clonado y desea establecer una conexión entre su repositorio y el servidor remoto, hágalo ejecutando el siguiente comando:

Origen de adición remota de Git<сервер>

¡NOTA! Reemplazar el valor en el código<сервер>a la dirección del servidor remoto que necesitas en este momento.

Después de la clonación, los cambios realizados se transferirán al servidor correspondiente.

Sucursales:

Otra característica excelente y avanzada de GIT es la capacidad de los desarrolladores y gerentes de proyectos de crear múltiples ramas independientes dentro de un solo proyecto. El objetivo principal de una rama es desarrollar funciones aisladas y que no se afectan entre sí. La rama estándar en cualquier proyecto es siempre la rama maestra. Se puede crear cualquier cantidad de ramas según sea necesario y, finalmente, fusionarlas en la rama maestra.

Se puede crear una nueva rama usando este comando:

Git pago -b característica_n *

característica_n este es el nombre de la sucursal

Si desea volver a la rama maestra, use el siguiente comando:

maestro de pago de git

Cualquier rama se puede eliminar usando este comando:

Git pago -d característica_n

Para que una rama esté disponible para otros usuarios, debe enviarla al repositorio remoto. Para hacer esto, ingrese este comando:

Característica de origen de Git Push_n

Actualizar y fusionar:

En caso de que necesite actualizar su directorio local a su última versión desde un repositorio remoto, simplemente ejecute el comando git pull.

Para fusionar una rama activa con otra, use este comando: git merge feature_n.

Ya sea que use pull o merge, GIT siempre intenta resolver los conflictos por sí solo, pero no siempre lo logra. Si el comando falla, el usuario debe resolver el conflicto manualmente. Una vez que haya editado los archivos (para resolver el conflicto), márquelos como fusionados usando el comando:

git agregar<имя.файла>

Si desea ver las diferencias antes de fusionar ramas, puede ejecutar el siguiente comando:

diferencia git<имя_ветки_источника> <имя_целевой_ветки>

Calificación:

Antes de publicar actualizaciones o revisiones de software, se recomienda crear etiquetas o rótulos para ellas. Para realizar esta acción en GIT, ejecute este comando:

Etiqueta Git 1.1.0 1c2d2d56fa

1c2d2d56fa en el comando anterior se refiere a los primeros 10 caracteres del ID de confirmación al que hace referencia la etiqueta. El ID de confirmación o ID de confirmación se puede encontrar en el registro.

Revista:

Puede estudiar la historia del repositorio consultando la revista. Comando para llamar a git log. Para mostrar las confirmaciones realizadas por un usuario específico, utilice:

Registro de Git --autor =Nombre

Se puede ver una versión comprimida del registro (una confirmación por línea) usando el comando:

Registro de Git --pretty=oneline

Para ver archivos modificados:

Registro de Git: nombre-estado

Reemplazo de cambios locales:

Si de alguna manera hiciste un lío y quieres deshacer los cambios realizados en el archivo, realiza este proceso usando el siguiente comando:

Git pago--<имяфайла>

Al ejecutar este comando, reemplazará los datos modificados en el árbol de trabajo con los datos más recientes ubicados en CABEZA. Los cambios que ya se hayan agregado al índice no se verán afectados.

Por el contrario, si se deben eliminar todos los cambios o confirmaciones locales y la rama maestra local debe vincularse al historial más reciente del servidor, ejecute los siguientes comandos:

Git buscar origen git reset --hard origin/master

Muchos de los involucrados en el desarrollo de software han oído hablar de Git. ¿Cuáles son estas tres letras? Es muy importante comprender la descripción, así como los principios operativos, para poder utilizar efectivamente en el futuro este sistema de control de versiones, que, a diferencia de otros sistemas similares, tiene conceptos completamente diferentes sobre la información y el trabajo con ella, a pesar de un similar. interfaz de usuario. Entonces, ¿qué es Git?

Descripción

Git sirve para el control de versiones de los archivos que se están desarrollando. Fue creado en 2005 por el autor del sistema operativo Linux. Este sistema sincroniza el trabajo con el sitio y también guarda y actualiza los cambios en los archivos. Este es un enfoque muy conveniente cuando varios desarrolladores trabajan en un proyecto. Hoy en día, muchos proyectos conocidos utilizan Git. ¿Qué aporta este uso? Por ejemplo, una gran cantidad de programadores participan en el desarrollo del sistema operativo Android. Sería extremadamente inconveniente si uno de ellos hiciera cambios sin que los demás lo supieran. Git permite que todos estén al tanto de todos los cambios y, en caso de errores, volver a versiones anteriores de los archivos.

Usar yesos en lugar de parches

La principal diferencia entre Git y otros es la forma en que analiza los datos. La mayoría de los programas almacenan información en forma de una lista de cambios denominada parches de archivos. Dichos sistemas tratan los datos almacenados como un conjunto de archivos, así como un conjunto de cambios que se realizan en cada archivo, en relación con el tiempo. ¿Cómo almacena Git sus datos? ¿Qué tiene este sistema que lo distingue de los demás? En lugar de parches, los datos almacenados aquí se consideran un conjunto de instantáneas de un pequeño sistema de archivos. Cada vez que un usuario envía una nueva versión de un proyecto, el sistema simplemente guarda una instantánea del estado de los archivos en el momento actual. Para mejorar la eficiencia cuando el archivo no ha sido modificado, el sistema no lo guarda, sino que crea un vínculo a una instancia previamente guardada que fue modificada más recientemente.

Esta es una diferencia muy importante con respecto a otros sistemas de control que tiene Git. ¿Qué significa esta diferencia? Git se vuelve como un pequeño sistema de archivos con herramientas muy poderosas que se ejecutan sobre él.

Operaciones principalmente locales

Para realizar la mayoría de las operaciones en Git, solo necesita recursos y archivos locales. Esto significa que la mayoría de las veces no es necesaria la información ubicada en otras computadoras de la red. Dado que todos los cambios del proyecto están en el disco, las operaciones se realizan a la velocidad del rayo. Por ejemplo, para ver el historial de un proyecto, no es necesario descargarlo del servidor. Se lee desde un repositorio local en la computadora. Si necesita ver cambios entre una versión de un archivo que se creó hace un mes y la actual, puede hacerlo muy rápidamente sin comunicarse con el servidor.

El trabajo local también significa que puedes hacer muchas cosas sin conectarte a la red. Por ejemplo, un desarrollador puede realizar cambios mientras está en transporte. Muchos sistemas de control no tienen esta capacidad.

Monitoreo de integridad de datos

Antes de guardar cualquier archivo, se le asigna un índice en forma de suma de verificación calculada directamente por Git. ¿Cuál es este valor, que se calcula mediante algoritmos especiales y se utiliza para verificar la integridad de los datos durante el almacenamiento y la transmisión? Es imposible cambiar nada aquí sin el conocimiento de Git, y esta es una parte importante de la filosofía del sistema.

Los datos se agregan con mayor frecuencia

Casi todas las acciones realizadas en Git se agregan a la base de datos. Es muy difícil eliminarlos. Solo puede perder información que aún no se haya guardado, pero cuando se registra, se excluye la pérdida. Por esta razón, muchas personas eligen Git, ya que aquí pueden realizar experimentos sin riesgo de hacer algo irreparable.

Estados del archivo

Trabajar con Git para principiantes significa recordar que un archivo puede estar en uno de tres estados:

Confirmado, es decir, el archivo se guarda en el almacenamiento local.
Se modifica cuando se han realizado modificaciones pero aún no se han guardado.
Preparado: archivos modificados que están marcados para guardar.

Entonces, en proyectos que usan Git, hay tres secciones para diferentes estados de archivos:

El directorio de Git donde se almacenan los metadatos, así como la base de datos de objetos. Esta parte del sistema es la más importante.
El directorio de trabajo, que es una copia de alguna versión del proyecto extraída de la base de datos.
Un archivo que contiene información sobre el guardado posterior.

Instalación de Git

Lo primero que debe hacer para utilizar un sistema de control de versiones es instalarlo. Hay varias formas de hacer esto. Hay dos opciones principales:

Instalación de Git desde la fuente.
Instale el paquete para la plataforma que está utilizando.

Instalación de Git desde la fuente

Si es posible, es mejor utilizar esta opción, ya que se obtendrá la versión más reciente. Cada actualización suele contener muchas mejoras útiles relacionadas con Por eso, si la instalación desde la fuente no le resulta demasiado difícil, es mejor que la prefiera. Y la mayoría de las distribuciones de Linux incluyen paquetes obsoletos.

Para instalar necesitarás las bibliotecas necesarias: expat, curl, libiconv, openssl, zlib. Después de instalarlos, puede descargar la última versión del sistema de control, compilarlo e instalarlo.

Instalación en sistema operativo Windows

Si el usuario no tiene Linux, pero quiere utilizar Git, Windows también soporta este sistema. Y es muy fácil de instalar. Existe un proyecto msysGit cuyo procedimiento de instalación es uno de los más sencillos. Simplemente descargue el archivo de instalación, que se puede encontrar en la página de GitHub del proyecto, y luego ejecútelo. Al finalizar la instalación, habrá dos versiones en la computadora: gráfica y de consola.

Configuración inicial de Git

Una vez instalado el sistema de control en la computadora, debe realizar algunos pasos para configurar el entorno para el usuario. Esto se hace sólo una vez. Al actualizar, se guardan todas las configuraciones. Se pueden cambiar en cualquier momento.

Git incluye la utilidad git config, que le permite realizar configuraciones y controlar el comportamiento y la apariencia del sistema. Estos parámetros se pueden guardar en tres lugares:

En un archivo que contiene valores que son comunes a todos los usuarios y repositorios.
En un archivo que contiene configuraciones para un usuario específico.
En el archivo de configuración ubicado en el repositorio actual. Estos parámetros son válidos sólo para él.

Nombre personalizado

En primer lugar, después de la instalación, deberá proporcionar un nombre de usuario y un correo electrónico. Esto es muy importante porque cada confirmación (estado de guardado) contiene estos datos. Se incluyen en todas las confirmaciones comprometidas y no se pueden cambiar posteriormente.

Si especifica la opción -global, dicha configuración solo deberá realizarse una vez.

Seleccionar un editor de texto

Después de especificar el nombre, debe seleccionar el editor que necesitará al escribir mensajes en Git. De forma predeterminada, se utilizará el editor estándar del sistema operativo. Si el usuario desea utilizar otro, debe especificarlo en la configuración del archivo de configuración en la línea core.editor.

Comprobación de parámetros

Para conocer los conceptos básicos de Git, debe poder verificar la configuración que está utilizando. Para hacer esto, use config -list. Muestra todos los parámetros disponibles que puede encontrar. Algunos nombres de configuraciones pueden aparecer varias veces en la lista. Esto sucede porque Git lee la misma clave de diferentes archivos. En esta situación, se utiliza el último valor de cada clave. Es posible verificar los valores de ciertas claves ingresando "(clave)" en el comando en lugar de "--list".

Cómo crear un repositorio

Hay dos maneras de lograr este objetivo. La primera es importar un catálogo o proyecto existente al sistema. El segundo es clonar un repositorio existente desde el servidor.

Crear en un directorio determinado

Si un usuario decide comenzar a usar Git para un proyecto existente, debe navegar hasta el directorio e inicializar el sistema. Para hacer esto necesitas el comando git init. Crea un subdirectorio en el directorio donde se ubicarán todos los archivos necesarios. En esta etapa, aún no se ha establecido el control de versiones sobre el proyecto. Para agregar archivos bajo control, debe indexarlos y realizar la primera confirmación de cambios.

Clonar un repositorio

Para obtener una copia de un repositorio existente, necesita el comando git clone. Con su ayuda, Git obtendrá una copia de casi todos los datos del servidor. Esto se aplica a todas las versiones de cada archivo. Una característica muy conveniente, ya que si el servidor falla, el programador podrá usar el clon en cualquier cliente para devolver el servidor al estado en el que se encontraba durante la clonación. Esto es como un punto de restauración.

Eliminar un archivo en Git

Puede eliminar cualquier archivo del sistema si lo excluye del índice, es decir, de los archivos monitoreados. Para hacer esto necesitas el comando git rm. También elimina el archivo del directorio de trabajo del usuario. Entonces necesitas comprometerte. Después, el archivo simplemente desaparecerá y ya no será rastreado. Si se ha modificado y ya está indexado, se utiliza la eliminación forzada con el parámetro -f. Este método evitará la eliminación de datos que aún no se han registrado en la instantánea y que no se pueden recuperar del sistema.

Cancelar cambios

En cualquier momento puede ser necesario cancelar una acción. Si el usuario se comprometió temprano y olvidó incluir algunos archivos, puede volver a confirmar usando la opción --amend. Este comando se utiliza para confirmar el índice. Si no se han realizado cambios desde la última vez que se guardó, el proyecto estará en el mismo estado y aparecerá un editor de comentarios donde el usuario podrá editar todo lo necesario. Recuerde que no todas las operaciones de deshacer se pueden deshacer. A veces puedes eliminar permanentemente los datos necesarios. Deberías tener cuidado.

Resultados

Ahora el usuario debería tener una idea de qué es Git, por qué es necesario este sistema de control de versiones y en qué se diferencia de otros productos similares. Está claro que para una familiarización completa, debe instalar una versión funcional de Git con su configuración personal. No estaría de más tener un libro de texto o un curso en vídeo sobre Git para principiantes que puedan guiar al usuario paso a paso a través de todas las etapas del trabajo con el sistema.

Popular en la categoría: