¿Por qué Git rechaza mi atracción simplemente porque tengo un compromiso en mi sucursal local?

Question

Hay un repositorio de Git en un servidor del que mi colega y yo hacemos push y pull. Funciona bien siempre que tiremos antes de comprometernos.

Sin embargo, si él ha empujado a la rama principal, y en la media hora que he hecho cometer un local, cuando trato de tirar me sale esto:

! [rejected]  master -> master (non-fast-forward) 

Pero sé que no debería haber no conflicto.

A mi modo de conseguir alrededor de él es tirando en una nueva rama temporal y luego la fusión de eso en mi amo como esto:

% git pull origin master:temp 
From ssh://example.com/home/my/remote/repo 
* [new branch]  master -> temp 
Already up-to-date. 
% git merge temp 
Already up-to-date. 
% git push origin master:master 

en cuenta que Git actúa como si yo no estoy haciendo nada, pero realmente lo han sacudido en sumisión.

Recientemente me di cuenta de que en lugar de tratar de "convencer" a Git de que está bien que lo tire. Solo puedo fingir que aún no me he comprometido con git reset --soft HEAD^ y git stash y luego hacer el pull y confirmarlo.

¿Qué podría estar causando este comportamiento extrañamente meticuloso?

Pude reproducir este problema todo en mi máquina local. Esto es lo que hice:

Primero hice el primer repositorio "local" y agregué un archivo.

% cd 
% mkdir local-1 
% cd local-1/ 
% mkdir website 
% cd website/ 
% git init 
Initialized empty Git repository in /Users/jason/local-1/website/.git/ 
% touch file 
% git add . 
% git commit -m 'added file' 
[master (root-commit) 6d4b322] added file 
0 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 file 

Luego hice el repositorio "remoto".

% cd 
% mkdir remote 
% cd remote 
% mkdir website.git 
% cd website.git/ 
% git init --bare 
Initialized empty Git repository in /Users/jason/remote/website.git/ 

Luego volví al local, hice una referencia y lo empujé al control remoto.

% cd ~/local-1/website/ 
% git remote add web ~/remote/website.git 
% git push web +master:refs/heads/master 
Counting objects: 3, done. 
Writing objects: 100% (3/3), 207 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
To /Users/jason/remote/website.git 
* [new branch]  master -> master 

Después de eso he clonado el control remoto en un segundo local.

% cd 
% mkdir local-2 
% cd local-2 
% git clone ~/remote/website.git 
Cloning into website... 
done. 

Entonces creó una referencia a la distancia desde el segundo local y empujado (aquí es donde estoy creando el problema creo).

% cd website/ 
% git remote add web ~/remote/website.git 
% git push web +master:refs/heads/master 
Everything up-to-date 

Luego realicé un cambio en local-2, comprometido y empujado.

% touch another 
% git add . 
% git commit -m 'added another' 
[master be91180] added another 
0 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 another 
% git push web 
Counting objects: 3, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (2/2), 238 bytes, done. 
Total 2 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (2/2), done. 
To /Users/jason/remote/website.git 
    6d4b322..be91180 master -> master 

Finalmente, hice un cambio diferente a lo local-1, comprometido, y trató de empujar.

% cd ~/local-1/website/ 
% touch something 
% git add . 
% git commit -m 'added something' 
[master 3984529] added something 
0 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 something 
% git push web 
To /Users/jason/remote/website.git 
! [rejected]  master -> master (non-fast-forward) 
error: failed to push some refs to '/Users/jason/remote/website.git' 
To prevent you from losing history, non-fast-forward updates were rejected 
Merge the remote changes (e.g. 'git pull') before pushing again. See the 
'Note about fast-forwards' section of 'git push --help' for details. 

Blast! ¿Qué tal un tirón?

% git pull web master:master 
From /Users/jason/remote/website 
! [rejected]  master  -> master (non-fast-forward) 

Bien, entonces ahí está el problema. ¿Cómo lo arreglo?

Answer 1

Probablemente significaba que hacer:

git pull web master 

Usando master:master está tratando de actualizar directamente master rama local en la etapa de ir a buscar el tirón que está causando el error no avance rápido.

Si está en una sucursal configurada para rastrear web/master, entonces solo necesita git pull web y esto también actualizará sus rastreos de seguimiento remoto.