El software Can Git (por ejemplo, Gitbox, Github, SourceTree) utiliza un repository remoto en lugar de local?

Me gusta usar el software Git para enviar confirmaciones, pero las que uso (Gitbox, Github, SourceTree) todas solicitan un repository local cuando les agrego un nuevo repository.

La cosa es que mi repository está en mi server de desarrollo, no en mi máquina local.

Entonces, ¿el software de Git puede usar un repository remoto de Git como repository de desarrollo, y luego enviarlo a su repository principal (por ejemplo, Github o Bitbucket)?

De lo contrario, parece que no puede usar el software y tiene que recurrir a la command-line a través de SSH.

Gracias

Una solución, que no depende del front-end para soportar la manipulación de un repository remoto directamente, sería montar el control remoto como un sistema de files en networking. Si solo tiene acceso SSH a la máquina remota, puede intentar usar SSHFS a través de FUSE (en Linux) o OSXFUSE en Mac OS X. O según sus preferences y configuration, puede usar SMB, NFS, DAV u otro sistema de files de networking .

Otra forma de hacerlo, que menciono en los comentarios, es exportar el sistema de files de networking de su máquina de desarrollo a su server. Hago esto para poder montar mi copy de trabajo actual en múltiples máquinas a la vez, y también para tener mi copy de trabajo local incluso cuando no estoy conectado al server.

Usted escribe:

Me sorprende que el software de Git no pueda tratar con repos remotos como la versión de trabajo.

La mayoría de las GUI de Git hacen parte de su trabajo llamando al command git . Para que admitan la operación remota, core Git también debería hacerlo. Está escrito en una mezcla de C y script de shell; todo eso tendría que ser reescrito para hacer frente a los files remotos.

Un editor de text tiene un trabajo mucho más fácil; lee un file cuando lo abre y lo escribe cuando lo guarda, mientras que Git lee y escribe muchos files en el transcurso de una sola operación, como commit .

Un sistema de files en networking significaría que todas las herramientas (Git y demás) funcionarán en sus files remotos. En lugar de crear una capa en todas y cada una de las aplicaciones para admitir el acceso a files en networking, hacerlo en el kernel (o mediante FUSE) y luego tratarlo como un sistema de files local le da ese soporte en cada aplicación de forma gratuita.

Recuerde, Git es un DVCS . El hecho de que no se conecte a un server remoto para enviar material es por layout .

Lo que quiere hacer es tener repositorys Git locales que envíen el código a su server de integración (el que realmente ejecuta el código). Es como implementar, solo se implementa en un server de testing en lugar de en producción.

Esto normalmente se logra teniendo un repository compartido de Git al que presionas. Este repository debe estar al descubierto . Además del repository compartido simple, querrás un clon no desnudo del repository compartido de Git que servirá como tu docroot de Apache.

Cuando el repository compartido recibe una confirmación, hará que el repo del docroot ejecute la git pull .

Esto se puede lograr utilizando anzuelos post-recepción en el repository compartido.

El repo de docroot se verifica en una twig específica (digamos develop ). Entonces, incluso si comprometes cosas en otras twigs y las presionas, el server no se verá afectado.

Esto le permite configurar varios repositorys de implementación, por lo que podría tener otro prod asociado de twig asociado con uno de los que realmente actualizaría el código de producción cuando inserte cosas en él.

También le permite almacenar trabajo incompleto / continuo en una sucursal compartida que no se implementa en absoluto, para que sepa que lo que ha estado trabajando en su computadora portátil está a salvo en el repository compartido, aunque puede hacerlo ". Se enviará al server de testing porque no está completo y rompería el server de testing, haciendo que otras personas no puedan trabajar o algo así.

Este artículo explica en detalle cómo configurar todo eso. Lo he hecho antes, funciona bien.

Encontré una manera fácil para mí: en Transmitir (cliente FTP) hay una opción para 'Montar favorito como disco'. SourceTree puede funcionar como se espera con este disco "virtual".

Sin embargo, una limitación: puede montar el disco e iniciar SourceTree solo después de que haya hecho todos los cambios en el código y esté listo para hacer commit / push, no funcionará si mantiene el SourceTree y el disco ssh montados mientras trabaja en el código. Por alguna razón, el disco montado por Transmitir no actualiza el contenido de los files en vivo, sino solo después de desmontar / montar la acción.

Tuve este problema exacto hace aproximadamente un año. Desafortunadamente no pude encontrar ninguna respuesta consistente y confiable. Busqué en Google durante semanas, pensando que fueron mis términos de búsqueda los que no tuvieron éxito, intentando de todas forms.

[La configuration que teníamos era que cada desarrollador tenía su propio server de desarrollo: tenerlos separados de las máquinas significaba que los sitios podían desarrollarse en cualquier lugar, los serveres de desarrollo podían configurarse para ser exactamente los mismos que los entornos en vivo y el administrador del sistema podía mantenerlos actualizados y respaldado – veo la ventaja de tener un server de desarrollo separado para la máquina en funcionamiento, ¡con una de las pocas desventajas de no tener aplicaciones git!]

Todo lo que dependa de los assemblys de files o suplantando a su computadora para que piense que un disco remoto es local está bien para la exploración general de files, pero las aplicaciones de Git tienden a descascararse cuando la connection es intermitente. Otras veces tienes que hacer las cosas de cierta manera, solo para ver un git status

Sé que esta no es la respuesta que desea escuchar ya que estaba en su situación hace un time y sé exactamente cómo se siente, pero lo mejor que puede hacer es usar git en la command-line .

Odio ser una de esas líneas de command que son mejores contestadores de Stack Overflow, pero en esta situación no pude encontrar nada que estuviera a la altura, para ser utilizado todos los días por varios desarrolladores.

También estaba en contra de eso en ese momento, prefiero la interfaz de usuario más bonita y fácil de usar, pero desde que aprendí la línea de command & git, nunca miré hacia atrás. Al comenzar mis propios proyectos en casa, ¡me encuentro usando terminal sobre cualquier aplicación, ya que encuentro muchas de ellas confusas!

No solo ayuda con la confianza de tu línea de command, sino que mi conocimiento de Git se ha multiplicado por diez desde que usé la terminal, ya que las aplicaciones a menudo ocultan muchos de los sucesos.