1

yop,

J'utilise un dépôt Git, sur github, depuis la maison ou le boulot.
Parfois, quand j'oublie de pusher (à la maison par exemple), et que je fais ensuite des modifs au boulot (que cette fois, je push), je ne peux plus faire un pull à la maison.
Je crois comprendre l'idée, c'est que j'ai des modifs pas commitées dans mon répertoire de travail, et Git ne voudrait pas les écraser avec un pull.
Ok, ça part d'une bonne intention.

Donc, questions :
1. Comment lui dire "sisi vas-y, tu peux quand même puller, c'est pas grave si ça écrase mes modifs." ?
2. Pourquoi, par deux fois, Git m'a "forcé" à faire un merge de branch, alors que je n'avais pas créé de branche, et que j'avais rien demandé ? confus

ps ->Une réponse parfaite serait simple, et faisable en deux clics sous Tortoise Git grin

Merci d'avance !

2

Si tu veux vraiment tout écraser: git reset --hard origin/master annule (efface) toutes tes modifications locales, committées ou pas.

Sinon, l'idée est de faire un commit de tes modifications locales et ensuite un pull avec rebase (git pull --rebase) pour déplacer tes modifications locales par dessus le master actuel. Ensuite, tu peux éventuellement finir ce que tu as commencé et faire un git commit --amend. Finalement, seulement quand tu es content du résultat, tu fais un push. (Si tu n'es pas content et si tu n'arrives pas à nettoyer ton bordel, tant que tu n'as pas fait de push, tu peux toujours faire un git reset --hard origin/master pour tout écraser.)

Je ne connais pas l'interface de Tortoise Git, donc je ne peux pas te dire où trouver tout ça dans ses menus.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

3

[edit] Gros cross smile

Pour la question 1, tu as plusieurs options :

Si tu veux conserver le travail que tu as fait à la maison, tu peux le commit dans une autre branche pour le retrouver plus tard et enlever ces changements de ton espace de travail :
git checkout -b nouvellebranche # Crée une nouvelle branche "nouvellebranche" et te place dessus git commit -am 'Ma sauvegarde' # Commit sur la branche actuelle ("nouvellebranche") git checkout master # Revient sur la branche initiale, en supposant qu'elle s'appelait "master" git pull origin master # Récupère tes changements distants, en supposant que le remote s'appelle "origine" et la branche "master"Avec TortoiseGit ça veut dire "Clic droit", "Git Switch / Checkout", cocher l'option "Create New Branch" et lui donner un nom. Ensuite faire le commit, puis revenir à la branche initiale avec le même menu.

Si tu veux le conserver mais seulement temporairement et que tu ne veux pas créer de branche tu peux utiliser la commande "stash" : au lieu d'être conservés dans une branche tes changements vont être sauvegardés dans une pile (le "stash"), tu pourras ensuite les récupérer depuis cette pile. Par défaut tu les récupères dans l'ordre inverse de l'ordre dans lequel tu les y a mis (= tu récupèreras en premier le dernier changement que tu avais stashé).
git stash # Empile les changements en cours dans le stash git pull origin master # Récupère tes changements distants git stash pop # Dépile les changements que tu avais mis de côté et essaie de les ré-appliquer sur la nouvelle version du codeAvec TortoiseGit tu as les options "Stash Save" et "Stash Restore" dans le menu (pas sûr du nom pour la deuxième, je te laisse vérifier).

Si tu veux perdre les changements que tu avais fait à la maison, tu peux utiliser la commande "reset" pour les effacer. Attention : c'est l'une des rares commandes de Git qui ne te permet aucun retour en arrière, donc il faut que tu sois sûr de toi :
git reset --hard HEAD # Annule les changements en cours et revient à l'état du dernier commit sur lequel tu étais (attention : définitif) git pull origin master # Récupère tes changements distantsAvec TortoiseGit l'option est ici : https://tortoisegit.org/docs/tortoisegit/tgit-dug-reset.html

