¿Por qué comprometerse sin empujar en git?

Estoy empezando a aprender Git. He estado jugando con GitKraken y espero que usar una GUI sea un camino viable para guardar y compartir cosas. Prefiero las GUI a la línea de comandos.

Ahora entiendo, en la GUI, necesito stage archivos, entonces commit ellos y luego push, para subirlos. Pero por qué son push y commit dos cosas diferentes? ¿Por qué querría simplemente commit localmente, sin la siguiente carga para mantener los archivos sincronizados?

Un par de razones (concretas). TLDR en negrita.

La primera razón es que es posible que no pueda presionar el control remotoporque no estás conectado a Internet.

La segunda razón es que a veces las confirmaciones no están listas para enviarse.. Por ejemplo, practico TDD. Después de confirmar una prueba fallida (lo cual hago), no quiero enviarla al control remoto, porque entonces mi equipo puede generar un conjunto de pruebas fallidas. Otra práctica común es aplastar estas confirmaciones antes de eliminarlas para que parezca que la característica fue una única confirmación.

La tercera razón es que es un proyecto personal que no quieres compartir con nadie., por lo que no hay ningún control remoto al que presionar. No es necesario tener un control remoto con un repositorio git.

La cuarta razón es que puede tener múltiples controles remotos (en general, la semántica distribuida se interpone en el camino). Entonces, después de comprometerse, ¿cómo sabría Git a qué control remoto desea presionar? ¿Todos ellos? ¿Uno en particular? ¿Un cierto dos de los siete? La inserción debe ser explícita desde la perspectiva de git debido a que la semántica de git es un VCS distribuido. Vea la respuesta de poke para más detalles.

PD Esto está fuera del tema de la pregunta, pero los shells de línea de comando (incluido bash) son interfaces extremadamente poderosas una vez que aprende a usarlos. Una vez que domines estas herramientas, usarlas es mucho más rápido que cualquier GUI que puedas encontrar. Esto tiene que ver con el hecho de que puede realizar acciones poderosas con pulsaciones de teclas en lugar del mouse, y que es infinitamente personalizable para satisfacer sus necesidades.

Git es un sistema de control de versiones distribuido. Como tal, no hay único repositorio central, como con Subversion o incluso CVS. Entonces, si hubiera un solo comando para confirmar y enviar, ¿a dónde iría esa confirmación? ¿Cuál sería el repositorio remoto?

En Git, no hay un repositorio central. Ni siquiera hay ninguna jerarquía en los repositorios. Para un repositorio local, alguna otro repositorio es un repositorio remoto con el que puede interactuar. Y el repositorio local es solo un posible repositorio remoto para cualquier otro repositorio.

Entonces, local y remoto son solo puntos de vista relativos a su ubicación actual: el repositorio local es siempre el repositorio actual, y todos los demás repositorios son remotos con los que puede interactuar.

Cuando trabajas con Git, tu repositorio local es con lo que interactúas: envías todos tus cambios localmente. Esto tiene muchos beneficios y casos de uso que no detallaré aquí, pero esencialmente es lo que hace que el control de versiones se distribuya, ya que el repositorio local tiene toda la información, el historial completo.

Entonces, cuando tiene ese repositorio local, que tiene el historial completo y todos los cambios, necesita una forma de interactuar con otros repositorios para permitirle compartir el historial. Las dos formas de hacerlo son empujar y tirar (o buscar). Dado que con los repositorios distribuidos, todos los repositorios son iguales, cada repositorio puede empujar o extraer de otro (suponiendo que tengan acceso).

Al final, se requiere que confirmar y enviar sean pasos separados porque uno interactúa con el repositorio (local) mientras que el otro es un paso deliberado para compartir cambios con un repositorio remoto.

Otra respuesta: no hay una buena razón

En los viejos tiempos (como hace cinco años, historia antigua según los estándares actuales de memoria) la gente a veces no conectado a internet! ¡Y querían seguir trabajando! Así que simplemente se comprometieron mientras trabajaban. Cuando se lograba la conexión, continuaban y empujaban todas sus confirmaciones. Git fue diseñado con esto como paradigma principal.

Flash-forward todas esas épocas hasta el presente y he aquí, la mecánica de las versiones de nuestro software no ha cambiado (mucho).

Algunas personas han argumentado que mantiene todos sus compromisos locales hasta que esté satisfecho de que su código es sólido. Admiro sus instintos: proteger el código del repositorio principal; mantenerlo lo más impecable posible. ¡Sí, por supuesto, por favor hazlo!

Pero Git proporciona un mecanismo que funciona mucho mejor para el código no tan perfecto, se llama ramas. Cree una rama, trabaje en ella (empujando confirmaciones todo el tiempo) hasta que esté satisfecho, luego fusione esa rama con la principal. De esta manera, si algo le sucede a su computadora (caída del disco duro, derrame de café, robo, etc.), todo su trabajo aún estará respaldado. Ese es uno de los puntos del control de versiones, ¿verdad?

Sin embargo, otros han argumentado que en un sistema de desarrollo altamente distribuido, es necesario especificar dónde y cómo impulsar las confirmaciones. Esta es ciertamente una opción, pero todavía tengo que ver esto en la práctica. No me puedo imaginar una empresa diciéndoles a sus desarrolladores: “Salgan y cada uno de ustedes se quede con su propia copia del código. Dejaremos que se empujen y tiren unos de otros según sientan y esperen que nada salga mal o se complique”. confuso.” Sí. Es mucho más fácil configurar una cuenta de bitbucket o github y decirles a todos: “¡Usen esto como su origen!”

Así que para ser franco: solo presiona con cada compromiso. No hay inconveniente en hacer esto, y existe una pequeña posibilidad de perder el trabajo si no lo hace.

Sirven para diferentes propósitos. Cada confirmación debe cambiar un aspecto aislado del código; por ejemplo, cambie el nombre de una variable, reemplace las llamadas a una función con llamadas a otra, o simplemente corrija un error tipográfico en un comentario. Piense en ellos como puntos de reversión; Si cambio de opinión sobre el enfoque que tomé aquí, ¿puedo descartar un pequeño conjunto de confirmaciones y aún mantener estos otros cambios no relacionados?

Un impulso solo debe ocurrir cuando su serie de compromisos alcanza un nuevo punto estable en el desarrollo que se ha probado lo suficiente como para compartirlo con sus colegas o colaboradores.

No es imposible o inusual hacer un impulso para cada confirmación si está trabajando, por ejemplo, en la corrección de errores menores. Pero la mayor parte del tiempo, tiene sentido realizar cambios individuales a medida que avanza hacia un objetivo más amplio, y solo empujar cuando cree que ha alcanzado ese objetivo.