Git Push no actualiza el código

Estoy actualizando el código en mi repository remoto. Por algún motivo, las actualizaciones no se reflejan.

git push origin master Enter passphrase for key '*********/.ssh/id_rsa': Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 421 bytes | 0 bytes/s, done. Total 5 (delta 4), reused 0 (delta 0) remote: Already on 'master' remote: M app/Http/routes.php To ssh://ec2-**-***-***-***.us-west-2.compute.amazonaws.com/*************** ce2cc5b..8149f07 master -> master 

No estoy obteniendo lo que es "remoto: M".

Por favor guíame. Tengo que hacer el lanzamiento lo antes posible.

Primero, recuerde que cuando ejecuta git push (o, para el caso, git fetch ), hay dos Gits y dos repositorys involucrados en el process. Uno es "tu" depósito de Git y "tu", y el otro es el Git del control remoto y su repository. (El repository en el control remoto también puede pertenecerle a usted, pero solo piense en ello como si fuera otra persona, atendiendo sus requestes, a través de una llamada telefónica por Internet).

Mensajes impresos sin remote: delante de ellos provienen de su Git. Mensajes impresos con remote: al frente provienen del control remoto. No vienen directamente del otro Git -los dos Gits tienen su arreglo de teléfono por Internet configurado para que hablen directamente y sepan lo que dicen los demás-, sino más bien, de algo dirigido por el otro Git. Cuando el otro Git ejecuta cosas, como anzuelos, y esas cosas imprimen sus propios posts, su Git copy esos posts en su Git y le dice a su Git: "No sé lo que esto significa, pero el gancho lo imprimió, y podría ser importante, entonces ¿por qué no le muestras esto al único ser humano disponible en todo este process, es decir, a la persona que hace el git push ? " Y tu Git lo hace: imprime a remote: whatever que remote: whatever para indicar que algo que el otro Git ejecutó imprimió whatever .


Ahora, en su configuration, tiene una secuencia de commands de implementación configurada en el otro sistema. Ese es tu gancho post-recepción. Un enlace posterior a la recepción puede hacer muchas cosas, pero su secuencia de commands particular está pensada como un mecanismo de implementación. Coloca contenidos aproximados de este script en un comentario , pero aquí está mejor formateado (los comentarios no admiten el formateo):

 #!/bin/sh GIT_WORK_TREE=******************** export GIT_WORK_TREE git checkout master 

Lo que hace esta secuencia de commands es hacer que el repository, que de otro modo sería simple, el que está en el remoto, actúe como un repository no desnudo: el tree de trabajo se especifica a través de GIT_WORK_TREE . (Dicho sea de paso, podría hacer que este sea un guión de una línea, en lugar de tres líneas: git --work-tree=... checkout master . Sin embargo, no hay ninguna razón particular para preferir ninguna forma aquí aparte del gusto personal).

¿Qué tipo de salida imprime git checkout veces? Bueno, probemos:

 $ git checkout master M wt-status.c Already on 'master' 

¿Qué viste en tu salida, con prefijo remote: ?

 remote: Already on 'master' remote: M app/Http/routes.php 

Conclusión: es casi seguro que esto provenga del command git checkout ejecuta en su script de implementación. (El order de las dos líneas ha cambiado, pero todavía proceden del git checkout ).

¿Cuándo imprime git checkout este tipo de post? La documentation de Git es un poco delgada aquí, pero:

Para prepararse para trabajar en <branch> , cambie a él actualizando el índice y los files en el tree de trabajo, y señalando HEAD en la twig. Se guardan las modificaciones locales a los files en el tree de trabajo , de modo que puedan comprometerse con la <branch> .

Por lo tanto, esto ocurre cuando se modifican el índice y / o el tree de trabajo, pero se pueden mantener esas modificaciones locales. (Vea Git – revise otra twig cuando haya cambios no confirmados en la sucursal actual para más detalles).

Esto significa que su tree de trabajo (remoto) ha realizado algunos cambios en la app/Http/routes.php files app/Http/routes.php , con respecto a la confirmación HEAD . 1 Cuando, con su Git, empuja hacia el control remoto, con su Git, el Git remoto ejecuta el script de deployment. Cuando el script de deployment usa su tree de trabajo no divulgado junto con el repository simple para que actúe como un repository no desnudo, y el otro script de deployment de Git ejecuta el process de git checkout , ese process de pago "mantiene el (local-to-remote-work- tree) modificación ", pero imprime esa línea M

Como la modificación que se guarda está en el control remoto, la única forma de manejarlo es ir al control remoto (por ejemplo, ssh in) para que pueda trabajar localmente allí. Luego, investigue por qué se modifica ese tree de trabajo: ¿quién hizo este cambio? ¿Por qué? ¿Qué hace? ¿Debería estar en el repository? ¿Debería hacerse de otra manera? ¿Necesita modificar el script de implementación? No puedo responder ninguna de estas preguntas por ti; debes decidir cómo hacer que todo esto funcione.


1 Ligeramente complicando la image, estos podrían estar en el índice del control remoto. Este índice es, de hecho, el índice del repository desnudo , porque git --work-tree=... checkout usa el índice (único) del repository, aunque ese índice refleje el tree de trabajo. Es probable, sin embargo, que el cambio solo se produzca en el tree de trabajo de implementación en el control remoto.