Github & git

robin4002

Salut à tous.

Premier tutoriel “hors forge”, où nous allons voir comment utiliser git et l’application github. Ce tutoriel ne s’applique donc pas que à minecraft, mais à n’importe quel projet.

Présentation

Git est un logiciel de gestion de versions décentralisé créé par Linus Torvalds. Il permet donc stocker les fichiers de votre projet à différent moment. Le principe est assez simple, vous devez commités vos codes, chaque commit correspond donc à une version de votre projet. Il existe d’autres logiciels comme mercurial, mais nous ne verrons que git dans ce tutoriel.
Github est un hébergeur, qui va héberger vos fichiers. Il en existe d’autre, tel que bitbucket, google code et sûrement de nombreux autres.

À quoi ça va servir ?
Grâce à git et github, on peut donc mettre ses codes sources en ligne, et garder différente version de ses codes sources. Les dépôts sur github peuvent être soit publics (donc open source) soit privés (seul vous et les collaborateurs ont accès, mais c’est payant).
L’intérêt est donc de partager son savoir, pouvoir récupérer ses sources à n’importe quel version (très pratique par exemple si vous faite une grosse connerie qui provoque pleins de bug, vous pouvez facilement revenir en arrière) mais surtout, de collaborer. En effet, vous ajoutez des contributeurs à vos projets, ou encore créer une organisation (exemple MinecraftForge). D’ailleurs, grâce au système de “fork” et de “pull request” n’importe qui peut proposer un changement dans vos projet, et vous pouvez soit l’accepter, soit le refuser, ainsi n’importe qui peut contribuer à vos projets.

Installation et inscription

Git peut être téléchargé ici : http://git-scm.com/downloads
(Si vous êtes sous ubuntu, vous pouvez directement l’installer depuis la logithèque).

Git s’utilise entièrement en ligne de commande, si vous êtes sous windows ou sous mac, vous pouvez utiliser l’interface github for Windows/Mac. Elle ne permet pas de faire tout ce qu’on peut faire en ligne de commande, mais elle permet de faire le plus important.

L’inscription sur github est simple, allez sur le site, choisissez un pseudo, entrez votre email, et un mot de passe.
Ensuite vous devez confirmer votre compte par émail. Rendez-vous sur l’accueil de github. Vous devez voir quelque chose comme ceci :

Ici vous trouverez de quoi bien commencer avec git et github, en revanche c’est en anglais. Pour ceux qui n’aime pas l’anglais, je vais expliquer ici les commandes les plus importantes.

Utilisation

Comme dit plus haut, git s’utilise en ligne de commande, sous Linux et Mac, tout passe directement par le terminal, sous Windows, un application Git bash devrait être disponible dans le dossier git de votre menu démarrer. Vous pouvez aussi utiliser git sur la console de windows en ajoutant git dans votre variable path. (La manipulation est la même que pour java, le chemin à ajouter est C:/Program Files (x86)/Git/bin/ ou C:Program Files/Git/bin/ si vous avez un système 32 bits, pensez au point virgule qui sépare les chemins).

Si vous utilisez l’application pour Windows et Mac, il suffit juste de la lancer et de suivre les instructions. Au moment où je fais ce tutoriel je suis sous linux, et comme de toute façon l’interface ne permet pas de tout faire, je vais vous apprendre à utiliser git en ligne de commande.

Pour commencez, il faut configurer git :

git config –global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Optionnel, sert à activer la couleur.

git config --global user.name "Votre pseudo"

C’est le pseudo qui sera affiché sur les commit, sur github votre émail sera utilisé et associé à votre compte github, mais dans l’historique de git, c’est ce nom qui apparaîtra.

git config --global user.email "votre@email.com"

Votre émail, il est important de mettre la même que sur github pour que github associe vos commit à votre compte, sinon l’auteur du commit ne sera pas reconnu (pas très grave, ne cause aucun problème en soit, mais on ne sait pas que c’est vous).

Une fois git configurer, retournez sur github, et créez un nouveau dépôt. Sur la page d’accueil de github, tous vos dépôt sont listés, et il y a un bouton “new repository”.
Nommez le dépôt, et ajoutez si vous le souhaitez une description :

Vous pouvez initialiser le dépôt avec un readme, un gitignore, et même une licence.
Une fois créé, si vous utilisez l’application vous devrez le voir apparaître sur la liste. Sinon il faut clone le projet, pour ça, retour sur le terminal.
Je vais créer un dossier ou je vais placer tous mes dépôts github. Pour changer de dossier avec le terminal, utilisez la commande cd. Pour cloner le projet utilisez :

git clone https://github.com/robin4002/Tutoriel-github.git

L’adresse se trouve sur le côté de votre projet github :

(cliquez sur l’encadré en rouge pour l’enregistrer directement dans le presse-papier)
Vous avez maintenant une copie local du projet, où vous pouvez modifier/supprimer/ajouter des fichiers.
Maintenant, il faut se déplacer dans le dossier du projet. (cd Tutoriel-github/)
Après quelques modifications, j’entre la commande :

git status