Pour la question 2 je ne suis pas sûr d'avoir compris ce que tu veux dire, tu es certain d'avoir vu écrit "merge de branche" ? J'aurais plutôt tendance à penser qu'il s'agit d'un commit de merge (c'est à dire un commit qui a deux parents au lieu d'un seul). Si tu veux interdire à Git de créer un commit de merge automatiquement, tu peux lui demander de faire un "fast-forward" (c'est à dire mettre à jour ta branche actuelle à condition qu'il soit possible de le faire sans créer de commit de merge). S'il n'y arrive pas, il échouera au lieu de créer silencieusement le merge ; à toi alors de te remettre dans un état qui lui permettra de faire le fast-forward (soit avec l'une des options listées ci-dessus, soit via un rebase ; cf. Google pour cette dernière solution).
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

4

Ok, merci beaucoup pour ces réponses super précises ! top
Et ça répond complètement à mon besoin le plus fréquent, c'est parfait.

Pour la seconde question, j'avais copié mais pas collé le lien qui se voulait illustratif ; le voici : https://github.com/Folcogh/Packinov3/commit/21de390d1095d1058e84778ec8ed335713dbbe87
Quand j'ai voulu faire un "Commit to master" avec Tortoise Git, il m'a proposé ce commit d'office, sans que je touche à rien. Ou plutôt, sans que je comprenne à quoi j'aurais pas dû toucher grin

Une explication du phénomène ?

5

Tu devais avoir à la fois au moins un commit en local qui n'existait pas sur la branche distante, et au moins un commit distant qui n'existait pas sur ta branche locale. Visuellement ça veut dire ça :
       o ab12cd (origin/master, branche distante)
o-o--<
       o cd32ab (master, branche locale)
Si tu demandes à Git de se débrouiller avec ça (avec la commande git pull origin master sans spécifier aucune option par exemple) il va créer un commit de merge pour s'en sortir, c'est à dire un commit qui aura 2 parents. Visuellement ça ressemblera à ça :
       o ab12cd
o-o--<   >--o ef45ab (nouveau commit)
       o cd32ab
Git a tendance à privilégier cette option par défaut puisque c'est la seule qui permet de préserver les deux commits précédents (ab12cd et cd32ab) intacts. Si tu veux éviter ça pour garder un historique linéaire, tu es obligé d'en réécrire l'un des deux : soit tu réécris ton commit local pour faire comme s'il avait été écrit à la suite du distant, soit tu réécris le commit distant pour faire comme s'il avait été écrit à la suite du local. Par exemple en choisissant la première option tu peux utiliser git rebase origin/master pour lui dire : réécrit tous mes commits en local qui n'existent pas dans la branche "origin/master" de façon à ce qu'ils soient ajoutés au bout de cette dernière. Le résultat ressemblera à ça :
    ab12cd  fa89de
o-o-o-------o (ancien commit cd32ab réécrit)
C'est tout beau tout propre et tout linéaire, il n'y a plus de commit de merge, mais en revanche ton ancien commit "cd32ab" n'existe plus : il a été remplacé par un nouveau commit "fa89de" qui n'a plus le même parent (qui ne se "base" plus sur le même état du code, d'où le nom de la commande). Comme cette opération va réécrire un (ou plusieurs) commits il y a également un risque que Git n'y arrive pas tout seul et qu'un conflit, c'est à dire une modification concurrente au même endroit dans le même fichier, soit à résoudre.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

6

Ok, merci bien. top

7

très clair, en effet top
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

8

Zeph (./5) :
Par exemple en choisissant la première option tu peux utiliser git rebase origin/master
… sachant que ça ne marchera que si tu as fait un fetch de master auparavant, parce que sinon, ton origin/master n'est pas à jour.

Pour faire tout en une étape, comme j'ai déjà mentionné, il y a la commande git pull --rebase. (Personnellement, je fais tous mes pulls avec --rebase.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

9

Oui en effet, j'ai passé sous silence pas mal de choses mais c'est difficile d'expliquer comment fonctionne Git sans écrire 3 pages smile

Comme le dit Kevin origin/master est l'étiquette qui correspondait à la branche master du remote origin la dernière fois que tu as synchronisé ton dépôt local avec celui distant (avec la commande fetch). La commande pull quant à elle est un raccourci qui combine plusieurs commandes : elle commence par faire une synchronisation (équivalente à fetch) puis récupère les commits distants sur ta branche locale. Dans le cas où les branches ont divergé (il y a de chaque côté des commits qui n'existent pas de l'autre, comme dans ./5) alors Git va faire soit un merge (par défaut) soit un rebase avec l'option proposée par Kevin.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

10

Il me semble qu'on peux modifier la config de git pour faire du rebase par defaut plutôt que du merge.

Oui c'est ca:

git config --global pull.rebase true

Mais bien sur ca change le comportement par defaut, et en changeant de machine ca ne se comportera pas de la meme maniere.

(edit: attention le "etiquette" dont parle Zeph a propos de origin/master n'a rien a voir avec un tag (ok ok en interne c'est proche mais pas du point de vu utilisateur))
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

11

Bof dans 90% des cas c'est équivalent pour l'utilisateur justement ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

12

la réécriture d'historique c le mal, surtout quand on travaille a plusieurs sur le même repo!! </gratuit grin>

sinon pour pas écraser des modifs locales temporairement:

git stash save

ca devient tout propre on peut faire son git pull origin master

ensuite git stash pop remet les modifs non committées par dessus les commits récupérés (ca peut foirer comme un merge bien sur)

le stash fonctionne comme un FIFO on peut faire save/pop plusieurs fois

si on veut juste détruire les modifs sauvées y'a git stash clear (ou clean chais plus), parfois ca va plus vite que toute une série de git checkout -- <fichier> grin

13

C’est ce que fait rebase normalement..
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

14

squalyl (./12) :

le stash fonctionne comme un FIFO on peut faire save/pop plusieurs fois

couloucoucou



Je relis ce topic et j'hallucine à quel point GIT est encore plus une usine à gaz que SVN ou CVS avant lui. Je ne comprends pas comment on peut proposer des IDE tous complets, des OS avec des intégrations de tout plein de trucs et pour cet outil, sans ligne de commande, point de salut. neutral
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

15

stash stash

nan, on s'en sort avec quelques trucs basiques, et globalement c'est juste mieux, en fait. sisi.

16

squalyl (./15) :
stash stash

nan, on s'en sort avec quelques trucs basiques, et globalement c'est juste mieux, en fait. sisi.
j'en suis pas convaincu, des fois je me dis qu'un dropbox avec synchro auto et historique ferait aussi bien sans la moindre ligne de commande...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

17

On ne veux pas forcément tout sauvegarder et Dropbox ne permet pas de faire un « snapshot » a un instant précis comme genre « modification du bidule pour tronxiner le chose, penser a trouner l’octamachin lors d’une utilisation intensive »
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

18

je fais les deux et pour du code tu veux pouvoir accéder facilement aux changements apportés. vazy pour développer a plus d'un avec un dropbox, faire des merge, etc.

19

Vince > j'utilise pas du tout la ligne de commande (uniquement la GUI de Git Extensions), et en pratique je m'en sors avec Git. Bon, je ne fais pas de trucs super chiadés non plus, mais ça prouve que t'as pas forcément besoin de te laisser pousser la barbe pour arriver à quelque chose ^^
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

20

vince (./14) :
Je relis ce topic et j'hallucine à quel point GIT est encore plus une usine à gaz que SVN ou CVS avant lui. Je ne comprends pas comment on peut proposer des IDE tous complets, des OS avec des intégrations de tout plein de trucs et pour cet outil, sans ligne de commande, point de salut. neutral
Je n'utilise quasiment que PyCharm ou IntelliJ comme interface à git, ça me convient très bien oui
L'inconvénient de git (mais c'est aussi un avantage) est qu'il permet de travailler à plusieurs de plein de façons différentes… du coup, ça rend les choses assez complexes. Github et Gitlab détaillent chacun plusieurs méthodes complètes (mais ça reste assez compliqué).
Je continue à faire en ligne de commande les push / fetch, mais c'est lié à ssh-agent qui ne fonctionne pas bien avec mes Yubikey.

