Posté par zul .
En réponse au journal Pourquoi je contribue ?.
Évalué à 5.
Dernière modification le 01 septembre 2014 à 19:46.
La plupart des gens n'ont pas envie d'apprendre la CLI pénible de git. github est ce qui a rendu git utilisable pour le plus grand nombre.
Il n'y aucune façon d'utiliser github correctement sans connaitre git. Remarque, ça explique comment je me retrouve à avoir de nombreuses pull request à partir de la branche master d'un fork, rebasé 12 fois, avec 3 commits sans lien et des commits messages pourris. C'est ça "faciliter le boulot d'un mainteneur".
Le workflow 'normal' d'une proposition de patch pour github à partir de rien, c'est
se loger sur github : click click
forker le projet : click click
cloner ton fork : git clone .... (cli)
configurer le remote : git remote add ... (cli)
créer une branche feature : git checkout -b my_feature (cli)
coder, commiter : git add ..., git commit (cli)
pusher sur ma branche : git push origin my_feature (cli)
resortir son navigateur et appuyer sur pull request (click click + tapoter une explication).
vs
cloner le dépot : git clone ... (cli)
créer une branche feature (cli)
coder, commiter (cli)
préparer un patch : git format-patch master (cli)
envoyer un mail avec le patch ou ouvrir un bug sur le bug-tracker
Je me demande qui est le plus barbu (ou si c'est pas franchement strictement équivalent).
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par zul . En réponse au journal Pourquoi je contribue ?. Évalué à 5. Dernière modification le 01 septembre 2014 à 19:46.
Il n'y aucune façon d'utiliser github correctement sans connaitre git. Remarque, ça explique comment je me retrouve à avoir de nombreuses pull request à partir de la branche master d'un fork, rebasé 12 fois, avec 3 commits sans lien et des commits messages pourris. C'est ça "faciliter le boulot d'un mainteneur".
Le workflow 'normal' d'une proposition de patch pour github à partir de rien, c'est
vs
Je me demande qui est le plus barbu (ou si c'est pas franchement strictement équivalent).