J’obtiens :

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   README.md
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# fichier
no changes added to commit (use "git add" and/or "git commit -a")

On voit ici que j’ai modifier le fichier README.md et que j’ai ajouter un nouveau fichier nommé “fichier” (quelle inspiration !). En revanche pour l’instant ces fichiers ne sont pas “commités”.
Il faut ajouter les fichiers au futur commit avec git add <nom du=“” fichier=“”>ou alors je peux commiter en utilisant le paramètre -a pour ajouter tous les fichiers modifiés.
Maintenant :

git add .
git status

Petit rappel, le dossier . correspond au dossier actuel. Avec la commande git add . j’ai donc ajouté tous les fichiers modifiés au commit. git add * à le même effet. Vous pouvez ajoutez individuellement les fichiers si vous ne souhaitez pas commit tous les fichiers que vous avez modifiés.
Ensuite voila ce que me donne la commande status :

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   README.md
# new file:   fichier
#

Les deux fichiers ont bien été ajoutez et sont prêt à être commité. La commande git status est très pratique pour se retrouver, apprenez-la donc. Comme indiqué, vous pouvez utiliser git reset HEAD <nom du=“” fichier=“”>pour le retirer.

git commit -m "premier commit"

On commit maintenant les fichiers, -m et un paramètre pour mettre la description du commit.
Maintenant git status donne ceci :

# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)
#

On voit que j’ai un commit en plus que origin/master. origin/master correspond au dépôt sur github, vous pouvez ajouter des nouveaux “remote” nous verrons ça avec les “fork”.
Pour synchroniser il faut utiliser :

git push origin master

origin est donc le nom du remote par défaut, master est la branche principale, nous verrons aussi ceci plus bas.
À l’inverse de push, la commande

git pull origin master

sert à synchroniser votre dépôt local par rapport à “origin”.

Collaboration :
Pour ajouter des amis à votre projet, il faut aller dans Setting -> Collaborators. Vous devrez entrer votre mot de passe, et ensuite il suffit d’entrer le pseudo github du collaborateur.
Si vous coder à deux sur un projet, vous allez rapidement vous retrouver dans cette situation :

La première personne a ajouté un mob, il a donc fait la classe du mob, les rendus, a mit les codes dans le proxy et dans la classe principale.
La deuxième personne a ajouté un bloc, il a donc fait la classe du bloc, et modifié la classe principale.
La première personne commit, synchronise, tout va bien.
Le deuxième personne commit, synchronise, et la, plus rien ne fonctionne
Si vous utilisez l’application github, un message d’erreur, et il vous proposera de “open shell”, cliquez sur cette option.
Si vous êtes déjà en ligne de commande, pas de problème. Si vous n’avez pas commité vos changements, faite-le, ensuite synchroniser votre dépôt local :

git pull origin master

Vous verrez quelque chose du genre conflict : <fichier>(si git passe en rebase, faite git rebase --abort, nous n’avons pas besoin du rebase).
Ouvrez ces fichiers, dedans, git à fusionner les deux codes, vous aurez dans le fichier des HEAD ===
Modifiez les fichiers qui ont des conflits comme vous le souhaitez.
Ensuite, commitez à nouveau, et synchronisez :

git commit -a -m "fix merge conflict"
git push origin master

Et voila, le conflit devrait être réglé.

Github vous permet aussi de faire des organisations, pour en faire une, allez dans l’accueil de github, cliquez sur la flèche à côté de votre pseudo (à gauche, pas à droite) et faite “create Organization”. Vous pouvez créer des groupes dans votre organisation, leur attribuer les permissions sur x projet, mettre x personnes dans ce groupe, etc …

Le “fork” :
Vous pouvez “fork” n’importe quel projet à l’aide du bouton en haut à droite du projet github. Cela va créer une copie du dépôt dont vous serez le propriétaire. C’est très pratique pour reprendre un projet mort, faire une version dérivé d’un projet, pour faire un addon de ce projet ou encore pour contribuer à un projet dont vous n’êtes pas le propriétaire.
Une fois fork, le projet vous appartiens, vous pouvez donc le cloner, modifier les fichiers en local, commiter et synchroniser. Lorsque vous avez des commits en plus que le projet d’origine, vous devrez voir apparaître sur votre projet (sur github) un petit texte qui dit que vous avez x commit en plus que le projet d’origine. Vous pouvez faire une comparaison, et ensuite envoyer un pull request. Les changements que vous avez fait seront donc envoyer sous forme de proposition, et le propriétaire du projet d’origine pourra soit accepter soit refuser vos changements.

S’il y a eu des nouveaux commit dans le projet d’origine et que vous souhaitez mettre à jour votre fork, vous pouvez utiliser :

git remote add upstream <urldu fichier .git>

