Correccion del README_EO #297

Closed
mester wants to merge 10 commits from Traduko into main
Collaborator

Perdona, pero creo que el sistema que utilizo para gestionar git desde el editor de textos creo que coge todo lo que tengo, que no está fusionado a la rama principal y como no sé cómo arreglarlo

Perdona, pero creo que el sistema que utilizo para gestionar git desde el editor de textos creo que coge todo lo que tengo, que no está fusionado a la rama principal y como no sé cómo arreglarlo
mester added the
TRANSLATION
label 2024-01-12 20:36:58 +01:00
fede was assigned by mester 2024-01-12 20:36:58 +01:00
mester added 7 commits 2024-01-12 20:36:58 +01:00
mester added 1 commit 2024-01-12 20:38:54 +01:00
Owner

Perdona, pero creo que el sistema que utilizo para gestionar git desde el editor de textos creo que coge todo lo que tengo, que no está fusionado a la rama principal y como no sé cómo arreglarlo

Probablemente porque una vez fusionados tus cambios originales, la rama se borra en el servidor pero no ha sucedido lo mismo localmente en tu equipo.

Una vez que tus cambios han sido fusionados, tendrías que

  1. cambiar a la rama principal (main) (git checkout main)
  2. traer (actualizar) la rama main con los cambios fusionados (git pull)
  3. borrar la rama local utilizada originalmente (y que se borra en el servidor cuando se acepta la fusión) (git branch -d <nombre.de.la.rama>
  4. crear una rama local nueva a partir de la principal (o main) (git checkout -b <nombre.de.la.rama.nueva>

En el caso de este último PR (Pull request o Pedido de Fusión) lo que habría que hacer es seguir los pasos arriba comentados y solicitar uno nuevo.

Adicionalmente, hay que tener presente que no es necesario hacer un commit cada vez que hacemos una modificación:

lo primero que necesitamos entender es que un commit no es como hacer Ctrl+s porque Git no es "solo un sistema de respaldos". Un commit es más como una instantánea de nuestra carpeta de proyecto en un punto determinado. La idea principal detrás de un sistema de control de versiones (Git en este caso) es permitir llevar un registro de todos los cambios realizados a nuestro código a lo largo del tiempo así podemos mirar hacia atrás y verificar cuándo, cómo y por qué se ha "desarrollado". Cada "commit" es, entonces, un "hito" en el historial de registros de nuestro proyecto. Y cada "hito" es acompañado de un mensaje que describe qué ha cambiado. Necesitamos tener en cuenta que cuantos más commits realizamos más se llena la línea de tiempo, aumentando por consiguiente las posibilidades de generar un historial de registros "confuso".

Comento esto porque el PR anterior tenía varios "commits" en lugar de solo uno o dos.

Muchas gracias por dedicarle tiempo.

> Perdona, pero creo que el sistema que utilizo para gestionar git desde el editor de textos creo que coge todo lo que tengo, que no está fusionado a la rama principal y como no sé cómo arreglarlo Probablemente porque una vez fusionados tus cambios originales, la rama se borra en el servidor pero no ha sucedido lo mismo localmente en tu equipo. Una vez que tus cambios han sido fusionados, tendrías que 1. cambiar a la rama principal (main) (git checkout main) 2. traer (actualizar) la rama main con los cambios fusionados (git pull) 3. borrar la rama local utilizada originalmente (y que se borra en el servidor cuando se acepta la fusión) (git branch -d <nombre.de.la.rama> 4. crear una rama local nueva a partir de la principal (o main) (git checkout -b <nombre.de.la.rama.nueva> En el caso de este último PR (Pull request o Pedido de Fusión) lo que habría que hacer es seguir los pasos arriba comentados y solicitar uno nuevo. Adicionalmente, hay que tener presente que no es necesario hacer un commit cada vez que hacemos una modificación: > lo primero que necesitamos entender es que un commit no es como hacer Ctrl+s porque Git no es "solo un sistema de respaldos". Un commit es más como una instantánea de nuestra carpeta de proyecto en un punto determinado. La idea principal detrás de un sistema de control de versiones (Git en este caso) es permitir llevar un registro de todos los cambios realizados a nuestro código a lo largo del tiempo así podemos mirar hacia atrás y verificar cuándo, cómo y por qué se ha "desarrollado". Cada "commit" es, entonces, un "hito" en el historial de registros de nuestro proyecto. Y cada "hito" es acompañado de un mensaje que describe qué ha cambiado. Necesitamos tener en cuenta que cuantos más commits realizamos más se llena la línea de tiempo, aumentando por consiguiente las posibilidades de generar un historial de registros "confuso". Comento esto porque el PR anterior tenía varios "commits" en lugar de solo uno o dos. Muchas gracias por dedicarle tiempo.
Author
Collaborator

Gracias

Gracias
mester added 2 commits 2024-01-27 18:14:10 +01:00
fede requested review from fede 2024-01-27 21:20:44 +01:00
mester closed this pull request 2024-03-07 16:33:47 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Disroot/Howto#297
No description provided.