Tu utilises bien les techniques que tu veux. Mais quand on donne un conseil technique il me semble qu'on a une certaine responsabilité de prévenir les destinataires des risques potentiels.
En l'occurence un git reset HEAD^ c'est pas une commande triviale à utiliser et je trouve préférable de donner les pistes permettant de corriger une erreur plutôt que simplement poser ça là en se contentant d'un « C'est trop cool [par contre démerdez vous si vous perdez des données à cause de gunwip] »
Donc j'explique pour les lecteur⋅ices qui ne savent pas : git log peut aussi servir à voir l'historique sur un dépot distant, et git reflog sert à retrouver l'historique des commits sur lesquel on est passé.
Pour la différence entre git add . et git commit -a, je trouve peu pertinent d'ajouter au dépôt des fichiers non suivis si on en a pas encore l'usage.
Ça vaut pour les .fuse_hidden qui surviennent de temps en temps dans les montages sshfs, pour les fichiers temporaires d'une librairie qu'on vient de tester et qu'on a pas encore pris le temps de mettre dans le .gitignore, pour les .Trash d'un poste qui n'a pas encore de gitignore global, voire pire ce fichier de conf avec le mot de passe de la base de donnée qui lui non plus reflete un travail en cours et qui n'est pas encore dans le gitignore, etc…
C'est ton choix, moi je préfère prévenir qu'il y a un risque que j'estime non négligeable de perte de donnée, ainsi que de pourrissement de dépôt par des données inutiles ou des fuites de mot de passe.
Pour finir ta remarque sur le piédestal est déplacée, je ne pense pas t'avoir manqué de respect personnel en critiquant ta solution technique. Au risque de me faire traiter encore une fois d'oppresseur intolérant, je te prierai de ne pas verser dans l'attaque perso sans provocation. Peut-être après on fera « la paix. »
Ah la vile cochonnerie ! Non, vraiment faites pas ça.
Pour mettre un travail en attente il y a git stash, qui n'a pour seul comportement inattendu que demander à résoudre les conflits si conflit il y a.
Ensuite au niveau de la mise en place de cette "solution" ça laisse à désirer.
Faire git add . est redondant avec l'argument -a de git commit qui a le même effet. (Sauf que ça commite pas les fichiers non suivis, mais du coup ça évite en plus de rajouter dans le dépôt des fichiers qui n'ont rien à y faire et qu'on a manqué dans le .gitignore)
Faire un alias qui efface le dernier commit, c'est un coup à perdre des données. gunwip sur la mauvaise branche et oups merde, comment je le retrouve ce commit que j'aurai pas du effacer ? (Avec git reflog si on s'en rends compte de suite, avec de la chance si on a fait d'autres trucs depuis.)
Et si on efface un commit public il faut le retrouver (heureusement ce sera plus simple qu'avec un commit local, avec git log origin/nom_de_branche on s'en sort facilement) on ne peut pas juste « le refaire à la main » puisque son SHA sera différent, il faudra faire un push -f et les contributeurs vont être perturbés. Une fois encore, si on se rend pas de suite compte de la boulette, il faut du courage.
Faire des alias bash est peu pertinent pour les commandes git simples vu que git permet de faire des alias git (et éloigne le risque d'une mauvaise frappe du coup)
git config --global alias.wip "commit -am '--wip--'"
git config --global alias.unwip "reset HEAD^"
Il faut maintenant taper git wip et git unwip, comme ça on sait que ce sont des commandes git et pas autre chose.
Mais vraiment, c'est très mal ce genre de trucs et un workflow plus robuste est de faire beaucoup de petits commits puis éventuellement y remettre de l'ordre ensuite avec un rebase interactif.
via moi-même, développeur responsable git au boulot, qui passe une part non négligeable de mon temps à rattraper les boulettes des collègues et stagiaires aventureux qui font ce genre de choses.
Un github-like en Go (apparemment assez léger pour tourner sur un raspberry) et sous licence MIT.
Je me met ça de côté pour le boulot (jai besoin de l'authentification LDAP), ça semble très prometteur.
Ce truc explique simple un concept CRUCIAL pour ne plus avoir peur de faire des trucs compliqués (ou qui semblent compliqués) dans GIT.
N'ayez plus peur, tentez des trucs de malade, ça risque rien.
Tous les tuto gerrit commencent avec un git clone et se terminent après avoir pushé le 1er patch. TOUS ! Mais un logiciel il s'arrête pas au premier patch, comment on fait pour continuer ? C'est trivial ? C'est compliqué ? Impossible de savoir. Jusque maintenant.
Après des jours de recherche j'ai finalement trouvé un workflow clair pour utiliser Gerrit.
Plein d'options à rajouter dans la config git et leur explication.
Et un nouvel abonnement RSS \o/
J'ai ouvert mes dépots git au monde :)
Je débute encore avec GIT donc vous risquez de voir pas mal de non-sens surtout au niveau des branches (merge me fait peur)
Le plus utile sera le dépot shaarli je pense. La branche master constitue ma version, l'originale de Sebsauvage est dans la branche «Original» du coup vous pourrez installer Shaarli avec un simple « git clone -b Original http://git.aldarone.fr/clone/php/shaarli.git » et le mettre à jour avec « git pull »
Pour chaque version sortie par Seb je ferai un tag -Alda et un tag -Seb correspondant à nos versions respectives.
Les différences entre les 2 ? Principalement mon thème (qui inclue des boutons de partage vers les réseaux sociaux et qui a un design « responsive ») et l'activation par défaut du protocole pubsubhubbub.
Un github-like en RoR à mettre sur son propre serveur. (Utilise Gitolite et SQLite)