Cela dit, ça permet plus de choses que svn ou que cvs, ce n'est pas étonnant que cela soit plus compliqué. Cela pourrait (peut-être) être moins compliqué (par exemple, mercurial a la réputation d'être aussi puissant mais plus intuitif, mais je ne connais pas).

vince (./16) :
j'en suis pas convaincu, des fois je me dis qu'un dropbox avec synchro auto et historique ferait aussi bien sans la moindre ligne de commande...
sauf que tu ne peux pas maintenir plusieurs branches en parallèle ^^
Si tu ne fais que du "Dropbox", tu peux utiliser Sparkleshare qui fait l'équivalent avec du git sous le capot (c'est ce que j'utilise pour mes documents et ça marche pas mal du tout).
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

21

D'ailleurs Vince, puisque tu parles d'IDE, pas mal d'entre eux sont compatibles directement avec Git ; ça peut t'éviter de devoir utiliser un autre soft à côté.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

22

squalyl (./12) :
la réécriture d'historique c le mal, surtout quand on travaille a plusieurs sur le même repo!! </gratuit grin>
Justement, l'intérêt d'un pull avec rebase est de réécrire ton historique locale avant d'envoyer la modification au serveur public.

Je ne comprends absolument pas pourquoi ce n'est pas le défaut. Ras le bol des historiques non-linéaires!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

23

(m'étonne pas de toi... l'URSS pratiquait aussi la réécriture de l'historique, et ils faisaient même mieux que Git : en plus des fichiers textes, ils géraient aussi les fichiers images)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

24

25

trisotfl

26

C'est un troll très courant sur internet, merge vs rebase, je suis pas sûr que ça soit la peine de le dupliquer ici sauf si ça intéresse Folco hehe
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

27

On pourrait passer au débat mergstub vs kernbase oui
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

28

ans(2) -> non merci, ça m'ira comme ça cheeky

29

Il n'y a donc pas une commande plus rapide que l'autre ? Ou plus compacte ?

30

roll
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)