Hola Jose Israel:

La verdad es que para la gestión GitHub utilizo la web como aplicación visual, aunque siempre que puedo utilizo el comando gh (https://cli.github.com/) Hubo una temporada que probé GitHub Desktop, hace unos años ya (https://desktop.github.com/) pero no me enganchó y no la he usado casi.

Hola de nuevo SVA:

Como te he respondido en otro commentario tuyo al respecto, de nuevo gracias por recordarme lo complicado que es hablar de este tema en Español. A raiz de tus comentarios, he estado leyendo al respecto en la RAE ya que efectivamente, mis textos están llenos de extranjerismos.

En todos los años que llevo trabajando con git con compañeros del metal en español, absolutamente a nadie, jamás, le he escuchado decir «petición de extracción» o «confirmación de cambios». Si usase ese vocabulario entre mis compañeros no sabrían de qué estoy hablando, te lo aseguro. Pocas veces he escuchado el uso de bifurcación en lugar de fork, que a mi es un término que me parece tremendamente confuso en castellano ya que puede confundirse un fork traducido como bifurcación con una bifurcación como tal en un grafo consecuencia del uso de ramas. Si en un curso en el que hablo de forks en lugar de usar el extranjerismo usase el término bifurcación, la confusión que generaría en las personas a las que estoy intentando enseñar sería tremenda.

Asi que, siendo práctico, y estando totalmente de acuerdo contigo en que el español es muy rico y que debemos usarlo siempre que podamos, seguiré usando los extranjerismos para que el resto de interlocutores me entienda sin ambigüedades.

Commo te he comentado antes, gracias a tus comentarios he estado liyendo un poco sobre este tema. Encontré en la RAE este documento (https://www.rae.es/dpd/ayuda/tratamiento-de-los-extranjerismos) que dice lo siguiente:

En su tratamiento se han aplicado los siguientes criterios generales:

1. Extranjerismos superfluos o innecesarios. Son aquellos para los que existen equivalentes españoles con plena vitalidad. En el artículo se detallan esas alternativas y se censura el empleo de la voz extranjera. Ejemplos: abstract (en español, resumen, extracto), back-up (en español, copia de seguridad), consulting (en español, consultora o consultoría).

2. Extranjerismos necesarios o muy extendidos. Son aquellos para los que no existen, o no es fácil encontrar, términos españoles equivalentes, o cuyo empleo está arraigado o muy extendido. Se aplican dos criterios, según los casos:

2.1. Mantenimiento de la grafía y pronunciación originarias. Se trata de extranjerismos asentados en el uso internacional en su forma original, como ballet, blues, jazz o software. En este caso se advierte de su condición de extranjerismos crudos y de la obligación de escribirlos con resalte tipográfico (cursiva o comillas) para señalar su carácter ajeno a la ortografía del español, hecho que explica que su pronunciación no se corresponda con su forma escrita. No obstante, en algunas ocasiones no se ha renunciado a sugerir fáciles adaptaciones o posibles equivalencias, que se proponen en segundo término.

2.2. Adaptación de la pronunciación o de la grafía originarias. La mayor parte de las veces se proponen adaptaciones cuyo objetivo prioritario es preservar el alto grado de cohesión entre forma gráfica y pronunciación característico de la lengua española. La adaptación de estas voces se ha hecho por dos vías

Creo que los extranjerismos relacionados con git cumplen el punto 2: están muy extendidos y/o no es fácil encontrar términos en castellano equivalentes. Por ejemplo «petición de extracción» o «confirmación de cambios», son términos que a mi juicio no significan lo mismo que los correspondientes términos en inglés. Por ello, seguiré usando los extranjerismos.

De nuevo, te agradezco tus comentarios ya que me has ayudado a profundizar en un tema sobre el que nunca me había detenido a pensarlo mínimament. Si algún día coincidimos en algún evento, sería genial continuar esta conversación en persona.

Un cordial saludo,

Alfonso

hola SVA:

Lamento que el artículo te de repelús, la verdad es que esta serie de artículos sobre pull requests es la que mejores comentarios ha recibido de todo el blog. Gracias por enseñarme que el extranjerismo se escribe en cursiva, lo tendré en cuenta cuando escriba en el futuro.

Un saludo,

Alfonso

Luis, tienes razón en este comentario. Es problema de cómo está escrito el artículo. Con tanto extranjerismo crudo es muy difícil leerlo. Está lleno de faltas.
Invito a la revisión de este artículo, por ejemplo:
Un pull request es una petición que el propietario de un fork de un repositorio hace al propietario del repositorio original para que este último incorpore los commits que están en el fork.
Sustituir por:
Una petición de extración o «pull request» es una petición que el propietario de una bifurcación ( fork – en cursiva-) hace al propietario del repositorio original para que este último incorpore la confirmación del conjunto de cambios que están en la bifurcación (fork).

Así el artículo tendría mucha más calidad.
Saludos.

Hola Clau:

No hay ninguna diferencia, es sólo una diferencia de nombre. Gitlab lo llama «merge request» y github / bitbucket lo llaman «pull request».

Y en respuesta a tu segunda pregunta, no, no es obligatorio usar forks para hacer un pull request.

gracias!

¡Gracias por visitarnos Jose Ángel! me alegro de que te haya resultado útil.

Hola Daniel:

Acabo de ver este comentario metido entre el SPAM del blog. Disculpa que haya tardado tanto tiempo en responderte. Es una buena pregunta y aunque haya pasado tiempo, te respondo por si aún te sirve la respuesta.

Para eliminar ese commit necesitas hacer un rebase interactivo.

3b4r4903 (ramaX)
549nf34
4m3400
904g4jf4
aaabbbccc

(date cuenta que a los commits que has puesto tu yo he añadido el commit aaabbbccc, que sería el padre de 904g4jf4)

El comando sería:


> git checkout ramaX
> git rebase -i aaabbbccc


Este comando abrirá un editor de texto con una pantalla similar a la siguiente:


pick 904g4jf Comentario de este commit...
pick 4m3400 Comentario de este commit...
pick 549nf34 Comentario de este commit...
pick 3b4r490 Comentario de este commit...

# Rebase aaabbbccc..3b4r490 onto 3b4r490 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop = remove commit
# l, label = label current HEAD with a name
# t, reset = reset HEAD to a label
# m, merge [-C | -c ] [# ]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.


Siguiendo las instrucciones que te muestra el comando en pantalla, en la línea correspondiente al commit 549nf34 sustituyas «pick» por «drop». Guarda y cierra tu editor y el rebase interactivo comenzará a ejecutarse.

Si te salen conflictos (cosa que dependerá de lo que tengas en los commits) resuelvelos, sube los ficheros al staging area con un git add y luego continúa el rebase con git rebase –continue.

Espero haberte resuelto la pregunta y, de nuevo, perdona el retraso.

3b4r4903
549nf34
4m3400
904g4jf4

Si yo quiero eliminar únicamente el 549nf34 pero quiero conservar los demás sin tener que eliminar el primero 3b4r4903 ,4m3400, 904g4jf4 ?

Que comando tengo que usar?

Que es lo que tengo que hacer?

Muchas gracias por la explicación 🙂

Hola Alexander:

Gracias por tu pregunta y perdona que haya tardado tanto en responderte.

Es una buena pregunta y la respuesta depende de cómo estáis trabajando; si usáis pull request o no o si estáis usando rebase o merge, por ejemplo. Por concretar un poco, y asumiendo que utilizas merge y no trabajáis con pull requests, a mi modo de verlo tendrías dos opciones:

1. Mantener la rama hasta que sepas los resultados de las pruebas y el veredicto de QA. Si está todo OK, la borras. Si no, vuelves a la rama, haces los cambios que te piden, negreas de nuevo en develop y esperas los resultados. Vas repitiendo el proceso hasta que esté todo Ok y entonces borras la rama.
2. Cierras la rama y si tienes que hacer modificaciones, creas una nueva rama para implementarlas

Si trabajase en las condiciones que te he indicado arriba, seguramente optaría por la primera opción.

¡Un saludo!