tag remove practices crear best git

remove - ¿Servidor Git como GitHub?



git tag best practices (19)

Bare Bones Browser

git instaweb --httpd=webrick

del libro git scm

combínelo con algo como el enfoque descrito here para el desarrollo distribuido (crédito a datagrok por el concepto bien descrito)

Inicie un único servidor git desde cualquier repositorio local.

He twitteado esto ya, pero pensé que podría usar algo de expansión:

Habilitar el flujo de trabajo de git descentralizado: git config alias.serve "daemon --verbose --export-all --base-path = .git --reuseaddr --strict-paths .git /"

Supongamos que utiliza un flujo de trabajo de git que implica trabajar con un repositorio "oficial" central desde el que extrae e inserta sus cambios desde y hacia. Estoy seguro de que muchas compañías hacen esto, al igual que muchos usuarios de servicios de hosting git como Github.

Digamos que el servidor, o Github, baja un poco.

No se preocupe, después de todo, una de las razones por las que usa git es que tiene una copia del historial completo del proyecto en su clon local.

Puede seguir codificando y comprometiéndose, mientras espera que el equipo de operaciones le dé vida al servidor. Nota para uno mismo: comprar donas para el equipo de operaciones.

Pero, ¿qué pasa si, durante este tiempo de inactividad, desea colaborar con otra persona, que puede no ser un experto en git, en el mismo repositorio?

O, en lugar del tiempo de inactividad, ¿qué pasa si usted y su colaborador están en el campo y, por alguna razón, no puede hacer que su VPN le permita conectarse a su repositorio oficial?

O, ¿qué pasa si usted y su colaborador están llevando a cabo una serie de cambios experimentales, y aunque tenga acceso, no desea introducir su desastre sin terminar en el repositorio central oficial? (Ni siquiera como ramas características). Tal vez esté en el medio de limpiar una rebase o fusión desastrosa y las ramas estén por todas partes.

Bueno, Git, como probablemente sepa, es un here .

A pesar de que puede usar un repositorio central de git "oficial" en su flujo de trabajo, aún tiene la capacidad de usar git de una manera de igual a igual, donde usted y su colaborador simplemente crean y comparten compromisos entre sí, y la central El servidor ni siquiera tiene que saberlo.

Entonces, ¿cómo obtienes tus ramas y te comprometes con ellas, o viceversa?

  • Podrías usar las instalaciones de git para enviar parches por correo electrónico. Pero eso es un poco poco elegante y requiere cierto conocimiento sobre cómo aplicar los parches enviados por correo electrónico.
  • Puede crear una cuenta en su propia máquina para que su colaborador la pueda enviar. Pero tal vez no tenga acceso a la raíz local, o tal vez no confíe en ellos con acceso SSH a su caja.
  • Podrías clonar tu repo en una unidad de mando y pasarlo de un lado a otro. Pero eso es bastante tedioso, especialmente si está en la misma red local y requiere una unidad de disco USB.

Probablemente puedas pensar en otros métodos, también. Pero hay una manera muy fácil: si se pueden ver en la red, puede iniciar un único servidor Git que pueden usar como control remoto para clonar, recuperar y extraer los cambios, y eliminarlo cuando esté hecho con eso

La herramienta que lo habilita es git daemon , que tiene muchas opciones y funcionalidad, pero con el propósito de habilitar este sencillo "solo sirve el repositorio en el que estoy", la forma de usarlo es crear un alias. Me gusta llamarlo git serve . Correr:

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Usar un alias es realmente crucial, porque los alias de git se ejecutan en el directorio base de su árbol de trabajo. Por lo tanto, la ruta ''.git'' siempre apuntará al lugar correcto, sin importar dónde se encuentre dentro del árbol de directorios de su repositorio.

Utilice su nuevo git serve como así:

  1. Ejecutar git serve . "Listo para retumbar", informará. Git es malo.
  2. Encuentra tu dirección IP. Digamos que es 192.168.1.123.
  3. Diga "hey Jane, no estoy listo / capaz de empujar estos compromisos hasta el origen, pero puedes recuperar mis compromisos en tu clon ejecutando git fetch git://192.168.1.123/ "
  4. Presione ctrl + c cuando ya no quiera servir ese repositorio.

También puede decirle a Jane que git clone git://192.168.1.123/ local-repo-name si aún no tiene un clon del repositorio. O bien, use git pull git://192.168.1.123/ branchname para realizar una búsqueda y combinación a la vez, útil si están trabajando juntos en una rama de función.

Sin embargo, tenga en cuenta que no debe hacer esto en redes hostiles si guarda secretos en su repositorio, porque no hay autenticación. No anuncia su existencia, pero cualquier persona con un escáner de puertos puede encontrarlo, conectarse a él y clonar su repositorio.

