git y flujo de trabajo de C++, cómo manejar archivos de objetos y archivos?

Question

Uso git para interactuar con un repositorio SVN. Tengo varias ramas git para los diferentes proyectos en los que trabajo.

Ahora, cada vez que cambio de una rama a otra usando 'git checkout', todos los ejecutables compilados y los archivos de objeto de la rama anterior todavía están allí. Lo que me gustaría ver es que pasar de la rama A a la B resulta en un árbol con todos los archivos de objetos y binarios de la última vez que trabajé en la rama B.

¿Hay alguna manera de solucionar esto sin crear múltiples repositorios git ?

Actualización: Entiendo que los ejecutables y los binarios no deberían terminar en el repositorio. Estoy un poco decepcionado por el hecho de que todas las ramificaciones en git son inútiles para mí, ya que resulta que tendré que clonar mi repositorio proxy git para cada una de las sucursales que quiero iniciar. Algo que ya hice para SVN y esperaba evitar con git. Por supuesto, no tengo que hacerlo, pero me llevaría a hacer una nueva marca la mayor parte del tiempo después de cambiar de rama (no es divertido).

Answer 1

Lo que desea es un contexto completo, no solo la rama ... que es generalmente fuera del alcance de una herramienta de control de versiones. La mejor manera de hacerlo es usar múltiples repositorios.

No se preocupe por la ineficiencia de eso ... Haga que su segundo repositorio sea un clon del primero. Git usará automáticamente enlaces para evitar tener múltiples copias en el disco.

Aquí hay un truco para darle lo que desea

Puesto que usted tiene directorios obj separado, podría modificar el Makefile para que la ubicación de la base dinámica utilizando algo como esto:

OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'` 
OBJDIR = "$(OBJBASE).obj" 
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj" 
# non-git checkout: OBJBASE == "", OBJDIR == ".obj" 

Eso cambiará el nombre de su sucursal a OBJBASE, que puede usar para construir su ubicación actual de objdir. Dejaré que lo modifique para que se ajuste a su entorno y lo haga amigable para los usuarios que no son Git de sus Makefiles.

Answer 2

Estos archivos no son rastreados por Git o Subversion, por lo que se dejan solos en el supuesto de que son de alguna utilidad para usted.

Acabo de hacer mis compras en diferentes directorios. Me ahorra la molestia de hacer la limpieza.

Answer 3

Esto no es git o svn específico: debe hacer que su compilador y otras herramientas dirijan la salida de archivos intermedios, como archivos .o, a directorios que no están bajo control de versiones.

Answer 4

Puede establecer su compilador IDE para generar todos los archivos temporales privados (.class y así sucesivamente) en <output>\branchName\....

Configurando su configuración de compilación rama por rama, puede registrar el nombre de la bifurcación en la ruta del directorio de salida.

De esta manera, aunque los archivos privados permanecen cuando git checkout, su proyecto en la nueva sucursal está listo para funcionar.

Answer 5

En el directorio de la distribución contrib/git, hay un script llamado git-new-workdir que le permite checkout ramas múltiples en diferentes directorios sin clonar su repositorio.

Answer 6

¡Una limpieza no debería ser necesaria porque los archivos que son diferentes entre las distintas ramas se comprueban con la fecha real!

Esto significa que si su archivo Makefile es correcto, solo aquellos objetos-archivos, libs y ejecutables se vuelven a compilar que realmente cambiaron debido a la finalización de la compra. Cuál es exactamente la razón por la que hay un archivo MAKE en primer lugar.

La excepción es si necesita cambiar las opciones del compilador o incluso compiladores en diferentes ramas. En ese caso, probablemente git-new-workdir sea la mejor solución.

Answer 7

Para mantener varias cajas del mismo repos, puede usar git-workwork. Por ejemplo,

mkdir $BRANCH.d 
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH 

Answer 8

Si los ejecutables compilados son archivos que se han marcado en
continuación alijo git soluciona el problema.

[compile] 
git stash save "first branch" 
git checkout other_branch 
[Fiddle with your code] 
[compile] 
git stash save "second branch" 
git checkout first_branch 
git stash apply [whatever index your "first branch" stash has] 
# alternatively git stash pop [whatever index...] 

Si los ejecutables compilados son archivos que no han y no serán controladas en
continuación, sólo tiene que añadir a .gitignore