Share
En pocas palabras, un repositorio remoto es uno que no es el suyo. Podría estar en un servidor central, en la computadora personal de otro desarrollador o incluso en su sistema de archivos. Mientras pueda acceder a él desde algún tipo de protocolo de red, Git hace que sea increíblemente fácil compartir contribuciones con otros repositorios..
La función principal de los repositorios remotos es representar a otros desarrolladores dentro de su propio repositorio. Las sucursales, por otro lado, solo deben tratar con el desarrollo del proyecto. Es decir, no intente dar a cada desarrollador su propia sucursal para que trabaje en dar a cada uno un repositorio completo y reservar sucursales para desarrollar características.
Este capítulo comienza cubriendo la mecánica de los controles remotos, y luego presenta los dos flujos de trabajo más comunes de la colaboración basada en Git: el flujo de trabajo centralizado y el flujo de trabajo del integrador.
Similar a rama de git, la git remoto El comando se utiliza para gestionar las conexiones a otros repositorios. Los controles remotos no son más que marcadores en otros repositorios; en lugar de escribir la ruta completa, le permiten hacer referencia a ella con un nombre fácil de usar. Aprenderemos cómo podemos usar estos marcadores en Git Abajo.
Puede ver sus controles remotos existentes llamando al git remoto comando sin argumentos:
git remoto
Si no tiene controles remotos, este comando no generará ninguna información. Si usaste git clon para obtener su repositorio, verá una origen remoto. Git agrega automáticamente esta conexión, bajo el supuesto de que probablemente querrá interactuar con ella en el futuro.
Puede solicitar un poco más de información sobre sus controles remotos con el -v bandera:
git remoto -v
Esto muestra la ruta completa al repositorio. La especificación de rutas remotas se trata en la siguiente sección.
los git remoto añadir comando crea una nueva conexión a un repositorio remoto.
git remoto añadir
Después de ejecutar este comando, puede acceder al repositorio de Git en
Git acepta muchos protocolos de red para especificar la ubicación de un repositorio remoto, incluyendo expediente://, ssh: //, http: //, y su costumbre git: // protocolo. Por ejemplo:
git remote agrega a algunos usuarios ssh: //[email protected]/some-user/some-repo.git
Después de ejecutar este comando, puede acceder al repositorio en github.com/some-user/some-repo.git usando solo algún usuario. Desde que usamos ssh: // como protocolo, es probable que se le solicite una contraseña SSH antes de poder hacer algo con la cuenta. Esto hace que SSH sea una buena opción para otorgar acceso de escritura a los desarrolladores, mientras que las rutas HTTP se usan generalmente para dar acceso de solo lectura. Como pronto descubriremos, esto está diseñado como una característica de seguridad para entornos distribuidos.
Finalmente, puedes eliminar una conexión remota con el siguiente comando:
git remoto rm
Commits puede ser la unidad atómica del control de versiones basado en Git, pero ramas Son el medio en el que se comunican los repositorios remotos.. Ramas remotas actúa como las sucursales locales que hemos cubierto hasta ahora, excepto que representan una sucursal en el repositorio de otra persona.
Una vez que haya descargado una sucursal remota, puede inspeccionarla, fusionarla y ampliarla como cualquier otra sucursal. Esto permite una curva de aprendizaje muy corta si entiende cómo usar las sucursales localmente..
El acto de descargar sucursales de otro repositorio se llama atractivo. Para obtener una rama remota, puede especificar el repositorio y la rama que está buscando:
git fetch
O, si quieres descargar cada ramificar en -r opción a rama de git:
rama git -r
Esto le da una lista de sucursales que se parece a algo como:
origen / origen maestro / origen de alguna característica / otra característica
Las ramas remotas siempre tienen un prefijo con el nombre remoto (origen/) Para distinguirlos de las sucursales locales..
Recuerda, Git usa repositorios remotos como marcadores-No conexiones en tiempo real con otros repositorios. Las ramas remotas son copias de las sucursales locales de otro repositorio. Fuera del alcance real, los repositorios son entornos de desarrollo completamente aislados. Esto también significa que Git nunca recuperará automáticamente las sucursales para acceder a la información actualizada; debe hacerlo manualmente.
Pero, esto es algo bueno, ya que significa que no tiene que preocuparse constantemente por lo que todos los demás están contribuyendo al hacer su trabajo. Esto solo es posible debido al flujo de trabajo no lineal habilitado por las sucursales de Git.
Para todos los propósitos, las ramas remotas se comportan como ramas de solo lectura. Puede inspeccionar de forma segura su historial y ver sus compromisos a través de git checkout, pero no puede continuar desarrollándolos antes de integrarlos en su repositorio local. Esto tiene sentido cuando se considera el hecho de que las ramas remotas son copias de los compromisos de otros usuarios.
los ... La sintaxis es muy útil para filtrar el historial de registros. Por ejemplo, el siguiente comando muestra las nuevas actualizaciones de origen / maestro que no estan en tu local dominar rama. Por lo general, es una buena idea ejecutar esto antes de fusionar los cambios para que sepa exactamente lo que está integrando:
git log master ... origen / master
Si esto genera algún compromiso, significa que está detrás del proyecto oficial y probablemente debería actualizar su repositorio. Esto es descrito en la siguiente sección.
Es posible verificar sucursales remotas, pero esto lo colocará en un lugar aislado. CABEZA estado. Esto es seguro para ver los cambios de otros usuarios antes de integrarlos, pero los cambios que agregue se perderán a menos que cree una nueva sugerencia de sucursal local para hacer referencia a ellos..
Por supuesto, el objetivo principal de la búsqueda es integrar las sucursales remotas resultantes en su proyecto local. Digamos que eres colaborador de un proyecto de código abierto, y has estado trabajando en una característica llamada alguna característica. Como el proyecto "oficial" (típicamente señalado por origen) avanza, es posible que desee incorporar sus nuevas confirmaciones en su repositorio. Esto aseguraría que su función aún funcione con los desarrollos de vanguardia.
Afortunadamente, puedes usar el mismo git merge comando para incorporar cambios de origen / maestro en su rama característica:
git checkout alguna característica git fetch origin git merge origin / master
Dado que su historial se ha desviado, esto se traduce en una fusión de 3 vías, después de lo cual su alguna característica La sucursal tiene acceso a la versión más actualizada del proyecto oficial..
Accentsconagua
dominar en una rama característica Sin embargo, frecuentemente se fusiona con origen / maestro solo para acceder a las actualizaciones eventualmente se obtiene un historial lleno de combinaciones de combinaciones sin sentido. Dependiendo de la precisión con la que su función necesite realizar un seguimiento del resto de la base del código, la reorganización podría ser una mejor manera de integrar los cambios:
git checkout alguna característica git fetch origin git rebase origin / master
Al igual que con la reorganización local, esto crea un historial perfectamente lineal, sin comillas de fusión superfluas:
dominar Rebasar / fusionar sucursales remotas tiene exactamente las mismas ventajas y desventajas que se discutieron en el capítulo sobre sucursales locales.
Dado que la secuencia de búsqueda / fusión es una ocurrencia tan común en el desarrollo distribuido, Git proporciona una Halar comando como un atajo conveniente:
origen de git pull / maestro
Esto obtiene la rama maestra del origen, y luego la fusiona en la rama actual en un solo paso. También puedes pasar el --rebase opción de uso git rebase en lugar de git merge.
Para complementar el git fetch comando, Git también proporciona una empujar mando. Empujando es casi lo opuesto a la captura, en la medida en que la búsqueda importa las sucursales, mientras que la exportación de las sucursales a otro repositorio.
git push
El comando anterior envía el local git push crea un local rama. Por ejemplo, ejecutando git push mary my-feature en su repositorio local se verá como lo siguiente desde la perspectiva de Mary (su repositorio no se verá afectado por el empuje).
Darse cuenta de mi característica es un local sucursal en el repositorio de María, mientras que sería una remoto Rama si ella misma la hubiera traído.
Esto hace que empujar una operación peligrosa. Imagine que se está desarrollando en su propio repositorio local, cuando, de repente, una nueva sucursal local aparece de la nada. Pero, se supone que los repositorios sirven como entornos de desarrollo completamente aislados, entonces ¿por qué debería git push incluso existen? Como pronto descubriremos, empujar es una herramienta necesaria para mantener los repositorios públicos de Git.
Ahora que tenemos una idea básica de cómo Git interactúa con otros repositorios, podemos analizar los flujos de trabajo del mundo real que son compatibles con estos comandos. Los dos modelos de colaboración más comunes son: el flujo de trabajo centralizado y el flujo de trabajo del integrador. Los usuarios de SVN y CVS deben sentirse bastante cómodos con el desarrollo centralizado de Git, pero usar Git significa que también podrá aprovechar sus capacidades de combinación altamente eficientes. El flujo de trabajo del integrador es un modelo de colaboración distribuido típico y no es posible en sistemas puramente centralizados.
A medida que lea estos flujos de trabajo, tenga en cuenta que Git trata a todos los repositorios como iguales. No hay un repositorio "maestro" de acuerdo con Git como lo hay con SVN o CVS. La base de código "oficial" es simplemente una convención de proyecto, la única razón por la que es el repositorio oficial es porque ahí es donde todos están origen puntos remotos.
Cada modelo de colaboración implica al menos uno público repositorio que sirve como punto de entrada para múltiples desarrolladores. Los repositorios públicos tienen la única restricción de ser desnudo-no deben tener un directorio de trabajo. Esto evita que los desarrolladores sobrescriban accidentalmente el trabajo de los demás. git push. Puede crear un repositorio simple pasando la --desnudo opción a git init:
git init --bare
Los repositorios públicos solo deberían funcionar como instalaciones de almacenamiento-No entornos de desarrollo. Esto se transmite añadiendo un .git extensión a la ruta del archivo del repositorio, ya que la base de datos interna del repositorio reside en la raíz del proyecto en lugar de la .git subdirectorio. Entonces, un ejemplo completo podría verse como:
git init --bare some-repo.git
Aparte de la falta de un directorio de trabajo, no hay nada especial en un repositorio simple. Puede agregar conexiones remotas, empujar hacia él y tirar de él de la manera habitual..
El flujo de trabajo centralizado se adapta mejor a los equipos pequeños donde cada desarrollador tiene acceso de escritura al repositorio. Permite la colaboración mediante el uso de un único repositorio central, al igual que el flujo de trabajo SVN o CVS. En este modelo, todos los cambios deben compartirse a través del repositorio central, que generalmente se almacena en un servidor para permitir la colaboración basada en Internet.
Los desarrolladores trabajan individualmente en su propio repositorio local, que está completamente aislado de todos los demás. Una vez que han completado una función y están listos para compartir su código, lo limpian, lo integran en su local. dominar, y empujarlo al repositorio central (por ejemplo,., origen). Esto también significa que cada desarrollador necesita acceso SSH al repositorio central.
Luego, todos los demás pueden obtener los nuevos compromisos e incorporarlos a sus proyectos locales. Nuevamente, esto se puede hacer con una combinación o una rebase, según las convenciones de su equipo..
Este es el proceso central detrás de los flujos de trabajo centralizados, pero se topa cuando varios usuarios intentan actualizar simultáneamente el repositorio central. Imagine un escenario donde dos desarrolladores terminaron una característica, la fusionaron en su local. dominar, y trató de publicarlo al mismo tiempo (o cerca de él).
Quienquiera que llegue primero al servidor puede empujar sus confirmaciones de manera normal, pero luego el segundo desarrollador se queda con un historial divergente, y Git no puede realizar una combinación de avance rápido. Por ejemplo, si un desarrollador llamado John empujara sus cambios justo antes de Mary, veríamos un conflicto en el repositorio de Mary:
La única manera de hacer el origen's master (actualizado por John) coincide con Mary's dominar Es para exagerar John se compromete. Obviamente, esto sería muy malo, por lo que Git aborta el impulso y genera un mensaje de error:
! [rechazado] master -> master (non-forward-forward) error: no se pudo empujar algunos refs a 'some-repo.git'
Para remediar esta situación, Mary necesita sincronizarse con el repositorio central. Entonces, ella podrá empujar sus cambios de la manera habitual..
git fetch origin master git rebase origin / master git push origin master
Aparte de eso, el flujo de trabajo centralizado es relativamente sencillo. Cada desarrollador se queda en su propio repositorio local, periódicamente tirando / empujando al repositorio central para mantener todo actualizado. Es un flujo de trabajo conveniente para configurar, ya que solo se requiere un servidor, y aprovecha la funcionalidad SSH existente.
El flujo de trabajo del integrador es un modelo de desarrollo distribuido donde todos los usuarios mantienen su propio público Repositorio, además de su privado. Existe como una solución a los problemas de seguridad y escalabilidad inherentes al flujo de trabajo centralizado..
El principal inconveniente del flujo de trabajo centralizado es que cada El desarrollador necesita acceso a todo el proyecto. Esto está bien si está trabajando con un pequeño equipo de desarrolladores de confianza, pero imagine un escenario en el que está trabajando en un proyecto de software de código abierto y un extraño encontró un error, lo corrigió y desea incorporar la actualización en el proyecto principal. Probablemente no quiera darle acceso de empuje al repositorio central, ya que podría comenzar a empujar todo tipo de confirmaciones aleatorias y perdería el control del proyecto..
Pero, lo que puede hacer es decirle al colaborador que envíe los cambios a su propia repositorio publico. Luego, puede colocar su corrección de errores en su repositorio privado para asegurarse de que no contenga ningún código no declarado. Si aprueba sus contribuciones, todo lo que tiene que hacer es combinarlas en una sucursal local y enviarlas al repositorio principal como de costumbre. Te has convertido en un integrador, además de un desarrollador ordinario:
En este flujo de trabajo, cada desarrollador solo necesita acceso push a su propia repositorio publico. El colaborador utiliza SSH para enviar a su repositorio público, pero el integrador puede obtener los cambios a través de HTTP (un protocolo de solo lectura). Esto lo convierte en un entorno más seguro para todos, incluso cuando agrega más colaboradores:
Tenga en cuenta que el equipo todavía debe acordar un único repositorio "oficial" del que extraer los cambios; de lo contrario, los cambios se aplicarían fuera de orden y todos los usuarios acabarían desincronizados muy rápidamente. En el diagrama anterior, "Tu Repo Pública" es el proyecto oficial..
Como integrador, debe realizar un seguimiento de más controles remotos de lo que lo haría en el flujo de trabajo centralizado, pero esto le brinda la libertad y la seguridad para incorporar cambios de cualquier desarrollador sin amenazar la estabilidad del proyecto..
Además, el flujo de trabajo del integrador no tiene un único punto de acceso que sirva como punto de estrangulamiento para la colaboración. En los flujos de trabajo centralizados, todos deben estar completamente actualizados antes de publicar los cambios, pero ese no es el caso de los flujos de trabajo distribuidos. Nuevamente, esto es un resultado directo del estilo de desarrollo no lineal habilitado por la implementación de la rama de Git.
Estas son enormes ventajas para grandes proyectos de código abierto. Organizar a cientos de desarrolladores para trabajar en un solo proyecto no sería posible sin la seguridad y la escalabilidad de la colaboración distribuida.
Apoyar estos modelos de colaboración centralizados y distribuidos fue todo lo que Git tenía que hacer. El directorio de trabajo, el escenario, las confirmaciones, las sucursales y los controles remotos fueron diseñados específicamente para habilitar estos flujos de trabajo, y prácticamente todo en Git gira en torno a estos componentes..
Fiel a la filosofía de UNIX, Git fue diseñado como un conjunto de herramientas interoperables, no como un solo programa monolítico. A medida que continúe explorando las numerosas capacidades de Git, descubrirá que es muy fácil adaptar comandos individuales a flujos de trabajo completamente nuevos..
Ahora le dejo a usted aplicar estos conceptos a los proyectos del mundo real, pero cuando comience a incorporar Git en su flujo de trabajo diario, recuerde que no es una bala de plata para la gestión de proyectos. Es simplemente una herramienta para rastrear sus archivos, y ningún conocimiento íntimo de Git puede compensar una serie de convenciones al azar dentro de un equipo de desarrollo..
Esta lección representa un capítulo de Git sucintamente, un libro electrónico gratuito del equipo en Syncfusion.
