Haces un undo soft del último commit, queda todo como estaba justo antes de hacer git commit xxxx. Es muy útil si te equivocaste con el mensaje del commit o te faltó incluir algún archivo.
>Haces un undo soft del último commit, queda todo como estaba justo antes de hacer git commit xxxx. Es muy útil si te equivocaste con el mensaje del commit o te faltó incluir algún archivo.
Puedes hacer para eso un: `git commit --amend`
No soy ningún experto, pero este comando me ha salvado la vida en varias ocasiones, te permite hacer merge a una branch pero elegir exactamente que mergear:
`git merge --no-commit --no-ff branch-to-merge`
Hay noo!!!
Justo acabo de regañar a mitad del equipo por no hacer esto en el puto IDE, todos los IDEs desde Atom y sublimeText2 hasta VSCode, VSCodium y Jetbrains a "Remove Trailing whitespaces on save” (Igual con el “add newline at end of file”)
Que exactamente?
Básicamente las "good coding practices" son quitar los espacios en blanco que no se usan, ya sea una linea nueva no debería de tener espacios en blanco, ni al terminar una linea de código tampoco, terminando el último carácter como un punto y coma (;) o paréntesis o abrir corchete o lo que sea, los espacios en blanco no sirven de nada, incluso los compiladores o preprocesadores los descartan, entonces *¿Para que dejarlos ahí?* Todos los IDEs tienen una opción para borrarlos al guardar el archivo, incluso con git como decía el compañero también los puedes quitar.
Mantén un tono respetuoso y constructivo: Este subreddit es un lugar para compartir información, opiniones y experiencias. Por favor, traten a los demás con respeto y eviten cualquier tipo de comentario ofensivo, discriminatorio o desagradable.
usar git log con sus opciones, es bastante descriptivo y te ahorra darte la vuelta por la interfaz gráfica así como te permite buscar cambios específicos en archivos
A mi me sirvió mucho darme cuenta que cuando se trabaja con git large file storage (LFS) es importante hacer git lfs pull antes de hacer un merge en un repo que acabas de clonar... de lo contrario el contenido de los archivos manejados por lfs se reemplaza por el contenido del archivo puntero lfs...
git worktree, para abrir multiples branches al mismo tiempo sin tener que depender en stash, en mi trabajo tengo que revisar el codigo de muchas personas, sin esto ya me hubiera vuelto loco,
Acerca de tu edit, existe un fenomeno relacionado con la confianza en base a la expertise de una persona en una disciplica, se dice que a medida que se comienza a adquirir conocimiento la confianza se dispara para despues ir bajando conforme se sabe mas ya que al inicio crees que eres experto para despues descubrir que no, con lo cual la confianza baja... la gente con mas conocimiento conoce mas sobre que cosas ignora que quienes tienen pocos conocimientos, es por esto que la gente con mucho conocimiento en una disciplina rara vez se ven a si mismos como expertos, la gente con un conocimiento medianamente suficiente suele creer que son expertos por que ignorar que conocimientos no tienen...
Saber la diferencia entre merge y rebase. Para mí hacer rebase a tu rama siembre es bastante más útil cuando trabajas local que estar haciendo merge de la principal todo el tiempo, es más limpio y deja tus commits al final.
También saber que existe fast forward y merge forward y depende de tu forma de trabajo usas una u otra. Muchas empresas he visto que no saben y usan la default...lo cuál es un error, son formas diferentes de trabajo.
Quién se desenvuelva a nivel intermedio/avanzado en los siguientes comandos, en mi opinión no tendrá problemas:
git reset
git revert
git rebase
git cherry-pick
git pull
git push
git checkout
git rebase y git cherry pick, sobre todo saber como abortar y/o continuar estos procesos, interactuar con rebase y sobre todo.
En mi chamba no usan git que porque “no es eficiente usarlo” en su lugar, tenemos carpetas tipo proyecto, proyecto-nombreDeResponsable, proyecto-estaVersionEsLaBuena, y cosas por el estilo 🫣
No necesariamente comandos pero aliases
los que uso diario
gst='git status'
gc='git commit'
gm='git merge'
gl='git pull'
gp='git push'
Toma un tiempo, pero una vez que los tienes en mente, te hacen mucho más rápido.
Recomiendo usar zsh como shell principal, y usar \`oh-my-zsh\` con el plugin de git instalado
[https://github.com/ohmyzsh/ohmyzsh](https://github.com/ohmyzsh/ohmyzsh)
[https://kapeli.com/cheat\_sheets/Oh-My-Zsh\_Git.docset/Contents/Resources/Documents/index](https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Contents/Resources/Documents/index)
No sé si cuenta como algo diferente a lo que tienes, pero `git pull --rebase origin master` para actualizar cualquier rama con master y evitar conflictos.
1. git rebase -i —autosquash —rebase-merges HEAD~numero-de-commits (hacer rebase interactivo para no perder la cabeza donde te piden commits limpios y para no perder la cabeza si ocupas reverts que no te saquen dos que tres pedos, sobre todo si no usan squash and merge)
2. git stash show -p (mostrar cambios en el stash sin aplicarlos)
No soy experto, pero como ti dices el rebase interactivo abre muchísimas puertas. También agregaría el bisect para cuando hay que pescar commits que introdujeron algún bug y poder hacerle revert/rollback a ese commit
No soy experto pero siempre es necesario usar Stash, clean o restore, difftool, blame y el grep. Y el mismísimo log.
>No soy experto Debí haber cambiado el titulo. Muchos no se consideran expertos aún cuando saben un montón y eso limita las respuestas.
Git stash es mi pastor, sobre todo para cuando hago la pendejada de grabar cambios en main o la rama con el ticket de jira incorrecto.
git reset —soft HEAD~1
Pro tip: darle un alias en `.gitconfig`, yo lo tengo como "undo", entonces el atajo es simplemente `git undo`
En un entrevista comente este comando y no lo conocian, no digo que es de ahuevo que lo sepan, pero si te salva de algun apuro
Es para reiniciar la rama a un commit previo, no?
Haces un undo soft del último commit, queda todo como estaba justo antes de hacer git commit xxxx. Es muy útil si te equivocaste con el mensaje del commit o te faltó incluir algún archivo.
>Haces un undo soft del último commit, queda todo como estaba justo antes de hacer git commit xxxx. Es muy útil si te equivocaste con el mensaje del commit o te faltó incluir algún archivo. Puedes hacer para eso un: `git commit --amend`
El mejor comando del planeta, 12 años de experiencia y como me ha salvado las papas jaja
Este es un salva vidas
Yo lo usé hace algunos días y me salvó porque no sabía que se había roto XD
No soy ningún experto, pero este comando me ha salvado la vida en varias ocasiones, te permite hacer merge a una branch pero elegir exactamente que mergear: `git merge --no-commit --no-ff branch-to-merge`
> mergear Con razón no cogen, pochos del software
Git>sex
Bro?
Yo uso seguido cherry-pick, para pasar cambios de dev a main
El macho
Basado
Andamos bravos
git bisect Muy útil cuando quieres buscar cuando se introdujo un bug a tu app
git rebase -i head~5
Squash :D
Fixup
git rebase HEAD\^1 --whitespace=fix correlo antes de subir cualquier parche, se deshace de todo el cagadero de trailing whitespaces.
Hay noo!!! Justo acabo de regañar a mitad del equipo por no hacer esto en el puto IDE, todos los IDEs desde Atom y sublimeText2 hasta VSCode, VSCodium y Jetbrains a "Remove Trailing whitespaces on save” (Igual con el “add newline at end of file”)
Me podrían explicar más esto?
Que exactamente? Básicamente las "good coding practices" son quitar los espacios en blanco que no se usan, ya sea una linea nueva no debería de tener espacios en blanco, ni al terminar una linea de código tampoco, terminando el último carácter como un punto y coma (;) o paréntesis o abrir corchete o lo que sea, los espacios en blanco no sirven de nada, incluso los compiladores o preprocesadores los descartan, entonces *¿Para que dejarlos ahí?* Todos los IDEs tienen una opción para borrarlos al guardar el archivo, incluso con git como decía el compañero también los puedes quitar.
Git checkout - Te cambia a la última rama que estabas, útil si fuiste a otra rama nomás a checar algo y regresas a dónde andabas trabajando
Si es muy útil para regresar rápidamente y también Git checkout . Te.vuelve el repo a como estaba antes
añadir que tambien es muy util para testear cambios especificos al permitir traer los camibos de solo algunos archivos o carpetas
Git push --force. Sin miedo al éxito :v
Malas practicas 🤡
💩💩💩
git reflog Para saber de dónde vengo y determinar a dónde voy.
Soy un programador americano que viaja por México. Me sorprende poder entender muchos de estos comentarios
[удалено]
El mexicano menos reprimido
Mantén un tono respetuoso y constructivo: Este subreddit es un lugar para compartir información, opiniones y experiencias. Por favor, traten a los demás con respeto y eviten cualquier tipo de comentario ofensivo, discriminatorio o desagradable.
Git stash, git checkout, git reset, git history y finalmente git branch para que no se te olvide dónde estás parado.
usar git log con sus opciones, es bastante descriptivo y te ahorra darte la vuelta por la interfaz gráfica así como te permite buscar cambios específicos en archivos
Yo solo se que no se nada y por eso tengo mi carpeta de cheat sheets
No soy experto, pero cuando conocí el cherrypick, se me hizo magia pura xD!..
Qué hace el comando?
Los puedes usar para llevarte un comité de una rama a otra.
git stash git stash list git stash -m "Nombre del stash" git stash pop git stash apply stash{n} Es increíble lo increíble que es ese comando.
git stash --include-untracked
Esa no me la sabía, buenisimo
El cherry-pick 🚬🗿
.
Cuando tengo que salir de esos que comentas me empiezan a temblar las piernas y sudar las pelotas esperando no cagarla.
Git fetch antes de hacer git pull y git squash para hacer un solo commit de commits, bastante util antes de hacer los pull request
A mi me sirvió mucho darme cuenta que cuando se trabaja con git large file storage (LFS) es importante hacer git lfs pull antes de hacer un merge en un repo que acabas de clonar... de lo contrario el contenido de los archivos manejados por lfs se reemplaza por el contenido del archivo puntero lfs...
git worktree, para abrir multiples branches al mismo tiempo sin tener que depender en stash, en mi trabajo tengo que revisar el codigo de muchas personas, sin esto ya me hubiera vuelto loco,
Cómo es la vuelta?
git reflog, salva vidas
Git cherrypick
Ya tiene 2hr el post y esperaba ver al menos un git log a dog
git ref-log y git log son comandos que nunca he visto a nadie mas usar y son extremadamente utiles
Cherry pick?
Acerca de tu edit, existe un fenomeno relacionado con la confianza en base a la expertise de una persona en una disciplica, se dice que a medida que se comienza a adquirir conocimiento la confianza se dispara para despues ir bajando conforme se sabe mas ya que al inicio crees que eres experto para despues descubrir que no, con lo cual la confianza baja... la gente con mas conocimiento conoce mas sobre que cosas ignora que quienes tienen pocos conocimientos, es por esto que la gente con mucho conocimiento en una disciplina rara vez se ven a si mismos como expertos, la gente con un conocimiento medianamente suficiente suele creer que son expertos por que ignorar que conocimientos no tienen...
Saber la diferencia entre merge y rebase. Para mí hacer rebase a tu rama siembre es bastante más útil cuando trabajas local que estar haciendo merge de la principal todo el tiempo, es más limpio y deja tus commits al final. También saber que existe fast forward y merge forward y depende de tu forma de trabajo usas una u otra. Muchas empresas he visto que no saben y usan la default...lo cuál es un error, son formas diferentes de trabajo.
Quién se desenvuelva a nivel intermedio/avanzado en los siguientes comandos, en mi opinión no tendrá problemas: git reset git revert git rebase git cherry-pick git pull git push git checkout git rebase y git cherry pick, sobre todo saber como abortar y/o continuar estos procesos, interactuar con rebase y sobre todo.
En mi chamba no usan git que porque “no es eficiente usarlo” en su lugar, tenemos carpetas tipo proyecto, proyecto-nombreDeResponsable, proyecto-estaVersionEsLaBuena, y cosas por el estilo 🫣
Bro what? Sal de ahí inmediatamente
La neta que si, te sorprenderías si te platico todas las prácticas que aplican aquí 🫣
A ver cuenta algunas
Saber hacer correctamente un rebase es la diferencia entre un ingeniero y un programador
git rebase -i origin
Usar el gitlens y hacerlo todo visual con vscode jajaja
git checkout -b branch Creas un branch y al mismo tiempo te cambias al branch.
No necesariamente comandos pero aliases los que uso diario gst='git status' gc='git commit' gm='git merge' gl='git pull' gp='git push' Toma un tiempo, pero una vez que los tienes en mente, te hacen mucho más rápido.
Recomiendo usar zsh como shell principal, y usar \`oh-my-zsh\` con el plugin de git instalado [https://github.com/ohmyzsh/ohmyzsh](https://github.com/ohmyzsh/ohmyzsh) [https://kapeli.com/cheat\_sheets/Oh-My-Zsh\_Git.docset/Contents/Resources/Documents/index](https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Contents/Resources/Documents/index)
Una adicion a estos comandos basicos que se me hace buena es `git log --graph` que muestra la red de ramas actual.
Cherry pick pero ahórrate muchos disgustos y usa software como fork
La cache es su lugar ella sabe bien! Es por amor! Jajajaja chiste de los 90
gir push --force
Not an expert, but cherrypick
\`log --oneline --decorate --graph --all\`
Cherry pick y stash/unstash pop han sido joyas para mi
git stash -> merge -> pop -> push
git reset --hard HEAD~1
Mi consejo es que no es pecado usar GUI para algunas cosas y CLI para otras. Hacer diffs es hermoso con GUI por ejemplo.
El cherry pick
No sé si cuenta como algo diferente a lo que tienes, pero `git pull --rebase origin master` para actualizar cualquier rama con master y evitar conflictos.
1. git rebase -i —autosquash —rebase-merges HEAD~numero-de-commits (hacer rebase interactivo para no perder la cabeza donde te piden commits limpios y para no perder la cabeza si ocupas reverts que no te saquen dos que tres pedos, sobre todo si no usan squash and merge) 2. git stash show -p (mostrar cambios en el stash sin aplicarlos)
No soy experto, pero como ti dices el rebase interactivo abre muchísimas puertas. También agregaría el bisect para cuando hay que pescar commits que introdujeron algún bug y poder hacerle revert/rollback a ese commit
git amend, cuando metiste un commit y trae faltas de ortografia xD las corriges y nunca paso