{"id":971,"date":"2012-03-16T17:11:52","date_gmt":"2012-03-16T16:11:52","guid":{"rendered":"http:\/\/blog.kodono.info\/wordpress\/?page_id=971"},"modified":"2012-08-23T15:34:31","modified_gmt":"2012-08-23T13:34:31","slug":"howto-github","status":"publish","type":"page","link":"https:\/\/blog.kodono.info\/wordpress\/howto-github\/","title":{"rendered":"HowTo GitHub"},"content":{"rendered":"

L’utilisation de GitHub<\/a> n’\u00e9tant pas triviale, j’ai d\u00e9cid\u00e9 de r\u00e9unir ici mes d\u00e9couvertes quant \u00e0 ce service et la fa\u00e7on de l’utiliser (ce document sera mis \u00e0 jour au fur et \u00e0 mesure donc<\/em>).<\/p>\n

Remarque<\/strong>: GitHub a sorti un petit test grandeur nature pour mieux connaitre GitHub… Et c’est \u00e0 essayer sur http:\/\/try.github.com\/<\/a><\/p>\n

Commencer<\/h1>\n

Il faut d’abord vous cr\u00e9er un compte, puis suivez le tutoriel qui est simple: http:\/\/help.github.com\/set-up-git-redirect<\/a>.<\/p>\n

\nA savoir<\/strong> – Git est sensible \u00e0 la case, cela signifie que les majuscules\/minuscules sont importantes dans votre pseudo<\/strong>.\n<\/div>\n
\nA savoir<\/strong> – Il vous est demander de cr\u00e9er une passphrase<\/strong> : il faudra vous en rappeler car vous l’utiliserez \u00e0 chaque push<\/code> et autres commandes.\n<\/div>\n

Cr\u00e9er un d\u00e9p\u00f4t (repository<\/i>)<\/h1>\n

Vous pouvez commencer par lire le guide de GitHub<\/a> mais il devient vite confus…<\/p>\n

\nA savoir<\/strong> – Git est sensible \u00e0 la case, cela signifie que les majuscules\/minuscules sont importantes dans votre nom de repository<\/strong>.\n<\/div>\n

Par d\u00e9faut vous allez cr\u00e9er une branche appel\u00e9e master<\/b>. Typiquement c’est l\u00e0 o\u00f9 vous allez mettre vos sources.
\nMais sachez qu’il est possible de faire h\u00e9berger des pages par GitHub. Cela peut \u00eatre la documentation de l’API que vous avez mis dans master<\/b>, ou un site de pr\u00e9sentation du projet que vous proposez (exemples avec http:\/\/twitter.github.com\/bootstrap\/<\/a> ou encore http:\/\/aymkdn.github.com\/SharepointPlus\/<\/a>).<\/p>\n

De fait, avant de lancer la commande git init<\/code> comme indiqu\u00e9 dans le tutoriel<\/a> (1. Create the README file<\/em>), il va falloir vous assurer que vous \u00eates dans le bon r\u00e9pertoire !
\nPrenons l’exemple de SharepointPlus<\/a> :<\/p>\n

Actuellement sur mon ordinateur j’ai deux r\u00e9pertoires :
\n→ disons D:\/Dev\/API\/SharepointPlus\/<\/code> o\u00f9 est stock\u00e9 mon fichier sharepointplus-x.x.js<\/code> et mon fichier changelog<\/code>;
\n→ et un autre r\u00e9pertoire D:\/Doc\/Auto Generate\/SharepointPlus\/<\/code> avec index.html<\/code> et toute ma documentation.<\/p><\/blockquote>\n

Tout ce qui concerne les fichiers API JavaScript seront stock\u00e9s dans ma branche par d\u00e9faut (master<\/em>).<\/p>\n

Donc la commande git init<\/code> doit \u00eatre faite dans le r\u00e9pertoire D:\/Dev\/API\/SharepointPlus\/<\/code>. Vous pouvez maintenant continuer \u00e0 suivre le tutoriel de GitHub<\/a>.<\/p>\n

\nA savoir<\/strong> – Le fichier README<\/code> sera lu directement par GitHub lorsqu’on visualisera votre repo. Si vous voulez le mettre en forme, alors il faut lui rajouter l’extension .md<\/code> (MarkDown<\/em>). Vous pouvez cr\u00e9er d’autres fichiers avec l’extension .md<\/code> (example<\/a>) : tous ces fichiers utilisent une syntaxe qui leur est propre et qui est d\u00e9crite dans http:\/\/github.github.com\/github-flavored-markdown\/<\/a> et sur http:\/\/daringfireball.net\/projects\/markdown\/basics<\/a>.\n<\/div>\n

Cr\u00e9er des pages h\u00e9berg\u00e9es par GitHub<\/h2>\n

On a donc cr\u00e9\u00e9 notre d\u00e9p\u00f4t et on a cr\u00e9\u00e9 une branche master<\/em> pour nos scripts.
\nMaintenant on souhaite h\u00e9berger quelques pages, et pour cela je vous invite \u00e0 lire le guide de GitHub<\/a>.<\/p>\n

Comme vous allez le d\u00e9couvrir, il faut cr\u00e9er une nouvelle branche, qui se nomme gh-pages<\/em> et qui contiendra nos fichiers HTML (avec un index.html<\/code> \u00e0 la racine).<\/p>\n

Dans mon exemple pr\u00e9c\u00e9dent, je vais donc devoir me mettre cette fois dans le r\u00e9pertoire D:\/Doc\/Auto Generate\/SharepointPlus\/<\/code> avant de lancer la commande git symbolic-ref HEAD refs\/heads\/gh-pages<\/code><\/p>\n

L\u00e0 encore le site n’est pas forc\u00e9ment tr\u00e8s clair, donc voici les commandes qu’il faudra taper :<\/p>\n

\r\ngit init\r\ngit symbolic-ref HEAD refs\/heads\/gh-pages\r\ngit add .\r\ngit commit -m 'first commit'\r\ngit remote add origin git@github.com:VOTRE_USERNAME\/NOM_DU_REPOSITORY.git\r\ngit push origin gh-pages\r\n<\/pre>\n
\nVous remarquerez que dans le bash de Git, lorsqu’on est dans une r\u00e9pertoire li\u00e9 \u00e0 un compte GitHub, on va voir entre parenth\u00e8se le nom de la branche. Par exemple pour gh-pages<\/em> je verrai D:\/Doc\/Auto Generate\/SharepointPlus\/ (gh-pages)<\/code>\n<\/div>\n
Envoyer des fichiers dans le d\u00e9p\u00f4t<\/h1>\n
Il y a trois commandes \u00e0 retenir.<\/p>\n
    \n
  1. git add file1 file2 ...<\/code> : ajouter tous les fichiers que vous souhaitez envoyer<\/li>\n
  2. git commit -m \"description\"<\/code> : indiquer gr\u00e2ce \u00e0 “description” les modifications que vous avez effectu\u00e9s<\/li>\n
  3. git push origin master<\/code> : “master” est le nom de la branche (\u00e7a peut donc \u00eatre aussi “gh-pages” ou autre)<\/li>\n<\/ol>\n
    \nAstuce<\/strong> – vous pouvez utiliser le point (.) avec la commande add<\/code> pour ajouter tous les fichiers du r\u00e9pertoire courant.\n<\/div>\n
    A noter que tous les commandes Git sont disponibles dans cette cheat sheet<\/a>.<\/p>\n
    Modifications distantes<\/h1>\n
    \u00c9diter en ligne<\/h2>\n
    Saviez-vous qu’il est possible d’\u00e9diter directement en ligne ses fichiers ? Il suffit d’aller dans son d\u00e9p\u00f4t et de visualiser un fichier. Vous verrez un “Edit” dans les menus. <\/p>\n
    R\u00e9cup\u00e9rer localement les modifications distantes<\/h2>\n
    Si des fichiers de votre d\u00e9p\u00f4t ont \u00e9t\u00e9 modifi\u00e9s (par vous ou quelqu’un d’autre), vous pouvez simplement r\u00e9cup\u00e9rer simplement ceux-ci en local gr\u00e2ce \u00e0 la commande git pull<\/code> (qui est l’\u00e9quivalent de la commande git fetch<\/code> suivie par un git merge origin\/master<\/code>). Cela va avoir pour effet de fusionner vos fichiers locaux avec ceux qui sont dans le d\u00e9p\u00f4t distant (branche master).<\/p>\n
    Si jamais le syst\u00e8me n’est pas capable de fusionner (merge) deux fichiers ensembles (par exemple dans le cas o\u00f9 vous avez modifi\u00e9 la m\u00eame ligne dans les deux fichiers), alors il va y avoir un conflit et vous devez le g\u00e9rer manuellement :<\/p>\n
    CONFLICT (content): Merge conflict in xxxxx
    \nAutomatic merge failed; fix conflicts and then commit the result.<\/p><\/blockquote>\n
    Pour g\u00e9rer ce conflit, vous devez d’abord installer Beyond Compare 3 (bc3)<\/a>. Je pr\u00e9cise que le programme est gratuit en mode standard (mais, une fois install\u00e9, vous pouvez d\u00e9bloquer des fonctionnalit\u00e9s en l’achetant et en passant alors en PRO). Selon l\u00e0 o\u00f9 vous l’installez vous devrez peut-\u00eatre configurer le chemin d’acc\u00e8s (path). Si vous ne faites pas cela, alors \u00e0 la commande git mergetool<\/code> vous aurez l’erreur suivante :<\/p>\n
    libexec\/git-core\/mergetools\/bc3: line 9: bcompare: command not found<\/p><\/blockquote>\n
    Pour r\u00e9soudre ce probl\u00e8me, vous devez configurer le path vers le fichier bcompare<\/a>; tapez dans la console git les commandes suivantes (pensez \u00e0 mettre votre path vers le fichier) :
    \ngit config --global merge.tool bc3<\/code>
    \ngit config --global mergetool.bc3.path \"c:\/program files\/beyond compare 3\/bcomp.exe\"<\/code><\/p>\n
    Une fois “Beyond Compare” install\u00e9 et configur\u00e9, alors retapez la commande git mergetool<\/code> qui va vous ouvrir le programme et vous pourrez parcourir votre fichier et faire les modifications n\u00e9cessaires.<\/p>\n
    Autres ressources<\/h1>\n
    Comprendre GitHub<\/a>
    \n    Toutes les commandes Git en fran\u00e7ais<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    L’utilisation de GitHub n’\u00e9tant pas triviale, j’ai d\u00e9cid\u00e9 de r\u00e9unir ici mes d\u00e9couvertes quant \u00e0 ce service et la fa\u00e7on de l’utiliser (ce document sera mis \u00e0 jour au fur et \u00e0 mesure donc). Remarque: GitHub a sorti un petit test grandeur nature pour mieux connaitre GitHub… Et c’est \u00e0 essayer sur http:\/\/try.github.com\/ Commencer Il […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","hide_page_title":"","footnotes":""},"class_list":["post-971","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/pages\/971","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/comments?post=971"}],"version-history":[{"count":17,"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/pages\/971\/revisions"}],"predecessor-version":[{"id":1000,"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/pages\/971\/revisions\/1000"}],"wp:attachment":[{"href":"https:\/\/blog.kodono.info\/wordpress\/wp-json\/wp\/v2\/media?parent=971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}