Salut à tous,

j'ai un dépot git en 3 branches (master, devel et une autre qui n'a aucun intérêt pour le problème) actuellement et j'aimerai merge une branch de développement dans la branche "master". Ce que j'ai fais :

git checkout master
git merge devel

Je pensais qu'en faisant ça sans ff, je ne verrai que le commit de merge dans ma branche master. Or j'ai tout l'historique de ma branche devel. C'est problématique. L'intérêt des branches pour moi c'est quand même de pouvoir commit un peu en mode bourrin dans les branches de développement de features et d'avoir une branche principale plus propre avec seulement les commits de merges de ces branches avec les commits qui lui sont directement destinées.
Je ne sais pas du tout comment m'y prendre pour ça. Concrètement comment ça se passe pour github quand on fait un pull request (ou un merge request sur gitlab). Parce qu'à la fin on se retrouve bien avec un seul commit dans le projet d'origine et le mec peut avoir pourri son fork ça ne change rien pour nous.

Merci à ceux qui pourront me répondre, ou qui pendront la peine de me lire

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

J'ai deux objections au fait d'utiliser rebase :

- Je bosse sur la branche master qui est une branche "publique" (voir le point "golden rule of rebase" de ton article)
- Je veux que mes deux branches soient toujours là après, rebase détruit une des deux

Je pourrais surement me démerder à créer des branches temporaires pour faire des rebase dedans mais ça me parraît un peu compliqué. Il n'y a pas plus simple ?

Je crois que c'est git merge --squash que tu cherches.

AtmelAVR > Oui ! Merci, j'avais déjà essayé mais je n'avais pas compris ce qu'elle faisait cette commande. J'ai du supprimer le dépôt local avant de faire un git status...

G_B > Ouais j'avais essayé avec --no-ff. Mais de toute façon il ne faisait pas de fastforward de base puisque j'avais un commit de merge. Donc le résultat était le même.

Quand au rebase c'est bien pour "rattraper" les développements d'autres personnes faites sur devel quand tu travailles sur une feature qui se base sur devel

Il faut créer une branche en plus dans ce cas, non ? J'ai du mal à comprendre git rebase. C'est peut être moi.

Notre utilisation de git n'est surement pas optimale (c'est moi le gros con qui ai oublié de pull avant un commit en haut, j'aurai du le corriger mais j'ai voulu aller trop vite...) j'avoue que je pensais connaître le truc avant de commencer ce projet mais en fait pas du tout.

Le projet de base n'est pas à nous (je ne sais pas pourquoi j'ai continué à pull depuis le projet après le fork sur master mais bon...)

Vu le screenshot que j'ai envoyé j'aurai pensé que c'est ce que je voulais faire. Voilà ce que j'ai dans la branche releases où j'ai fais le git squash :

Ça me semble bizarre maintenant que je vois le log graphique.

De base y’a un problème de compréhension de git ...

Tu gardera forcément l’historique de ta branche même si tu la merge sur ta master.
Du coup tu dois faire un git merge origin ta branch

De base y’a un problème de compréhension de git ...

Oui clairement. Sinon je ne serais pas là.

Tu gardera forcément l’historique de ta branche même si tu la merge sur ta master.
Du coup tu dois faire un git merge origin ta branch

Et je me retrouve avec quoi dans ce cas là ?

Avec troi branche...
mec les Tito ça manque sur le net.

Git est un outil de versioning donc toute t’es version son historise ce qui normale.

Donc le bon taf est de savoir comment gérer ses branche. En gros tu dois pas utilisé la master...

Je pensais qu'en faisant ça sans ff, je ne verrai que le commit de merge dans ma branche master. Or j'ai tout l'historique de ma branche devel. C'est problématique. L'intérêt des branches pour moi c'est quand même de pouvoir commit un peu en mode bourrin dans les branches de développement de features et d'avoir une branche principale plus propre avec seulement les commits de merges de ces branches avec les commits qui lui sont directement destinées.

non ce n'est pas problematique, l'oppose serait problematique par contre amha

ce que tu souhaites faire si j'ai bien compris, c'est de reduire tous les commit de ta branche `devel` en un seul commit, puis ensuite de merge ce seul et unique commit resultant dans master pour ainsi ne voir aucun historique du developpement de `devel` dans la branche master

autrement dit, tu souhaites applatir/ecraser (d'ou le squash en anglais) l'historique de `devel`

faire ca est possible mais c'est tres mauvais si ton nombre de commit est grand, c'est mauvais dans le sens ou il faut vouloir garder une granularite raisonnable en cas de bug, tu veux pouvoir ensuite utiliser git blame et/ou git bisect par exemple pour trouver ton commit fautif, puis meme, de maniere general, il est bon de garder l'historique de developpement

si tu tiens vraiment a perdre de l'information parce que tu consideres que l'historique de developpement de `devel` est inutile a garder car il s'agit d'ajout triviaux, tu peux faire un squash de tes commits de `devel` avec `git rebase -i <1er commit de ta branche devel` ensuite tu squash pour reduire ton historique, dans ton cas je n'irais pas a squash tous les commits de devel sur le 1er de la branche

mais plutot je ferais un squash seulement des commits ou la separation avec le commit precedent est inutile a garder, typiquement une typo ou un fix trivial

une fois ton rebase -i fini,

tu peux faire ton merge comme tu l'as fait, et tu auras un historique propre de devel visible dans master, et c'est ce que tu veux

Donc le bon taf est de savoir comment gérer ses branche. En gros tu dois pas utilisé la master...

Donc typiquement ce que je faisais de base. J'ai un peu merdé en continuant à pull depuis upstream j'avoue, mais sinon on n'a jamais commit directement sur cette branche. Pour ce qui est des tutos perso j'utilise la doc en ligne, j'ai aussi fais quelques tutos interractifs mais c'est rare que la partie sur les branches soit très claire (il y a des chances que ça vienne de moi aussi).

Après comme d'hab je n'ai pas épongé tous les tutos disponibles et je compte bien en trouver des plus informatifs/qualitatifs que ceux sur lesquels je suis tombé pour le moment.

VDD > Merci pour l'explication. J'avoue que j'utilise mal git de base (je suppose que je l'utilise comme svn, et encore svn propose de bosser sur des branches également) et j'avais rarement touché à des branches auparavant, du moins je n'y avais jamais touché en tant qu'"admin" du dépôt. Je vais faire des clones et voir ce que je peux en tirer pour rendre le truc propre.

Tu parles de "mal utiliser git", connais-tu git flow ? ( http://nvie.com/posts/a-successful-git-branching-model/ )

C'est une des méthodologies la plus utilisée concernant git et, d'expérience, une des plus pratique.