2011-03-23 21 views
45

Intenté poner una serie de comandos GIT que siempre utilicé continuamente como archivos de proceso por lotes para no repetir demasiado. Por ejemplo, tengo este archivo por lotes llamado update_repo_branch.bat para actualizar un repo local y sincronizar una rama con la rama remota:¿Cómo ejecuto varios comandos git en un archivo por lotes sin terminar después del primer comando?

@echo off
si (1%) ==() Goto final
si (% 2) ==() Goto extremo
cd% 1
git checkout% 2
git fetch origen
git merge oring /% 2
: fin

Es bueno ser perezoso, pero lo que encontré es que cuando se termina un comando GIT, parece enviar una bandera de salida para terminar lo que esté ejecutando. Por lo tanto, usar un archivo por lotes para ejecutarlos todos de una vez simplemente no funciona. ¿Alguna idea de cómo solucionarlo?

+0

es así, se realiza sólo 'checkout' git? – eckes

Respuesta

55

No estoy seguro de si esto es cierto para todos los paquetes de git de Windows, pero al menos algunos usan una secuencia de comandos git.cmd como un envoltorio alrededor de los ejecutables de git reales (por ejemplo git.exe). Entonces, cuando el archivo por lotes utiliza un comando git, Windows está ejecutando otro archivo por lotes.

Desafortunadamente, cuando un archivo de proceso por lotes invoca a otro, de forma predeterminada 'salta' al archivo de proceso por lotes invocado, nunca regresa (esto es por compatibilidad con antiguos procesadores de comando de MS-DOS o algo así).

Puede resolver este problema en un par de maneras:

  1. invocan git en sus archivos por lotes mediante el comando call para ejecutar el archivo por lotes git.cmd y regresar de nuevo a la suya:

    call git checkout %2 
    call git fetch origin 
    rem etc... 
    
  2. invoque git en su archivo de proceso por lotes usando la extensión .exe explícitamente para evitar el archivo por lotes git.cmd por completo.Para que esto funcione, puede que tenga que asegurarse de que usted tiene su camino y otras variables de entorno establecidas el camino git.exe Espera (que parece ser lo que git.cmd hace en msysgit):

    git.exe checkout %2 
    rem etc... 
    
+5

Dado que 'call' no hace nada inesperado con los programas normales, esta es una buena forma de evitarlo por completo, independientemente de qué' git' usen (ni siquiera sabía que había tantos). – Joey

+1

+1. El comportamiento descrito por el OP es muy probable que confirme el hecho de que 'git' es de hecho un script por lotes. No se espera que un programa 'exe' se comporte así. Y estoy de acuerdo con Joey, 'CALL' no dañará incluso si el programa resultó ser un' exe'. –

+1

Gracias! Eso funciona perfectamente! – Pok

3

Suponiendo que está utilizando msysGit como su cliente de Git, en realidad podría querer usar scripts Bash para esto. Se podría colocar una función fiesta en su ~/.bashrc (~ suele ser C: \ Users \ - see here) de la siguiente

update_repo_branch() { 
    if [ $# != "2" ]; then 
     echo "Usage: update_repo_branch REPO BRANCH" 1>&2 
     return 1 
    fi 

    cd $1 
    git checkout $2 
    git fetch origin 
    git merge origin/$2 
} 

continuación, puede ejecutar update_repo_branch myrepo cool-branch de la cáscara mysysGit.

Por supuesto, esto no será accesible desde cmd.exe. Solo podrá usarlo dentro del shell msysGit cygwin.

3

como veo de su ejemplo en realidad estás tratando de sincronizar su rama local de 'BRANCHNAME' con origen/BRANCHNAME

para ello no es necesario crear ningún script adicional, sólo hay que utilizar git pull en lugar de la secuencia git checkout branchname; git fetch origin; git merge origin/branchname

eche un vistazo a los documentos sobre seguimiento de sucursales en git y sus beneficios.

en términos generales, si se tiene un esquema de recompra así:

git branch -a 
... 
master 
dev1 
dev2 
remotes/origin/master 
remotes/origin/dev1 
remotes/origin/dev2 

Y su dev1 y ramas dev2 son el seguimiento de las ramas de origen/dev1 y origen/dev2 correspondientemente a continuación, sólo tiene que ejecutar en el repositorio:

git pull 

Este comando sincronizará eficazmente todas las ramas locales de seguimiento con las remotas.

para más ver aquí:

Git pull docs

Git remote branches and tracking branches (Progit book)

Cuestiones relacionadas