Siguiendo la tradición establecida, los saludo como futuros ingenieros de software senior. El artículo de hoy es la extensión lógica de mi artículo sobre Git . En el artículo sobre Git, describí cómo trabajar con Git en la línea de comandos. Hoy les mostraré cómo hacerlo todo en IntelliJ IDEA. Al comienzo de mi viaje como desarrollador, usé la línea de comandos y pensé que no necesitaba una GUI para esto. Después de todo, todo estaba claro como estaba... Pero eso fue justo hasta el momento en que comencé a usar Git en IntelliJ IDEA... Desde el principio, quiero decir que estoy describiendo mi experiencia personal. Hay varias formas de resolver cualquier problema en IntelliJ IDEA. Si conoce una forma mejor que la que describiré en el artículo, escríbala en los comentarios y la discutiremos.
Entradas requeridas:
Lea, siga y comprenda mi artículo sobre Git . Esto ayudará a garantizar que todo esté configurado y listo para funcionar.
Instale IntelliJ IDEA.
Asignar una hora de tiempo personal para lograr el dominio completo.
Trabajemos con el proyecto de demostración que usé para el artículo sobre Git. ACTUALIZAR:En el momento de la publicación, la nueva interfaz de usuario de GitHub estará disponible y algunos íconos no estarán donde se muestran en el artículo. No se alarme: solo necesita no cambiar a la nueva interfaz de usuario o buscarlos.
Clonar el proyecto localmente
Aquí hay dos opciones:
Si ya tiene una cuenta de GitHub y desea impulsar algo más adelante, es mejor bifurcar el proyecto y clonar su propia copia.
Clone mi repositorio y haga todo localmente sin la capacidad de enviar todo al servidor. Después de todo, este es mi repositorio :)
Para clonar un proyecto de GitHub, debe copiar el enlace del proyecto y pasarlo a IntelliJ IDEA:
Copie la dirección del proyecto:
Abra IntelliJ IDEA y seleccione "Obtener del control de versiones":
Copie y pegue la dirección del proyecto:
Se le pedirá que cree un proyecto IntelliJ IDEA. Acepto la oferta:
Dado que no hay un sistema de compilación y eso está más allá del alcance de este artículo, seleccionamos Crear proyecto a partir de fuentes existentes :
A continuación, verá esta hermosa pantalla: ahora que descubrimos la clonación, puede echar un vistazo.
Primer vistazo a IntelliJ IDEA como una interfaz de usuario de Git
Eche un vistazo más de cerca al proyecto clonado: ya puede obtener mucha información sobre el sistema de control de versiones. Primero, tenemos el panel Control de versiones en la esquina inferior izquierda. Aquí puede encontrar todos los cambios locales y obtener una lista de confirmaciones (análoga a "git log"). Pasemos a una discusión de Log . Hay una cierta visualización que nos ayuda a entender exactamente cómo ha procedido el desarrollo. Por ejemplo, puede ver que se creó una nueva rama con un encabezado agregado a la confirmación de txt, que luego se fusionó con la rama principal. Si hace clic en un compromiso, puede ver en la esquina derecha toda la información sobre el compromiso: todos sus cambios y metadatos.Además, puede ver los cambios reales. También vemos que allí se resolvió un conflicto. IDEA también presenta esto muy bien. Si hace doble clic en el archivo que se modificó durante esta confirmación, veremos cómo se resolvió el conflicto: Notamos que a la izquierda y a la derecha tenemos las dos versiones del mismo archivo que debían fusionarse en una sola. Y en el medio, tenemos el resultado combinado final. Cuando un proyecto tiene muchas ramas, confirmaciones y usuarios, debe buscar por separado por rama, usuario y fecha: lo último que quiero explicar antes de comenzar es cómo entender en qué rama estamos. un minuto para averiguarlo... ¿Lo encontraste? ¿Abandonar? :D En la esquina inferior derecha, hay un botón llamado Git: master. Lo que sigue a "Git:" es la rama actual. Si hace clic en el botón, puede hacer muchas cosas útiles: cambiar a otra rama, crear una nueva, cambiar el nombre de una existente, etc.
Trabajando con un repositorio
Teclas de acceso rápido útiles
Para el trabajo futuro, debe recordar algunas teclas de acceso rápido muy útiles:
CTRL+T : obtenga los últimos cambios del repositorio remoto (git pull).
CTRL+K — Crear una confirmación/ver todos los cambios actuales. Esto incluye archivos sin seguimiento y modificados (consulte mi artículo sobre git, que explica esto) (confirmación de git).
CTRL+SHIFT+K : este es el comando para enviar cambios al repositorio remoto. Todas las confirmaciones creadas localmente y que aún no están en el repositorio remoto se enviarán (git push).
ALT+CTRL+Z : revierte los cambios en un archivo específico al estado de la última confirmación creada en el repositorio local. Si selecciona todo el proyecto en la esquina superior izquierda, puede revertir los cambios en todos los archivos.
¿Qué queremos?
Para hacer el trabajo, necesitamos dominar un escenario básico que se usa en todas partes. El objetivo es implementar una nueva funcionalidad en una rama separada y luego enviarla a un repositorio remoto (entonces también necesita crear una solicitud de extracción para la rama principal, pero eso está más allá del alcance de este artículo). ¿Qué se requiere para hacer esto?
Obtenga todos los cambios actuales en la rama principal (por ejemplo, "maestro").
Desde esta rama principal, cree una rama separada para su trabajo.
Implementar la nueva funcionalidad.
Vaya a la sucursal principal y verifique si ha habido algún cambio nuevo mientras estábamos trabajando. Si no, entonces todo está bien. Pero si hubo cambios, hacemos lo siguiente: vamos a la rama de trabajo y rebase los cambios de la rama principal a la nuestra. Si todo va bien, entonces genial. Pero es muy posible que haya conflictos. Da la casualidad de que solo se pueden resolver de antemano, sin perder tiempo en el repositorio remoto.
¿Te preguntas por qué deberías hacer esto? Es de buena educación y evita que ocurran conflictos después de enviar su rama al repositorio local (existe, por supuesto, la posibilidad de que aún ocurran conflictos, pero se vuelve mucho más pequeño ).
Empuje sus cambios al repositorio remoto.
Lo que viene después depende de tus tareas y tu imaginación.
¿Obtener cambios del servidor remoto?
Agregué una descripción al LÉAME con una nueva confirmación y quiero obtener estos cambios. Si se realizaron cambios tanto en el repositorio local como en el remoto, se nos invita a elegir entre una fusión y una reorganización. Elegimos fusionarnos. Ingrese CTRL+T : ahora puede ver cómo ha cambiado el LÉAME, es decir, se extrajeron los cambios del repositorio remoto, y en la esquina inferior derecha puede ver todos los detalles de los cambios que provienen del servidor.
Crear una nueva rama basada en el maestro
Todo es simple aquí.
Vaya a la esquina inferior derecha y haga clic en Git: master . Seleccione + Nueva Sucursal .
Deje seleccionada la casilla de verificación Sucursal de Checkout e ingrese el nombre de la nueva sucursal. Para mí, será readme-improver .
Git: master luego cambiará a Git: readme-improver .
Simulemos trabajo paralelo
Para que aparezcan los conflictos, alguien tiene que crearlos :D Editaré el README con un nuevo commit a través del navegador, simulando así un trabajo paralelo. Es como si alguien hiciera cambios en el mismo archivo mientras yo estaba trabajando en él. El resultado será un conflicto. Eliminaré la palabra "completamente" de la línea 10.
Implementar nuestra funcionalidad
Nuestra tarea es cambiar el README y agregar una descripción al nuevo artículo. Es decir, el trabajo en Git pasa por IntelliJ IDEA. Agrega esto: Los cambios están hechos. Ahora podemos crear un compromiso. Presione CTRL+K , lo que nos da: Antes de crear una confirmación, debemos observar de cerca lo que ofrece esta ventana. Agregué flechas rojas para mostrarle dónde buscar. Hay muchas cosas interesantes aquí. En la sección Mensaje de confirmación , escribimos el texto asociado con la confirmación. Luego, para crearlo, debemos hacer clic en Confirmar. Todavía no he descubierto cómo hacer esto con una tecla de acceso rápido. Si alguien descubre cómo, por favor escríbame, eso me haría muy feliz. Escribimos que el README ha cambiado y creamos el commit. Aparece una alerta en la esquina inferior izquierda con el nombre de la confirmación:
Comprobar si la rama principal ha cambiado
Completamos nuestra tarea. Funciona. Escribimos pruebas. Todo esta bien. Pero antes de enviar al servidor, aún debemos verificar si hubo algún cambio en la rama principal mientras tanto. ¿Cómo pudo pasar eso? Bastante fácil: alguien recibe una tarea después de ti, y ese alguien la termina más rápido de lo que tú terminas tu tarea. Así que tenemos que ir a la rama maestra. Para hacer esto, debemos hacer lo que se muestra en la esquina inferior derecha de la captura de pantalla a continuación: En la rama principal, presione CTRL+T para obtener los últimos cambios del servidor remoto. Al observar los cambios, puede ver fácilmente lo que sucedió:Se eliminó la palabra "completamente". Tal vez alguien de marketing decidió que no debería escribirse así y le dio a los desarrolladores la tarea de actualizarlo. Ahora tenemos una copia local de la última versión de la rama maestra. Regrese a readme-improver . Ahora necesitamos reorganizar los cambios de la rama principal a la nuestra. Hacemos esto: Si hiciste todo correctamente y me seguiste, el resultado debería mostrar un conflicto en el archivo README: Aquí también tenemos mucha información para comprender y absorber. Aquí se muestra una lista de archivos (en nuestro caso, un archivo) que tienen conflictos. Podemos elegir entre tres opciones:
acepte el suyo: acepte solo los cambios de readme-improver.
acepte los suyos: acepte solo los cambios del maestro.
fusionar: elija usted mismo lo que desea conservar y lo que descarta.
No está claro qué cambió. Si hay cambios en la rama maestra, deben ser necesarios allí, por lo que no podemos simplemente aceptar nuestros cambios. En consecuencia, seleccionamos fusionar : Aquí podemos ver que hay tres partes:
Estos son los cambios de readme-improver.
El resultado combinado. Por ahora, es lo que existía antes de los cambios.
Los cambios de la rama maestra.
Necesitamos producir un resultado combinado que satisfaga a todos. Al revisar lo que se cambió ANTES de nuestros cambios, nos damos cuenta de que simplemente eliminaron la palabra "completamente". ¡Está bien, no hay problema! Eso significa que también lo eliminaremos en el resultado combinado y luego agregaremos nuestros cambios. Una vez que corrijamos el resultado combinado, podemos hacer clic en Aplicar . Luego aparecerá una notificación, diciéndonos que la rebase fue exitosa: ¡ Ya está! Resolvimos nuestro primer conflicto a través de IntelliJ IDEA :D
Empuje los cambios al servidor remoto
El siguiente paso es enviar los cambios al servidor remoto y crear una solicitud de extracción. Para hacer esto, simplemente presione CTRL+SHIFT+K . Luego obtenemos: A la izquierda, habrá una lista de confirmaciones que no se han enviado al repositorio remoto. A la derecha estarán todos los archivos que han cambiado. ¡Y eso es! Presiona Push y experimentarás felicidad :) Si el push es exitoso, verás una notificación como esta en la esquina inferior derecha:
parte de bonificación
Al principio, no quería agregar la creación de una solicitud de extracción a este artículo, pero no estaría completo sin ella. Entonces, vayamos a un repositorio de GitHub (uno que sea tuyo, por supuesto :)) y vemos que GitHub ya sabe lo que queremos: haz clic en Comparar y solicitar extracción . Luego haz clic en Crear solicitud de extracción . Debido a que resolvimos los conflictos por adelantado, ahora, al crear una solicitud de extracción, podemos fusionarla de inmediato: y eso es todo lo que quería decir esta vez. Por supuesto, solo les abrí un poco la puerta y les mostré una pequeña parte. Del resto te enterarás a medida que lo necesites. Tengo la costumbre de invitarte a que me sigas en GitHub, donde publico mis proyectos que involucran varias tecnologías que utilizo en el trabajo. Recientemente obtuve un logro personal: uno de mis proyectos recibió estrellas de más de cien desarrolladores. Hay un increíble sentimiento de alegría cuando sabes que lo que has hecho está siendo utilizado por otra persona. Y usarlo para bien.
El artículo de hoy es la extensión lógica de mi artículo sobre Git . En el artículo sobre Git, describí cómo trabajar con Git en la línea de comandos. Hoy les mostraré cómo hacerlo todo en IntelliJ IDEA. Al comienzo de mi viaje como desarrollador, usé la línea de comandos y pensé que no necesitaba una GUI para esto. Después de todo, todo estaba claro como estaba... Pero eso fue justo hasta el momento en que comencé a usar Git en IntelliJ IDEA... Desde el principio, quiero decir que estoy describiendo mi experiencia personal. Hay varias formas de resolver cualquier problema en IntelliJ IDEA. Si conoce una forma mejor que la que describiré en el artículo, escríbala en los comentarios y la discutiremos.
ahora que descubrimos la clonación, puede echar un vistazo.
Además, puede ver los cambios reales. También vemos que allí se resolvió un conflicto. IDEA también presenta esto muy bien. Si hace doble clic en el archivo que se modificó durante esta confirmación, veremos cómo se resolvió el conflicto: Notamos 
que a la izquierda y a la derecha tenemos las dos versiones del mismo archivo que debían fusionarse en una sola. Y en el medio, tenemos el resultado combinado final. Cuando un proyecto tiene muchas ramas, confirmaciones y usuarios, debe buscar por separado por rama, usuario y fecha: 
lo último que quiero explicar antes de comenzar es cómo entender en qué rama estamos. un minuto para averiguarlo... ¿Lo encontraste? ¿Abandonar? :D En la esquina inferior derecha, hay un botón llamado Git: master. Lo que sigue a "Git:" es la rama actual. Si hace clic en el botón, puede hacer muchas cosas útiles: cambiar a otra rama, crear una nueva, cambiar el nombre de una existente, etc.
ahora puede ver cómo ha cambiado el LÉAME, es decir, se extrajeron los cambios del repositorio remoto, y en la esquina inferior derecha puede ver todos los detalles de los cambios que provienen del servidor.
Los cambios están hechos. Ahora podemos crear un compromiso. Presione CTRL+K , lo que nos da: 
Antes de crear una confirmación, debemos observar de cerca lo que ofrece esta ventana. Agregué flechas rojas para mostrarle dónde buscar. Hay muchas cosas interesantes aquí. En la sección Mensaje de confirmación , escribimos el texto asociado con la confirmación. Luego, para crearlo, debemos hacer clic en Confirmar. Todavía no he descubierto cómo hacer esto con una tecla de acceso rápido. Si alguien descubre cómo, por favor escríbame, eso me haría muy feliz. Escribimos que el README ha cambiado y creamos el commit. Aparece una alerta en la esquina inferior izquierda con el nombre de la confirmación:
En la rama principal, presione CTRL+T para obtener los últimos cambios del servidor remoto. Al observar los cambios, puede ver fácilmente lo que sucedió:
Se eliminó la palabra "completamente". Tal vez alguien de marketing decidió que no debería escribirse así y le dio a los desarrolladores la tarea de actualizarlo. Ahora tenemos una copia local de la última versión de la rama maestra. Regrese a readme-improver . Ahora necesitamos reorganizar los cambios de la rama principal a la nuestra. Hacemos esto: 
Si hiciste todo correctamente y me seguiste, el resultado debería mostrar un conflicto en el archivo README: 
Aquí también tenemos mucha información para comprender y absorber. Aquí se muestra una lista de archivos (en nuestro caso, un archivo) que tienen conflictos. Podemos elegir entre tres opciones:
Aquí podemos ver que hay tres partes:
Ya está! Resolvimos nuestro primer conflicto a través de IntelliJ IDEA :D
A la izquierda, habrá una lista de confirmaciones que no se han enviado al repositorio remoto. A la derecha estarán todos los archivos que han cambiado. ¡Y eso es! Presiona Push y experimentarás felicidad :) Si el push es exitoso, verás una notificación como esta en la esquina inferior derecha:
haz clic en Comparar y solicitar extracción . Luego haz clic en Crear solicitud de extracción . Debido a que resolvimos los conflictos por adelantado, ahora, al crear una solicitud de extracción, podemos fusionarla de inmediato: 
y eso es todo lo que quería decir esta vez. Por supuesto, solo les abrí un poco la puerta y les mostré una pequeña parte. Del resto te enterarás a medida que lo necesites. Tengo la costumbre de invitarte a que me sigas en GitHub, donde publico mis proyectos que involucran varias tecnologías que utilizo en el trabajo. Recientemente obtuve un logro personal: uno de mis proyectos recibió estrellas de más de cien desarrolladores. Hay un increíble sentimiento de alegría cuando sabes que lo que has hecho está siendo utilizado por otra persona. Y usarlo para bien.
GO TO FULL VERSION