Avoir un historique propre avec git rebase

Tools
1

Alors je me suis rendu compte a force de contribuer a duniter-ts que mon utilisation de git était loin d’être optimale, et notamment j’ai laisser beaucoup de bruits, de merges locaux et autres saletés dans l’historique des commit de duniter-ts, commençant a m’en rendre compte suite a des remarques de @sveyret j’ai compris qu’il y avait des bonnes pratiques de git qu’il me manquait.

Je suis donc parti en quête d’un tutoriel clair et complet sur le sujet afin de maitriser enfin l’art du rebase, et j’ai trouver mon bonheur aujourd’hui :

Aussi pour l’instant et depuis toujours je fait tout en cli, mais si vous connaissez une gui git qui permet notamment de fractionner facilement un commit, y compris en isolant plusieurs modifs d’un même fichier, ça m’intéresse :slight_smile:

3 Likes
2

J’ai souffert longtemps aussi avant de découvrir le rebase.

J’ai compris son utilité et sa puissance grâce à un article en anglais.

Attention tout de même avec le rebase, on peut créer des régressions car les conflits sont résolus commit après commit, et pas tous en même temps comme un merge. Résultat j’ai fait revenir en arrière du code dont je ne savais pas que quelqu’un l’avait amélioré. Et le rebase ne l’a pas vu…

Merci pour l’article, je vais le dévorer ! :smiley:

1 Like
3

Tu peux indexer seulement des parties d’un fichier avec l’interface basique de git : git gui.

Tu index ton fichier, puis dans la partie droite, bouton droit, le menu te propose d’indexer/désindexer les lignes sélectionnées.

gitk permet de visualiser graphiquement l’arbre des branches.

Sinon certains IDE comme PyCharm, WebStorm et PHPStorm intègre graphiquement git dans leur interface.

1 Like
4

Attetion toutefois à ne push-forcer que sur les branches de développement uniquement avant de les merger dans les branches stables.
Autrement, les personnes qui suivent ces branches vont se retrouver avec des conflits lors d’un simple pull.

1 Like
5

Oui évidemment, de toute façon ça n’a pas de sens de rebaser sur une branche stable, on est censé le faire sur les branches de dev avant les merge de MR efectivement :slight_smile:

6

Je ne suis pas d’accord avec cela : il est beaucoup plus simple de nettoyer la branche au fur et à mesure que l’on progresse, plutôt que de tout faire d’un coup à la fin. Par contre, effectivement, un push force ne doit se faire que sur une branche où l’on est seul à travailler, ou alors il faut s’assurer que personne d’autre ne va y travailler en même temps, sous peine de risquer de perdre des commits !

2 Likes
7

C’est un très bon article, ce qui ne m’étonne pas de la part de C. Porteneuve. C’est d’ailleurs lui qui m’a formé sur git… :wink:

2 Likes
8

Excellent article ! C’est la première fois que je comprends quelque chose à git. :smiley:

1 Like
9

Personellement, j’utilise git-cola en gui qui permet de bien séparer les untracked files du reste.

1 Like
10

Je pense qu’ @elois cherche plutôt une IHM qui permet de faire visuellement la commande git add -p.

1 Like
11

Oui voila, j’aime beaucoup la gui intégré de vscode qui permet de selectionner les fichiers a intégrer ou non dans le commit mais il ne semble pas possible de n’insérer qu’une partie d’un fichier (faire un git add -p donc), peut être qu’il existe un plugin qui fait ça :thinking:

12

J’ai pas précisé mais oui c’est ce que fait git cola visuellement

main.png963×555 93.2 KB

2 Likes