Pero no es muy peligroso porque es de solo lectura por defecto. Lea la página de manual de git daemon cuidadosamente si cree que desea habilitar el acceso de escritura. En el caso de que desee obtener las confirmaciones de su colaborador, es mucho más seguro dejarlo en modo de solo lectura, y pedirle a su colaborador que también ejecute este comando, para que pueda extraerlo.

Relacionado tangencialmente: sobre el tema de servidores de uso único, si desea compartir temporalmente un montón de archivos estáticos a través de HTTP: python -m SimpleHTTPServer

Soy un usuario de Subversion desde hace mucho tiempo que va a probar Git. He leído algo al respecto y entiendo la naturaleza distribuida; puedo ver muchos de los beneficios.

Sin embargo, me gusta la idea de un servidor central que pueda asumir el rol de copias de seguridad, sistema de registro, etc., mientras sigue usando Git para mi bifurcación y uso compartido local. No estoy haciendo un proyecto de código abierto, así que no puedo usar Github (sin pagar), por lo que mi pregunta realmente es: ¿cuál es la mejor manera de ejecutar un servidor Git local?

Me doy cuenta de que esto puede ir en contra del patrón de uso estándar de Git, pero será útil para mi proyecto. Sin embargo, cualquier inquietud que pueda haber pasado por alto siempre es bienvenida.

¡Gracias!

Mientras tanto, el sitio de alojamiento Mercurial Bitbucket también ha comenzado a ofrecer repositorios Git.

Entonces, si no necesita un servidor local , solo un lugar central donde puede alojar repositorios Git privados de forma gratuita, IMO Bitbucket es la mejor opción.

De forma gratuita, obtiene un número ilimitado de repositorios privados y públicos de Git y Mercurial.
La única limitación es que en el plan gratuito, no más de cinco usuarios pueden acceder a sus repositorios privados (para obtener más, debe pagar).
¡Vea https://bitbucket.org/plans para más información!

