Antichesse (o ^ω^ o)
En une ligne :
git commit --amend --date=now
Sûrement l'un des meilleurs message de commit au monde. Non pas parce que le ratio code/message est complètement barré mais parce qu'il explique pourquoi ce commit existe et non pas ce qu'il a modifié. Dit autrement, avec un moteur de recherche qui taperait dans les logs, chaque répo Git deviendrait une base de connaissance équivalente à StackOverflow.
Et Epstein ne s'est pas tué lui-même dans sa cellule #Epstein.
Coudifié ! Tout est dans le titre.
Le concept du Test, Commit, Revert (TCR) est sympa.
Comment notre façon de programmer est-elle devenue asynchrone et bloquante ? C'est vrai que je passe mon temps à revenir sur des pull-requests qui ont eu lieu plusieurs jours auparavant ; et c'est dur à chaque fois ! J'aime coder et oublier le code que je viens de coder aussitôt que la PR part. Je n'aime pas qu'on me relance sur un sujet que j'ai fermé car c'est une charge cognitive forte et épuisante et pourtant ce modèle est devenu le modèle "standard".
=> Pour @Chlouchloutte
Via Riduidel
Parce que je ne m'en souviens jamais de la commande magique : git rebase -i HEAD~X
où X et le nombre de commits à fusionner depuis le HEAD (HEAD inclus)
Puis penser à remplacer de bas en haut les pick des lignes du début par des squash (tout ce qui est squash sera fusionné avec le commit de la ligne au-dessus).
@Lenny qu'en penses-tu ?
Writing Good Commit Messages
Rule zero: “good” is defined by the standards of the project you're on. Have a look at what the existing messages look like, and try to emulate that first before doing anything else.
Having said that, here are some things that will help your commit messages be useful later:
Treat the first line of the message as a one-sentence summary. Most SCM systems have an “overview” command that shows shortened commit messages in bulk, so making the very beginning of the message meaningful helps make those modes more useful for finding specific commits. It's okay for this to be a “what” description if the rest of the message is a “why” description. Fill out the rest of the message with prose outlining why you made the change. The guidelines for a good “why” message are the same as the guidelines for good comments, but commit messages can be signifigantly longer. Don't bother reiterating the contents of the change in detail; anyone who needs that can read the diff themselves. If you use an issue tracker (and you should), include whatever issue-linking notes it supports right at the start of the message, where it'll be visible even in shortlogs. If your tracker has absurdly long issue-linking syntax, or doesn't support issue links in commits at all, include a short issue identifier at the front of the message and put the long part somewhere out of the way, such as on a line of its own at the end of the message. Pick a tense and a mood and stick with them. Reading one commit with a present-tense imperative message (“Add support for PNGs”) and another commit with a past-tense narrative message (“Fixed bug in PNG support”) is distracting. If you need rich commit messages (links, lists, and so on), pick one markup language and stick with it. It'll be easier to write useful commit formatters if you only have to deal with one syntax, rather than four. (Personally, I use Markdown on projects I control.) This also applies to line-wrapping: either hard-wrap everywhere, or hard-wrap nowhere.An Example
commit 842e6c5f41f6387781fcc84b59fac194f52990c7
Author: Owen Jacobson owen.jacobson@grimoire.ca
Date: Fri Feb 1 16:51:31 2013 -0500DS-37: Add support for privileges, and create a default privileged user. This change gives each user a (possibly empty) set of privileges. Privileges are mediated by roles in the following ways: * Each user is a member of zero or more roles. * Each role implies membership in zero or more roles. If role A implies role B, then a member of role A is also a transitive member of role B. This relationship is transitive: if A implies B and B implies C, then A implies C. This graph should not be cyclic, but it's harmless if it is. * Each role grants zero or more privileges. A user's privileges are the union of all privileges of all roles the user is a member of, either directly or transitively. Obviously, a role that implies no other roles and grants no priveleges is meaningless to the authorization system. This may be useful for "advisory" roles meant for human consumption. This also introduces a user with the semi-magical name '*admin' (chosen because asterisks cannot collide with player-chosen usernames), and the group '*superuser' that is intended to hold all privileges. No privileges are yet defined.
Tuto très sympa. @Lenny, si tu as le temps, essaie de lire ce post. Il y a quelques idées à prendre 😃.
La structure de commit que je propose (en reprenant ce que dit l'article) :
Summarize changes in around 80 characters or less
More detailed explanatory text, if necessary. Wrap it to about 120 characters or so. In some contexts, the first line is
treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from
the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get
confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code
explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain
them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank
lines in between, but conventions vary here
If you use an issue tracker, put references to them at the bottom, like this:
Resolves: #123
See also: #456, #789SUPPPPPPPPPPPPPPPER UTILE Je copie-colle !
Ce qu'il faut éviter
Pour annuler des commits, il existe la commande git reset.
git reset --hard HEAD~1
HEAD is now at 444b1cf RhooCelle-ci est pertinente tant que les commits n'ont pas été poussés. Git vous retiendra au push d'ailleurs :
git push
To /tmp/repo
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '/tmp/repo'En effet, à partir du moment où un commit existe sur le serveur, il est potentiellement utilisé par des collaborateurs (mergé, à la base d'une branche, etc.). On pourrait faire le sale et forcer le push :
git push -f
Total 0 (delta 0), reused 0 (delta 0)
To /tmp/repo
+ b67c343...444b1cf master -> master (forced update)Mais il y a beaucoup mieux !
Ce qu'il faut faire
Annuler un commit, c'est finalement appliquer l'inverse de son diff !
On peut rediriger le diff des commits à annuler vers la commande patch --reverse :)
git diff HEAD^ | patch --reversePour faire plus simple, il y a git revert !
Par exemple pour annuler les trois derniers commits :
git revert HEAD~3..HEADOu pour annuler un commit en particulier :
git revert 444b1cffIl suffit alors de pousser proprement le commit obtenu sur le serveur. Les éventuels collaborateurs qui avaient basé leur travail sur les commits annulés devront gérer les conflits au moment venu...
Ettttttttttttttttttt bîme !!!!! MERCIIIIIIII MILLE MERCI !!!!!
Chlouchloutte, #spourtoi
A tout ceux qui ont l'appli McDonald installée sur leur mobile...
(Merci à Chlouchloutte pour le lien)
