Git flujo de trabajo básico

Question

Duplicar posible:
git push error '[remote rejected] master -> master (branch is currently checked out)'

Soy nuevo en Git y tratar de utilizarlo para un proyecto griales local.
Los pasos que siguen:

1. crear el griales proyectan
2. vaya al directorio del proyecto y git init
3. añadir todos los archivos en el proyecto en el área de ensayo y se comprometen.

4. El estado de Git en el repositorio da el siguiente mensaje

   BXX@BXX-PC /c/Work/Grails/projects/yyy/tables (master) 
   $ git status 
   # On branch master 
   nothing to commit (working directory clean) 
   

5. Tratar de mantenerlo como la rama principal, realice los cambios clonando el repositorio, y luego empujar los cambios de nuevo. Para eso

6. En mi IDE, revise el proyecto (IntelliJ). Esto realmente clona el proyecto a otro directorio.
7. Realice los cambios y confirme el proyecto

8. Introduzca los cambios locales en el maestro.

   15:41:56.249: git push -v origin master 
   Pushing to c:/Work/Grails/projects/xxx/tables 
   remote: error: refusing to update checked out branch: refs/heads/master   
   remote: error: By default, updating the current branch in a non-bare repository   
   remote: error: is denied, because it will make the index and work tree inconsistent   
   remote: error: with what you pushed, and will require 'git reset --hard' to match   
   remote: error: the work tree to HEAD. 
   

El estado de recompra clonado es

$ git status 
# On branch master 
# Your branch is ahead of 'origin/master' by 1 commit. 
# 
nothing to commit (working directory clean) 

favor me ayude con este entendimiento. ¿Hay un mejor flujo de trabajo a seguir? Es posible que pueda inicializar el repositorio a través de Intellij y trate de trabajar en la rama principal. Todavía no estoy seguro de lo que está mal arriba.

gracias.

Answer 1

Antes que nada, no necesita clonar su repositorio local. Puede usar ramas para dividir el desarrollo en el mismo repositorio.

Git es un VCS distribuido, y si tiene experiencia con Subversion o CVS antes, debe cambiar de opinión.

Git es muy ágil y puede usar diferentes flujos de trabajo con él. Los repositorios de clonación son más necesarios para un trabajo en equipo, no para el desarrollo local (en mi humilde opinión).

Sucursales es una buena alternativa para usted.

See. Vamos a establecer maestro rama de su repositorio para un código listo para producción. Vamos a crear otra rama de desarrollo :

$ git checkout -b development master 

Ahora se está trabajando en el desarrollo rama.

Puede utilizar diferentes ramas para cada función que desee desarrollar. Es muy fácil y útil.

Imaginemos que desea implementar alguna nueva característica, es necesario crear una nueva rama:

$ git checkout -b newfeature development 

Ahora puede trabajar con su código, añadir archivos, comprometerse y así sucesivamente.

continuación, tiene que fusión su nueva función desarrollada para el desarrollo rama:

$ git add . 
$ git commit -m "My last changes for the new feature" 
$ git checkout development 
$ git merge newfeature 

Ahora su nuevo código de la newfeature rama fusionaron en el desarrollo rama.

Para algún momento en el futuro, cuando usted decide que su código en el desarrollo rama de conseguir un poco de hito, que podría combinar todos los cambios de desarrollo a maestro rama.

Es un flujo de trabajo muy básico, puede ser útil para muchas ramas.

Mi consejo para usted ahora: lea más sobre git, ramificación, almacenamiento (muy, muy, muy útil para soluciones rápidas). Y después de un tiempo, obtendrás un gran esfuerzo de usar git.

Buena suerte.

Answer 2

El problema es que estás tratando de presionar a un repositorio no descubierto. Un repo non-bare es uno que tiene un árbol de trabajo asociado (es decir, los archivos se comprueban en el disco). De forma predeterminada, Git no le permitirá presionar a un repositorio no vacío; empujar a un repositorio no solo solo actualiza las estructuras internas de datos de Git, y no no alterar el árbol de trabajo (los archivos en el disco), lo que significa que si vuelves al repositorio lo presionaste y comenzaste a trabajar en los archivos , estarás trabajando en copias antiguas de los archivos. Naturalmente, esto causará problemas cuando intente realizar sus cambios.

La mejor manera de hacer esto es para empujar a un desnudo repositorio , que es uno creado por pasar la bandera --bare a Git al crear el repositorio:

$ mkdir new_repo 
$ cd new_repo 
$ git --bare init 

Por supuesto, el won repo desnuda No tiene ningún archivo desprotegido, por lo que no puede trabajarlo (tendrá que clonarlo primero).

Si solo está usando un repositorio de Git para el desarrollo local (y no comparte ni sirve el repositorio Git), no tiene tiene para tener un repositorio remoto al que presionar; puede trabajar en una sola copia de un repositorio local no estrictamente.

Answer 3

Esta es la descripción más clara y completa de un flujo de trabajo de git exitoso. Cubre básicamente lo que sugiere Sergey, con la adición de algunos gráficos muy apetitosos.

A successful Git branching model

El autor también sugiere cuando combina para incluir la etiqueta --no-ff para mantener el registro del hecho de que había una rama de la característica de la historia.

Answer 4

terminé aquí cuando se trata de fijar el mismo tipo de problema, afortunadamente no es una respuesta mucho mejor por ahí:

Git push error '[remote rejected] master -> master (branch is currently checked out)'

Debe comprobar que uno. Especialmente ya que es bastante fácil terminar en esta circunstancia. Para mí, todo lo que hice fue crear un directorio e iniciarlo para crear mi nuevo "repositorio compartido". Estaba en una llave USB porque nuestra red está completamente bloqueada y aún no podemos compartir un directorio ni acceder a GitHub.

Luego copié todo nuestro código fuente en ese directorio, lo agregué, lo comprometí y luego cloné el repositorio resultante en mi unidad local, de modo que ahora era mi origen. Pensé que podría hacer más tarde GitHub remoto y eliminar el repositorio USB compartido. Sin embargo, mi primer cambio en la unidad local e intento presionar al control remoto (el repositorio de claves) me dio el mensaje porque el repositorio de claves no era "simple". Todos los archivos originales estaban ahí todavía.

Consulte la respuesta más valorada en el enlace a la pregunta para ver qué hacer. Lo esencial es que establezca un indicador en el repositorio compartido para que crea que está vacío y luego elimine todo, excepto el subdirectorio .git y su inserción funcionará.