Différence entre deux commande basées sur git push

Bonjour,

Disons par exemple que je souhaite créer une nouvelle branche pour pusher mes modifs et ne pas polluer la branche master :
git branch ma-branche
git checkout ma-branche
git add myFile.ext
git commit -m""

Pour la ligne qui push vers le distant, quelle est la différence entre
1) git push
et
2) git push origin ma-branche ?

Sachant que je m'étais déjà positionné sur ma branche ma-branche, j'ai fait la commande 1).
Le problème, c'est que ma branche n'apparait pas sur le repo distant...

Mais qu'ai-je donc fait ? Pourquoi fallait-il que je fasse la commande 2) pour la voir apparaitre sur le repo distant ?
En faisant 1), ai-je pushé sur le master ?

Merci d'avance pour vos éclaircissements.

Bonjour,

les deux sont équivalente, sauf que dans le premier cas tu as déclarer un raccourci dans ton fichier .git/config vers le remote,
tu dois avoir une ligne

Code:

---

1 2 3 4 5 6 7 8

[remote "origin"] fetch = .... url = ..... [branch "master"] ...

---

http://git-scm.com/book/fr/Les-bases...%B4ts-distants

il t'explique cette notion

pour le second cas, c'est la même commande mais tu signales exactement ce que tu veux faire.

tu pousses t'as branche locale vers le dépôt distant ...;
http://git-scm.com/book/fr/Les-bases...C3%B4t-distant

Petit détail important origin, est par défaut le nom distant
master est le ,nom par défaut tu dépôt local.

j'aime pas trop le git push origin ma branche car il faut l'interpréter à l'envers ...

Olivier

Ok, merci pour l'explication.
En effet j'ai bien un raccourci dans mon fichier de config git.
Alors finalement, lorsque j'ai fais "git push", j'ai pushé sur le master, c'est bien ça ?
Mais mon commit, je l'ai fait sur ma branche non ?
Donc lorsque j'ai fait git push... je n'ai rien pushé du tout !? (sous entendu, je n'avais aucun commit en attente sur la branche master).

Donc si je résume, pour terminer mon push sur ma branche "ma-branche", je dois faire un "git push origin ma-branche" (Dis moi si je me trompe)


C'est vrai qu'il faut interpréter un git push origin à l'envers... mais c'est la seule solution que je connaisse pour pusher quelque chose. Comment aurais-tu fais ?

Merci encore.

Bonjour,

Avec git, il faut distinguer deux actions.

Je modifie mes fichiers .... je travaille, je travaille sur ma branche.
quand tout est OK, je commit, là, je suis toujours sur ma branche, j'ai commité mais je n'ai rien envoyé au serveur.
Il faut se dire que c'est un moyen de travailler seul et en itinérance. je peux si je le souhaite reprendre mon travail deux jours après, et recommité
sur ma branche .
git commit -m ..

Ok

Maintenant, j'estime que tout le monde doit partager mon travail qui est sur ma branche. que je vais appeler dev.

en règle général, la branche par défaut locale est dite "master", ce qui fait qu'en local j'ai "dev" et "master"
ce que je fais.

Code:

---

git checkout master

---

je bascule sur ma branche principale"

Code:

---

git merge dev

---

je fusionne la branche de travail dev sur la branche locale master dite stable en local"
comme je suis un dieu du dev, je partage mon superbe travail de ouf

Code:

---

git push origin master

---

ou raccourci

Code:

---

git push

---

En règle général, je travaille avec au moins trois branches.
celle locale, pour le développement dev
celle locale, en phase de recette, mais pas sûr encore, master
celle distante, ou je suis "sûr" de mes modifs dite origin.
Entre temps, je tague les versions, histoire de savoir ou j'en suis.

en local sur mon serveur

depot master -----------------> depot distant origin

|
branche dev


Olivier

Un détail qui a son importance sur le comportement par défaut de git-push (i.e. sans refspec): celui-ci peut être paramétré à l'aide du paramètre push.default

Les valeurs possible pour cette variable sont

• nothing - inhibe le push !
• matching -pousse toutes les branches ayant le même nom en local et remote (valeur par défaut pour git 1.x).
• upstream - pousse la branche courante sur sa branche remote (upstream).
• tracking - dépréciée (replacée par upstream)
• current - pousse la branche courante sur une branche remote de même nom.
• simple identique à upstream mais il faut que la branche courante soit trackée (valeur par défaut pour git 2.x).

Personnellement je conseille d'installer le mode current : 'git config push.default current'... pour travailler sur des branches de même nom en local/remote !

a+
Philippe

Bonjour,

Merci pour la précision.
Et je suis d'accord avec ton avis.

Olivier