Flux de travail de base de Git

Question

Possible Duplicate:
erreur de poussée git '[remote rejected] master -> master (la branche est actuellement vérifiée)'

Je suis nouveau sur Git et j'essaie de l'utiliser pour un projet grails local.
Les étapes que j'ai suivies:

1. créer le projet grails

2. aller dans le répertoire du projet et git init

3. Ajouter tous les fichiers du projet dans la zone de staging et commiter.

4. Le statut git du dépôt donne le message suivant

   BXX@BXX-PC /c/Work/Grails/projects/yyy/tables (master)
   $ git status
   # Sur la branche master
   Rien à valider (répertoire de travail propre)

5. En essayant de garder la branche master, faire les modifications en clonant le dépôt, et ensuite pousser les modifications. Pour cela

6. Dans mon IDE, checkout le projet (IntelliJ). Cela clone en fait le projet vers un autre répertoire.

7. Faire les modifications et commiter le projet

8. Pousser les modifications locales vers master.

   15:41:56.249: git push -v origin master
   Pousser vers c:/Work/Grails/projects/xxx/tables
   remote: erreur: refus de mettre à jour la branche vérifiée : refs/heads/master        
   remote: erreur: Par défaut, mettre à jour la branche actuelle dans un dépôt non nu        
   remote: est interdit, car cela rendra l'index et l'arborescence de travail incohérents        
   remote: avec ce que vous avez poussé, et nécessitera 'git reset --hard' pour mettre        
   remote: l'arborescence de travail à HEAD. 

Le statut du dépôt cloné est

$ git status
# Sur la branche master
# Votre branche devance 'origin/master' de 1 commit.
#
Rien à valider (répertoire de travail propre)

S'il vous plaît aidez-moi à comprendre cela. Y a-t-il un meilleur flux de travail à suivre. Je pourrais initier le dépôt via Intellij, et essayer de travailler sur la branche principale. Pas encore sûr de ce qui ne va pas ci-dessus.

merci.

Answer 1

Le problème est que vous essayez de pousser vers un dépôt non prêt. Un dépôt non prêt est un dépôt qui a un arbre de travail associé (c'est-à-dire que les fichiers sont réellement vérifiés sur le disque). Par défaut, Git ne vous permet pas de pousser vers un dépôt non prêt ; pousser vers un dépôt non prêt met seulement à jour les structures de données internes de Git, et ne modifie pas l'arbre de travail (les fichiers sur le disque), ce qui signifie que si vous revenez ensuite au dépôt vers lequel vous avez poussé et commencez à travailler sur les fichiers, vous travaillerez sur des copies plus anciennes des fichiers. Naturellement, cela causera des problèmes lorsque vous essayez de valider vos modifications.

La meilleure façon de faire est de pousser vers un dépôt prêt, qui est créé en passant le drapeau --bare à Git lors de la création du dépôt :

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

Bien sûr, le dépôt prêt n'aura aucun fichier vérifié, vous ne pouvez donc pas réellement y travailler (vous devrez d'abord le cloner).

Si vous utilisez simplement un dépôt Git pour le développement local (et ne partagez pas ou ne servez pas le dépôt Git), vous n'avez pas besoin d'avoir un dépôt distant vers lequel pousser ; vous pouvez travailler sur une seule copie d'un dépôt local, non prêt.

Answer 2

Tout d'abord, vous n'avez pas besoin de cloner votre dépôt local. Vous pouvez utiliser des branches pour diviser le développement dans le même dépôt.

Git est un VCS distribué et si vous avez de l'expérience avec Subversion ou CVS avant, vous devez changer d'avis.

Git est très agile et vous pouvez utiliser différents flux de travail avec lui. Cloner des dépôts est plus nécessaire pour un travail d'équipe, pas pour un développement local (à mon avis).

Les branches sont une bonne alternative pour vous.

Voyons. Définissons la branche master de votre dépôt pour un code prêt pour la production. Créons une autre branche pour le développement:

$ git checkout -b development master

Maintenant vous travaillez sur la branche développement.

Vous pourriez utiliser différentes branches pour chaque fonctionnalité que vous souhaitez développer. C'est très facile et utile.

Imaginons que vous voulez implémenter une nouvelle fonctionnalité, vous devez créer une nouvelle branche:

$ git checkout -b newfeature development

Maintenant vous pouvez travailler avec votre code, ajouter des fichiers, faire des commits, et ainsi de suite.

Ensuite, vous devez fusionner votre nouvelle fonctionnalité développée dans la branche développement:

$ git add .
$ git commit -m "Mes derniers changements pour la nouvelle fonctionnalité"
$ git checkout development
$ git merge newfeature

Maintenant votre nouveau code de la branche newfeature est fusionné dans la branche développement.

À un moment donné dans le futur, lorsque vous décidez que votre code dans la branche développement atteint un jalon, vous pouvez fusionner tous les changements de la développement à la branche master.

C'est un flux de travail très basique, cela peut être utile pour de nombreuses branches.

Mon conseil pour vous maintenant: en savoir plus sur git, les branches, le stockage (très-très-très utile pour des corrections rapides). Et après un certain temps, vous verrez un grand bénéfice de l'utilisation de git.

Bonne chance.

Answer 3

Ceci est la description la plus claire et la plus complète d'un flux de travail git réussi. Cela couvre essentiellement ce que Sergey suggère, avec l'ajout de quelques graphiques très utiles.

Un modèle de branching Git réussi

L'auteur suggère également lorsque vous fusionnez d'inclure la balise --no-ff pour garder une trace du fait que vous aviez une branche de fonctionnalité dans l'historique.

Answer 4

J'ai fini par arriver ici en essayant de résoudre le même type de problème, heureusement il y a une réponse bien meilleure ici :

Erreur de push Git '[remote rejected] master -> master (la branche est actuellement en cours d'exécution)'

Vous devriez vérifier celui-ci. Surtout que c'est assez facile de se retrouver dans cette situation. Pour moi, tout ce que j'ai fait était de créer un répertoire et d'y initialiser git pour créer mon nouveau "dépôt partagé". C'était sur une clé USB car notre réseau est complètement verrouillé et nous ne pouvons pas partager un répertoire ou accéder à GitHub pour le moment.

Ensuite, j'ai copié tout notre code source dans ce répertoire, je l'ai ajouté, committé, puis j'ai cloné le dépôt résultant sur mon disque local pour en faire mon origine. Je me suis dit que je pourrais plus tard rendre GitHub distant et me débarrasser du dépôt USB partagé. Cependant, ma première modification sur le disque local et ma tentative de push vers le distant (le dépôt clé) m'ont donné ce message car le dépôt clé n'était pas "bare". Tous les fichiers originaux étaient toujours là-bas.

Consultez la réponse la mieux notée sur la question liée pour savoir quoi faire. L'idée est que vous définissiez un drapeau dans le dépôt partagé pour qu'il pense qu'il est "bare" puis supprimez tout sauf le sous-répertoire .git, et votre push fonctionnera alors.