Cómo configurar o guardar cambios en archivos con Git o administrar Branches o ramas

Supongamos que ya tiene un repositorio de Git en GitHub y desea obtener sus archivos y tal vez perdió la copia local en su computadora o está trabajando en una computadora diferente y desea acceder a los archivos en su repositorio.

Qué debes hacer? Descarga tus archivos desde GitHub? ¡Exactamente! A esto lo llamamos "clonación" en la terminología de Git.

¿Cómo manejar cambios en archivos con Git?

Cómo clonar en Git

Vamos a clonar el repositorio, llamado Demo, que creamos en el último artículo. (Si aún no ha creado un repositorio de demostración. Para clonar su archivo, navegue como puede ver arriba "Clonar con HTTPS" La opción está abierta, puedes cambiar o modificar la fecha de un archivo.

• Copie la URL de su repositorio desde ese cuadro desplegable (https://github.com/ <your_username> /Demo.git).
• Abra el terminal y escriba el siguiente comando para clonar su repositorio de GitHub en su computadora:
• git clone https://github.com/<your_username>/Demo.git
• Luego, para ver la lista de archivos en el directorio de demostración, ingrese el comando : ls Demo /

Modificar Archivos

Ahora que hemos clonado el repositorio, modifiquemos los archivos y los actualicemos en GitHub. Para comenzar, ingrese los comandos a continuación. Uno por uno, para cambiar el directorio a Demo /, verifique el contenido de README.md, haga eco del nuevo contenido (adicional) a README.md y verifique el estado con git status:

• cd Demo /
• ls
• cat README.md
• echo "Agregó otra línea a REAMD.md" >> README.md
• cat README.md
• git status.

Cargue un archivo en su repositorio

Hemos modificado el archivo README.md con un contenido nuevo y es hora de cargarlo. a GitHub.
Vamos a cometer los cambios y empujarlos a GitHub, puedes cambiar la extensión del archivo.

git commit -m "Archivo Léame actualizado"

Esto le dice a Git que está "comprometiéndose" a los cambios que le "agregó". Puede recordar de la primera parte de esta serie que es importante agregar un mensaje para explicar Lo que hizo en su confirmación para que sepa cuál es su propósito cuando vuelva a mirar su registro de Git más adelante. El archivo Léame actualizado es el mensaje para esta confirmación. Si no cree que esta sea la forma más lógica de explicar lo que hizo, no dude en escribir su mensaje de confirmación de manera diferente.

Agregue un Nuevo Archivo a Git

Ahora que hemos modificado un archivo y lo hemos actualizado en GitHub, vamos a crear un nuevo archivo, a agregarlo a Git y subirlo a GitHub, puedes combinar varios archivos.

• echo "Este es un archivo nuevo" >> file.txt
• Esto creará un nuevo archivo llamado file.txt.
• Debería ver el contenido del archivo. Ahora ejecute:

Git Status

Git informa que tiene un archivo sin seguimiento (llamado file.txt) en su repositorio. Esta es la manera en que Git le dice que hay un nuevo archivo En el directorio de repo en su computadora sobre el que no se lo ha contado y Git no está rastreando ese archivo por los cambios que realice.

Eliminar un Archivo de Git.

Sucede qué si descubrimos que cometimos un error y necesitamos eliminar file.txt de nuestro repositorio. Una forma es eliminar el archivo de nuestra copia local del repositorio con este comando:

• rm file.txt
• Si ahora hace el estado de git.
• Git dice que hay un archivo que no está preparado para la confirmación.
• Y que se eliminó de la copia local de la repo.
• Ahora ejecutamos
• git add file.txt -> git status

Git add

Puede usarse cuando estamos agregando un nuevo archivo a Git, modificando el contenido de un archivo existente y agregándolo a Git, o eliminando un archivo de un repositorio de Git.

Efectivamente, git add tiene en cuenta todos los cambios y los pone en marcha para confirmarlos. En caso de duda, mire cuidadosamente la salida de cada comando en la captura de pantalla del terminal a continuación.

Git nos dirá que el archivo eliminado está preparado para su confirmación. Tan pronto como confirme este cambio y lo envíe a GitHub, el archivo también se eliminará del repositorio en GitHub.

• git commit -m "Delete file.txt"
• git push -u origin master

Si eres un programador, o estar interesado en realizar tu proyecto utilizando las herramientas brindadas por GIT. Entonces sin duda has llegado a escuchar o habrás leído en algún rincón de internet sobre los Branches. Estos son una herramienta bastante particular y realmente útil al momento de trabajar en GIT.

Los Branchesson ramificaciones en el almacén o también llamado repositorio de nuestro proyecto. Entendiéndose mediante otras palabras, un Branch es simplemente otro camino a tomar por nuestro proyecto, diferente al principal. Permitiendo así a sus usuarios poder realizar actividades o pruebas que no afectarían directamente al proyecto. Sino que, sirven como ensayo para poder comprobar que el código redactado sea funcional para que el código redactado sea funcional, estos sirven como ensayo. En el caso de que no haya funcionado, simplemente se descartaría dicho código sin haber afectado al producto inicial. Ahora, en los siguientes párrafos se te explicará las razones y formas de usar los Branch.

¿Por qué estamos utilizando Branches?

Si eres un usuario habitual de GIT, probablemente te hayas dado cuenta de que no resulta indispensable el uso de Branches. Esto se debe a que cuando se maneja un solo Branch y las actividades se están realizando por una sola persona. No es necesario manejar múltiples Branches.

Pero, este caso puede verse modificado, varias personas pueden estar incluidas en el desarrollo. O incluso, pueden estar en necesidad de realizar una prueba que pueda dañar la estructura del proyecto. En este caso en el que se realizarán “trys” de características experimentales, puede llegar a ser necesaria la implementación de Branches.

Realmente algunos de los usuarios de GIT pueden a afirmar que lo correcto sería realizar un fork del proyecto que se está llevando a cabo. Y a continuación, implementar las medidas experimentales para ver su resultado. Para después incluir esta mejora en el fork anteriormente realizado o descartarla en el caso de ser contraproducente.

Sí, realmente esta es una medida viable, pero de igual manera resulta en un trabajo bastante largo y probablemente innecesario. Debido a que con solo incluir un nuevo Branch dentro del proyecto podremos experimentar tanto como queramos. Y en el caso de que los cambios realizados no sean de nuestro agrado, no pasa nada, simplemente no unimos los Branch en mención.

Pero, si consideramos que los cambios realizados a este Branch pueden beneficiar nuestro proyecto. Tan solo necesitaremos hacer un merge o fusión con el Branch principal ¡y listo!, el trabajo estaría hecho. Bastante más fácil y rápido que la otra manera, ¿cierto?

Ahora, adentrando un poco más en la posibilidad de que haya dos personas trabajando en un mismo proyecto. Existe la gran posibilidad de que surjan conflictos en los códigos que ellas escriban. Obviamente dos cerebros no a la pensar ni actuar exactamente igual.

De esta manera GIT nuevamente presenta su gran capacidad para desarrollar proyectos en grupo. Debido a que se podría generar una estructura con tres diferentes Branch. A los desarrolladores se les asignaría dos para que puedan trabajar de forma individual. Y un tercero que sería el Branch principal o unificador.

Permitiendo así que cada uno de los desarrolladores trabaje a su propio ritmo   y realice su código bajo su propia autonomía. Y después, cuando se haya comprobado que el código es funcional. Estos Branch pertenecientes a los desarrolladores serían incorporados al Branch unificador.