Comprender git: conectar la rama a un repositorio remoto

Question

Tengo un repositorio en github, por ejemplo testrepo. Ahora me gustaría configurar un repositorio local repo que tenga una rama origin-master donde deseo poder editar cosas desde el repositorio.

repo/origin-master <--------> origin/master 

La clonación funciona bien:

mkdir repo && cd repo && git init 
# not necessary of course: 
echo "master" > master && git add master && git ci -m "master" 
git remote add origin git@github.com:<username>/testrepo.git 
git fetch origin 
git branch --set-upstream origin-master origin/master 
git checkout origin-master 
# create a new file: 
echo "for origin-master" > orig-master && git add orig-master && git ci -m "orig-master" 

pero

git push origin 
To git@github.com:<username>/testrepo.git 
! [rejected]  master -> master (non-fast-forward) 
error: failed to push some refs to 'git@github.com:<username>/testrepo.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. 

¿Cómo puedo saber git que si quiero empujar a su origen, quiero empujar la rama local origin-master a origin/master?

Answer 1

Establecer el comportamiento de su comando predeterminado a aguas arriba:

$ git config push.default upstream 
$ git push origin 

git push origin es lo mismo que git push origin :, que empuja todas las ramas de "igualación" de forma predeterminada. Su rama de maestro de origen no coincide, por lo que intenta tomar la rama que hace coincide (master) y la envía al origen.

Alternativamente, puede especificar los push refspecs sobre una base per-remoto:

$ git config --add remote.origin.push origin-master:master 
$ git push origin 

Ver también git-push examples y git-config.

Answer 2

Consulte this post para obtener un buen consejo de empujar a un repo no pelado (es decir, con copia de trabajo). Básicamente lo que está sucediendo aquí es que cuando presionas de esta manera, el repositorio remoto no actualiza su copia de trabajo (los archivos reales), solo su historial. Luego necesita git reset --hard para actualizar los archivos, pero es peligroso ya que perderá modificaciones no comprometidas.

Como consejo general, diría que prefiero pull to push cuando se trata de múltiples repositorios no desnudos: push to only bare repositories!

Answer 3

Tengo problemas para comprender qué tipo de flujo de trabajo está tratando de configurar, pero ¿esto ayudaría?

"How do you make an existing git branch track a remote branch?"