Para agregar a lo que Chris ha dicho, puede usar gitosis (http://eagain.net/gitweb/?p=gitosis.git) para controlar quién puede acceder al repositorio.

Dependiendo de su uso, también puede usar hooks (en la carpeta .git / hooks) para que su código se introduzca automáticamente en el sistema de archivos del servidor cuando empuja desde su máquina local. Aquí hay un script popular para hacer eso: http://utsl.gen.nz/git/post-update . Sin embargo, esto no será necesario en todos los casos.

Prueba http://gitlab.org/

La mejor herramienta de git GUI que he usado. Es muy similar a GitHub.

Es de código abierto (licencia MIT) y es el software de administración de git más instalado con más de 25.000 instalaciones. Cuenta con lanzamientos mensuales y una comunidad activa con más de 375 colaboradores. Puede tener un número ilimitado de repositorios privados, internos y públicos en su propio servidor. Es una aplicación de Ruby on Rails que se ejecuta en la mayoría de las plataformas Unix.

Puede considerar http://gitblit.com/ , un servidor de Visor y repositorio Java Git de código abierto, integrado y puro para grupos de trabajo pequeños.

Puede que no sea ​​la configuración del servidor git más común , pero habiendo jugado con diferentes esquemas de diseño, herramientas, creación de reflejos y permisos, diría que una alternativa bastante sólida para los repositorios empresariales es Gerrit , que puede parecer sorprendente ya que es más conocido como Herramienta de revisión de código. Comenzamos a usarlo como código de revisión y lentamente se convirtió en nuestro repositorio principal, desechando g3 / gitolite

  • Es fácil de implementar (básicamente, sueltas el .war en un tomcat)
  • tiene una interfaz de usuario web para administrar repositorios, grupos y permisos (o un cli de ssh)
  • tiene una implementación java ssh y git incorporada, por lo que no tiene nada más que configurar
  • Compatibilidad con ldap para usuarios y grupos (generalmente una necesidad para las empresas)
  • un sistema de permisos muy flexible (con grupos de proyectos, herencia de permisos, restricciones de lectura / escritura / ramificación / escrituras no revisadas / etc)
  • capacidades de revisión de código (si te gusta esa cosa)
  • duplicación de repositorio (para enviar algunos repositorios a github u otro repositorio público)

Además, es utilizado por grandes proyectos (por ejemplo, Android, Chrome), por lo que hace escalas y ahora es bastante sólido. Simplemente otorgue a sus usuarios el permiso PUSH si desea permitir omitir la parte de revisión de código.

Si desea solicitudes de extracción, existen los proyectos de código abierto de RhodeCode y GitLab y el Stash pagado.

Si necesita un servidor GIT bueno y fácil, debe probar GitBlit. También utilizo gitolite pero solo servidor, con GitBlit obtienes todo en uno, servidor, administrador, repos. gerente ... URL: http://gitblit.com/

Si no le importa ponerse gitolite con la línea de comandos, gitolite es un tratamiento absoluto cuando trabaja en un entorno corporativo en el que necesita establecer diferentes derechos de acceso en diferentes repositorios. Es una especie de nueva versión de gitosis mencionada por @Chris.

Aquí está el resumen del sitio web del autor:

Gitolite le permite usar un solo usuario en un servidor para alojar muchos repositorios de git y proporcionar acceso a muchos desarrolladores, sin tener que darles permisos de usuario reales o acceso de shell al servidor. La magia esencial para hacer esto es el acceso pubkey de ssh y el archivo authorized_keys, y la inspiración fue un programa antiguo llamado gitosis.

Gitolite puede restringir quién puede leer (clonar / buscar) o escribir (empujar) un repositorio. También puede restringir quién puede empujar a qué rama o etiqueta, lo cual es muy importante en un entorno corporativo. Gitolite se puede instalar sin requerir permisos de root, y sin software adicional que git y perl.

Tiene un conjunto de características bastante completo, pero una cosa que me gusta mucho es que toda la edición del día a día de la configuración se realiza a través de un repositorio especial de git. Es decir, agregar un usuario es solo

  • Añadir usuario al archivo de configuración
  • Añadir la clave ssh del usuario
  • Cometer el cambio
  • Empújalo a gitolita
  • Voila, la configuración está en vivo!

Y cuando se necesita mirar el código a través del navegador, gitolite tiene soporte para "sincronizar" la configuración con gitweb. O si te gusta cgit , que es una muy buena interfaz web para git escrita en C, mejor, entonces deberías ver este cgit .

Si solo quieres tu repositorio en un lugar central, esto es bastante fácil con el control de versiones distribuido como Git:
Simplemente puede poner su repositorio central en alguna carpeta compartida en una máquina central y todos pueden clonarlo desde allí.

Si desea un sitio web "real" en su servidor local, conozco el sitio web de hosting Git http://repo.or.cz .
Parece tener menos funciones que GitHub, pero a diferencia de GitHub, puede obtener el código fuente y alojarlo en su propio servidor local.

Descargo de responsabilidad: solo leí sobre repo.or.cz, ¡nunca lo probé yo mismo!

Simplemente puede configurar un servidor ssh y ejecutar un repositorio central allí. Luego, todos los desarrolladores simplemente acuerdan (como una cuestión de política) empujar al servidor cuando hayan terminado de confirmar. Este es el patrón de uso en mi lugar de trabajo. Muy CVS y como SVN.

  1. Encuentre un lugar para colocar el repositorio (por ejemplo, /var/gitroot ).
  2. Cree un nuevo repositorio ( mkdir project.git && cd project.git && git init --bare --shared=group ).
  3. Luego, en su cliente, clone el repositorio remoto ( git clone ssh://yourserver.com/var/gitroot/project.git && cd project )
  4. agregar algunos archivos ( git add README )
  5. commit ( git commit -m "Initial import" ),
  6. push ( git push origin master )

Esto debería establecer las cosas para usted.

También puede instalar Indefero , es un clon GPL de GoogleCode, ya que admite tanto Subversion como Git, puede tener una transición sin problemas. Soy el autor de Indefero.

para configuraciones simples, puede proporcionar acceso ssh a un servidor central, y configurar el directorio de trabajo de cada usuario para empujar / tirar desde este ''origen''. Esa sería la configuración más simple y común para equipos pequeños.

También puede buscar gitosis, que le brinda un servidor http y la capacidad de administrarlo de forma remota. De esa manera, no tiene que otorgar el acceso a ssh y todo lo que conlleva a cada interlocutor.

RhodeCode es una aplicación web de código abierto para Git & Mercurial que se puede instalar fácilmente en cualquier sistema operativo (se incluye un instalador).

RhodeCode (la nueva versión se llama RhodeCode Enterprise) agrega características de Git que faltan, como la revisión de códigos, y en general es muy rápido y confiable.

Para un alojamiento remoto Como otros han dicho, bitbucket.org ofrece repositorios privados gratuitos, lo he estado usando sin problemas.

Para la red local o LAN, scm-manager.org este scm-manager.org (un solo archivo ejecutable, es realmente simple de instalar, está hecho en Java para que pueda ejecutarse en Linux o Windows). En caso de que lo instale, estas son contraseñas predeterminadas.

Username: scmadmin Password: scmadmin