Digamos que hay dos personas trabajando en una rama de git, que verifican al mismo tiempo pero una de ellas se compromete primero y luego la otra se compromete después. ¿Se fusionará el compromiso más reciente con el compromiso anterior o pueden varias personas trabajar simultáneamente en la misma sucursal?comprometiéndose a la misma rama con git
Bueno, cuando clonas un repositorio git (¿es eso lo que querías decir con "check out"?), Estás creando una nueva rama. Las ramas de Git son locales para cada repositorio, no global. Una vez dicho esto, tiene un protocolo sobre cómo se transmiten las actualizaciones de las sucursales entre repositorios: cuando extrae de un control remoto, por defecto la rama "principal" del control remoto se fusiona con su rama "principal", por ejemplo. Y cuando presione, su rama "maestra" puede ser anexada a la rama maestra del control remoto. De modo que el maestro y el maestro de control remoto ("origen/maestro", si se quiere) son ramas diferentes, pero están relacionadas por convención.
Volviendo al punto --- observe que dije que su rama principal puede ser anexada cuando presiona hacia un control remoto. Si dos personas han tomado una copia de origen/maestro e hicieron cambios independientes (recuerde que esto es como hacer cambios en dos ramas localmente), una vez que una persona ha modificado sus cambios, los cambios de la otra persona no son simples anexos al origen/dominar más --- tienen que fusionarse. Esto no puede suceder cuando empujas, solo cuando tiras (confusamente, "tirar" no es lo opuesto a "empujar": "buscar" es lo opuesto a empujar; un tirón es una búsqueda seguida de una fusión (o una rebase)).
Así que, si se encuentra en esta situación, quienquiera que intente impulsar sus cambios primero debe retroceder desde el origen/maestro actualizado, fusionar o volver a establecer la base de su versión de maestro, y luego presionar. De forma predeterminada, no puede eliminar los cambios de alguien en una sucursal y reemplazarlos por los suyos: necesita al menos hacer "git push -f" para hacer eso, y el repositorio remoto puede tener configuraciones o ganchos para hacerlo considerablemente más difícil.
O los dos podrían cooperar de antemano: uno de ellos toma los cambios del otro, realiza la fusión y luego presiona el resultado. Esto puede ser una buena acción si es probable que los cambios se superpongan o se afecten entre sí. Recuerde la Primera Ley de los sistemas de control de versiones: un VCS no reemplaza la comunicación.
Varias personas pueden trabajar en la misma sucursal al mismo tiempo. Cuando tiras (o haces que la otra persona empuje) sus cambios a ti git combinarán los cambios, lo que resultará en una rama con tus dos cambios.
En Git, las sucursales son estrictamente local. Un desarrollador no puede cambiar las ramas remotas de otro desarrollador (vea la nota en la parte inferior). Sin embargo, en el caso de un repositorio bare, puede "presionar" sus cambios para actualizar las ramas del repositorio remoto, si los cambios darán como resultado un avance rápido.
Pero si dos desarrolladores se están comprometiendo con el mismo repositorio remoto, solo uno podrá avanzar rápidamente la rama remota sin actualizar su rama al principio.
Por ejemplo, supongamos que Alice y Bob trabajan en la rama principal en sus repositorios locales, cada uno clonado desde un repositorio compartido (sin conexión) en un servidor. Si Alice termina su trabajo primero, cuando empuja sus cambios comprometidos al repositorio compartido compartido, avanzará rápidamente la rama principal del repositorio desnudo.
Ahora Bob no puede avanzar rápidamente la rama principal del repositorio desnudo sin actualizar primero su rama local para incluir los commits que Alice ha agregado (porque los commits que ha agregado no son ancestros de los commits que Alice creó).
Una forma en que Bob puede hacer esto es tirar (o preferiblemente rebasear) del repositorio desnudo después de que Alice haya empujado sus commits. Esto fusionará los cambios de Alice en la rama de Bob y posibilitará que Bob adelante rápidamente la rama maestra del repositorio desnudo con un empujón.
Otros flujos de trabajo son posibles: Alice y Bob podrían cooperativamente extraerse unos de otros directamente sin usar un depósito descubierto compartido. Hay posibilidades casi infinitas, realmente. Pero en general, la fusión en Git se realiza por y se realizan cambios.
[Nota: lo que realmente es posible empujar en repositorios no desnudas, y por lo tanto actualizar otras ramas de la gente, sin embargo, esto a menudo da resultados poco intuitivos, no es considerado un flujo de trabajo git típica, y en general no se recomienda]
una respuesta más corta es la siguiente:
commit -m "my changes"
recuperar la versión compartida
git fetch sharedrepo
uno de estos dos para sincronizar su rama local con el otro repo
git merge sharedrepo/sharedbranch
git rebase sharedrepo/sharedbranch
Rebase serializa la historia si no desea que una gran cantidad de ramas en la historia final. Ambas opciones pueden obligarte a resolver conflictos antes de que termines.
después de combinación de rebase y resolución de conflictos/que empuja de nuevo a repo
git push sharedrepo HEAD:sharedbranch
No utilice -f aquí como este debe ser un avance rápido. Si tiene mala suerte, alguien más puede haber empujado una nueva versión. Si eso sucede, reinicie este procedimiento.
Se puede trabajar por separado y luego cada vez que necesita para empujar/tirar de cambios sí:
git add --all .
git commit -m "Commit desc"
git pull
git push
Explicación:
git add --all .
Añadir todos los cambios, incluyendo los archivos eliminados
git commit -m "Commit desc"
Declare la confirmación
git pull
primer tirón, que se fusionarán, es posible que necesite para arreglar los conflictos
git push
empuje la última versión fusionada [opcional - si desea enviar los cambios]
Si desea más control, como poder trabajar en múltiples versiones locales/remotas al mismo tiempo, luego eche un vistazo a branches.
Recomiendo esta página simple pero útil como un flujo de trabajo sugerido http://genomewiki.ucsc.edu/index.php/Working_with_branches_in_Git cubre algunos procedimientos excelentes.
"un VCS no reemplaza la comunicación". Ese es probablemente el mejor comentario que he leído toda la semana. – baudtack