(exemple https://github.com/BuildCraft/BuildCraft.git). Cela va ajouter un nouveau remote nommé upstream, vous pouvez le nommé autrement.
Cette commande n’a que besoin d’être fait une fois sur le projet, le remote ne disparaît pas.

git pull --rebase upstream master

Cela va synchroniser la branche master du remote “upstream” (que nous avons défini juste au dessus) dans la branche actuelle. Le paramètre --rebase évite les commits double, si vous ne le faite pas, et que vous envoyez un pull request, tous les commits qui ont été synchronisés depuis le projet “upstream” vont aussi apparaître dans le pull resquest, ce ne sera pas propre.

Les branches :
Git a un système de branche, c’est très pratique lorsque vous avez plusieurs versions maintenue à jour en même temps. Par exemple, vous vous lancez dans une version 2.x de votre mod, mais elle est très buggué, vous souhaitez donc maintenir à jour la version 1.x de votre mod en attendant de stabiliser la 2.x. Ou alors, un exemple qui va arrivé très bientôt, lorsque forge 1.7 sera disponible, vous allez travailler sur la 1.7, mais comme la 1.7 est une longue mise à jour, vous continuez à corriger les bugs de la version 1.6.4.
Dans ces deux cas, les branches sont très pratiques.
Pour créer une nouvelle branche :

git branch 1.7.2

Créer une branche 1.7.2.

git checkout 1.7.2

Vous déplace dans la branche 1.7.2. Maintenant toutes les commandes que vous faites seront fait dans la branche 1.7.2.
Le principe est le même, pour synchroniser le dépôt sur github :

git push origin 1.7.2

La première fois, cela va publier la branche.

git pull origin 1.7.2

pour synchroniser votre dépôt local. Pour retourner sur la branche principale :

git checkout master

Maintenant je vais faire quelques changements sur la branche 1.7.2, comme si je mettais à jour mon mods. Une fois que mon mod est stable, je décide de ne plus supporter la 1.6.4, je fais donc fusionner ma branche 1.7.2 sur la branche master :

git checkout master #je reviens dans ma branche principale
git merge 1.7.2 #fusionne la branche 1.7.2 dans la branche actuelle (donc dans master)
git push origin master #je synchronise

Ensuite vous pouvez supprimer la branche en local avec :

git branch -d 1.7.2

Et sur github dans la section branches -> view merged branches -> delete branch.

Eclipse et votre dépôt git

Vous avez sûrement remarqué que git ne détecte que les changements dans le dossier du repo, et non dans votre dossier mcp/src/minecraft.
Il faut donc copier les sources à chaque fois, et c’est très chiant, on perd du temps. Heureusement, il est possible de lier un dossier à un projet eclipse.

Dans le dossier du dépôt de votre projet, créez deux nouveaux dossier. Un dossier “common” dans lequel vous allez mettre tous les fichiers .java commun au serveur et au client, et un dossier “resources” où vous allez mettre tous le reste (sons, images, etc …)
Inutile de faire un dossier client et server comme les mods sont universels depuis la 1.3.2.

Ensuite lancer eclipse normalement, dans la workspace de mcp. Déplacez les fichiers de votre mods qui sont dans forge/mcp/src/minecraft vers le deux dossier que vous avez créé avant.
Une fois eclipse lancé, faite un clic droit sur le projet Minecraft -> build path -> configure path build. Une fenêtre s’ouvre, allez dans l’onglet sources, et cliquez sur “Link source …”
Sélectionner le dossier common de votre mod :

Choisissez le nom du dossier dans le projet :

Puis faite la même chose avec le dossier resources et tous vos mods, résultat final :

Et maintenant lorsque je modifie un fichier, il est changer dans le dossier du dépôt git correspondant.

/!\ Attention, les sources ne sont plus dans forge/mcp/src/minecraft, mais dans <votre dossier git>/<nom du dépôt git>/common et <votre dossier git>/<nom du dépôt git>/ressource pour les images. Lorsque vous suivrez des tutoriels, il faudra y penser !

D’ailleurs ce changement qui offre un gros avantage, cause aussi un gros problème, en effet, comme les sources ne sont plus dans le dossier de mcp, recompiler et obfuscater ne fera plus rien !
Mais chaque problème a une solution, c’est pour ça que nous allons voir dans le prochain tutoriel comment compiler automatiquement votre mod avec ant, ainsi les taches de recompilation, de reobfcustation, la création de l’archive, et l’ajout des textures dans l’archive seront automatique, il vous suffira d’un seul clic pour lancer tout ça

Questions / Réponses

Rien pour le moment.

Superloup10

Comment fonctionne l’installation sous linux, stp?

robin4002

sudo apt-get install git en ligne de commande, ou git dans la logithèque si tu utilise ubuntu.

Superloup10

Ok, pour info, je me suis converti au dual-boot.

robin4002

Comme moi
(enfin, j’ai un pc en dual boot ubuntu/win7 et un full ubuntu car de toute façon seven tourne pas bien dessus)

Superloup10

Moi, c’est Win7/ubuntu.

utybo

Perso Win7/Kubuntu

Norskel

Moi c’est Mac/windows7

^^

legeek11202

Très bon tuto mais le truc que je déteste le plus c’est que l’on soit obligé de payer pour le private :/, du coup j’utilise SVN
Perso:
Je compte me mettre en Win8.1/Xubuntu :x

robin4002

https://bitbucket.org/ permet aussi de faire des repo privés gratuitement.