lidiando con git

• online book
• cheat sheet

repositorio nuevo

make <dir>.git
cd <dir>.git
git init --bare
cd ..
scp -r <dir>.git chafar.net:git
git clone chafar.net:git/<dir>.git
rm -r <dir>.git

repositorio de algo que ya se tiene

cd <dir>
git init
cd ..
git clone --bare <dir> <dir>.git
scp -r <dir>.git chafar.net:git
mv <dir> <dir>.tmp
git clone chafar.net:git/<dir>.git
cd <dir>
cp ../<dir>.tmp/<lo-que-interese> .

... y en algún momento sobrará .tmp ... QUIZÁ un guión bash que haga precisamente esto

clonando

git clone chafar.net:git/{loquesea}.git

... esta sintaxis es la de scp y no acepta prefijo ssh://, lo mas parecido con prefijo ssh sería

git clone ssh://chafar:net/~chafar/git/{loquesea}.git

rameando

el problema que me suele ocurrir con esto es que en medio de trabajar
en rama de feature me sale arreglar otra cosilla y en lugar de volver a master
lo hago en la rama de feature, y la liamos: lo IMPORTANTE es ser CONSCIENTE de
en qué rama estas y si mola hacer lo que sea en esa rama o no mola nada.

git branch <name> crea una nueva
git switch <name> cambia a esa rama
... trabajas en ello y si necesitas volver a master dejas todo commit o stashed
git switch master
... haces lo que haya que hacer en master y commit
git switch <name>
... mas trabajo
git commit
... y para consolidarlo en master:
git switch master
git merge <name>

aliases de commits

aki

• último (o actual) commit: HEAD
• n commits ago: p.e. HEAD~2
• branchname: p.e. master
• commit_id: p.e. 3e887ab

squashing

para hacer merge de una rama dev, o topic, simplificando el historial en un solo commit,
una vez hecho el trabajo en dev / topic:

git switch master
git merge --squash dev / topic  --> deja todos los cambios staged para el commit
git commit

github

Curiosamente, parece no haber ningún mecanismo propio en github para hacer pull del repositorio del que has cloneado el tuyo. Eso plantea el poblemo de que si estas haciendo algo que en su momento pueda ser objeto de una pull request al repositorio original, has de hacerlo desde tu copia de trabajo en tu máquina, donde tu repositorio github suponemos que es origin y al original lo llamamos upstream:

git remote add upstream <url-del-repositorio-origen>
git fetch upstream

lo vas actualizando con:

git pull upstream master

y lo reflejas en github con:

git push

SVN

Para importar repositorio de svn, como yo tengo los proyectos agrupados en repositorios svn, hay que importar solo parte del repositorio. Con esto funciona (el repositorio es trabajos, y queremos la rama chafar/cnet en repositorio git cnet):

git svn clone --authors-file=users.txt --trunk=chafar/cnet/trunk svn+ssh://chafar.net/home/chafar/svn/trabajos cnet

en chafar.net:

cd ~/dev
git --bare init cnet.git

y de nuevo en local:

cd cnet
git remote add origin chafar@chafar.net:git/cnet.git
git push --set-upstream origin master

sparse-checkout

en un repositorio sparse_checkout, solo se traen cosas escogidas del repositorio remoto; se gestiona mediange 'git sparse-checkout ...' y básicamente puedes hacer: git sparse-checkout add dir[/dir[/dir...]] para traerte las zonas que te interesen

módulos (https://git-scm.com/book/en/v2/Git-Tools-Submodules)

Para añadir un repositorio git como submódulo:

git submodule add URL

para inicializar en los clones:

git submodule update --init modulo

para actualizar:

git submodule update --remote module (equivalente a cd module; git pull; cd ..)

para que git status informe algo de los submódulos:

git config status.submodulesummary 1

para que cuando haces push el proyecto te avise si tienes cambios sin publicar en el módulo:

git config push.recurseSubmodules check

... y cuando te avisa, para hacerlo cómodo puedes hacer:

git push --recurse-submodules=on-demand

y por último, decir que en el capítulo correpondiente del book de git (https://git-scm.com/book/en/v2/Git-Tools-Submodules) hay buena info para cosas mas elaboradas, como branches en el submódulo y demas.