tag repositorio que crear git version-control

repositorio - ¿Cómo consigues que git siempre tire de una rama específica?



git tag (8)

Bajo [branch "master"] , intente agregar lo siguiente al archivo de configuración Git del repositorio ( .git/config ):

[branch "master"] remote = origin merge = refs/heads/master

Esto le dice a Git 2 cosas:

  1. Cuando estás en la rama maestra, el control remoto predeterminado es el origen.
  2. Cuando use git pull en la rama maestra, sin control remoto ni rama especificada, use el control remoto predeterminado (origen) y fusione los cambios de la rama maestra remota.

Sin embargo, no estoy seguro de por qué esta configuración se habría eliminado de tu configuración. Es posible que tenga que seguir las sugerencias que otras personas han publicado también, pero esto puede funcionar (o al menos ayudar).

Si no desea editar el archivo de configuración a mano, puede usar la herramienta de línea de comandos en su lugar:

$ git config branch.master.remote origin $ git config branch.master.merge refs/heads/master

No soy un maestro git, pero he estado trabajando con él desde hace algún tiempo, con varios proyectos diferentes. En cada proyecto, siempre git clone [repository] y desde ese punto, siempre puedo git pull , siempre que no tenga cambios sobresalientes, por supuesto.

Recientemente, tuve que volver a una rama anterior, y lo hice con git checkout 4f82a29 . Cuando volví a estar listo para tirar, descubrí que tenía que volver a establecer mi rama en maestro. Ahora, no puedo tirar utilizando un git pull directo, sino que debo especificar git pull origin master , lo que es molesto, y me indica que no entiendo completamente lo que está pasando.

¿Qué ha cambiado, lo que no me permite realizar un git pull directo sin especificar el maestro de origen y cómo volver a cambiarlo?

ACTUALIZAR:

-bash-3.1$ cat config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [branch "master"] [remote "origin"] url = [email protected]:user/project.git fetch = refs/heads/*:refs/remotes/origin/*

ACTUALIZACIÓN 2: Para ser claro, entiendo que mi método original puede haber sido incorrecto, pero necesito arreglar este repositorio para que pueda usar git pull nuevamente. Actualmente, git pull da como resultado:

-bash-3.1$ git pull You asked me to pull without telling me which branch you want to merge with, and ''branch.master.merge'' in your configuration file does not tell me either. Please name which branch you want to merge on the command line and try again (e.g. ''git pull ''). See git-pull(1) for details on the refspec. If you often merge with the same branch, you may want to configure the following variables in your configuration file: branch.master.remote = branch.master.merge = remote..url = remote..fetch = See git-config(1) for details.

Puedo decirle a git pull qué rama combinar, y funciona correctamente, pero git pull no funciona como lo hacía originalmente antes de mi git checkout .


Como no quería editar mi archivo de configuración de git, seguí la información en la publicación de @ mipadi y la utilicé:

$ git pull origin master


Me resulta difícil recordar los argumentos exactos de git config o git branch como en las respuestas de mipadi y Casey, así que uso estos 2 comandos para agregar la referencia en sentido ascendente:

git pull origin master git push -u origin master

Esto agregará la misma información a su .git / config, pero me parece más fácil de recordar.


Si lo prefiere, puede configurar estas opciones a través de la línea de comando (en lugar de editar el archivo de configuración) así:

$ git config branch.master.remote origin $ git config branch.master.merge refs/heads/master

O, si eres como yo, y quieres que este sea el valor predeterminado en todos tus proyectos, incluidos aquellos en los que podrías trabajar en el futuro, entonces agrégalo como una configuración de configuración global:

$ git config --global branch.master.remote origin $ git config --global branch.master.merge refs/heads/master


También hay una forma de configurar Git, por lo tanto, siempre extrae y empuja la rama remota equivalente a la rama actualmente verificada en la copia de trabajo. Se llama una rama de seguimiento que git ready recomienda configurar de forma predeterminada .

Para el siguiente repositorio sobre el directorio de trabajo actual:

git config branch.autosetupmerge true

Para todos los repositorios de Git, que no están configurados de otra manera:

git config --global branch.autosetupmerge true

Tipo de magia, IMHO pero esto podría ayudar en casos donde la rama específica es siempre la rama actual .

Cuando haya establecido branch.autosetupmerge en true y branch.autosetupmerge una sucursal por primera vez, Git le informará sobre el seguimiento de la rama remota correspondiente:

(master)$ git checkout gh-pages Branch gh-pages set up to track remote branch gh-pages from origin. Switched to a new branch ''gh-pages''

Git entonces empujará a esa rama correspondiente automáticamente:

(gh-pages)$ git push Counting objects: 8, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1003 bytes, done. Total 6 (delta 2), reused 0 (delta 0) To [email protected]:bigben87/webbit.git 1bf578c..268fb60 gh-pages -> gh-pages


Tu pregunta inmediata sobre cómo hacer que sea un maestro, debes hacer lo que dice. Especifique la refspec de la que desea extraer en su configuración de rama.

[branch "master"] merge = refs/heads/master


Git pull combina dos acciones: obtener nuevas confirmaciones del repositorio remoto en las ramas rastreadas y luego fusionarlas en su rama actual .

Cuando verificó un compromiso en particular, no tiene una rama actual, solo tiene HEAD que apunta al último compromiso que realizó. Así que git pull no tiene todos sus parámetros especificados. Por eso no funcionó.

Según su información actualizada, lo que está tratando de hacer es revertir su repositorio remoto. Si conoce la confirmación que introdujo el error, la forma más fácil de manejar esto es con git revert que registra una nueva confirmación que deshace la confirmación de error especificada:

$ git checkout master $ git reflog #to find the SHA1 of buggy commit, say b12345 $ git revert b12345 $ git pull $ git push

Ya que es su servidor el que desea cambiar, asumiré que no necesita volver a escribir el historial para ocultar la confirmación del buggy.

Si el error se introdujo en una confirmación de fusión, este procedimiento no funcionará. Consulte How-to-revert-a-faulty-merge .


git branch --set-upstream master origin/master

Esto agregará la siguiente información a su archivo de config :

[branch "master"] remote = origin merge = refs/heads/master

Si tiene branch.autosetuprebase = always entonces también se agregará:

rebase = true