Git
Nous utilisons une instance locale de Gitlab pour gérer nos dépôts. Nous utilisons donc le système de gestion des dépôts Git. Nous récupérons aussi les données de Ryzom Core qui utilise le système de gestion des dépôts Mercurial.
Voir aussi les principes de base et comment récupérer les données propres à Khaganat, ainsi que Gitflow. Les possibilités de Gitlab sont très bien présentées sur l'article Gérer des projets avec Gitlab.
Les indications d'installation sont données pour un système basé sur Debian, il suffit d'adapter la commande apt-get
à votre propre distribution/OS.
Installer et paramétret Git chez soi
Commencez par installer git sur votre ordinateur.
sudo apt-get install git
Paramétrez ensuite votre git, de façon globale. Commencez par indiquer votre nom d'utilisateur, puis votre email :
git config --global user.name "Votre Nom Ici"
git config --global user.email moi@example.com
Trouvez dans quel dossier vous souhaitez gérer votre projet (en local). Au besoin créez ce dossier. Mettez-vous dans ce dossier en console :
mkdir Monprojet cd Monprojet
Ensuite, tout dépend de si vous démarrez depuis un projet en local, ou si vous mettez aussi votre projet en ligne, par exemple sur Github ou notre Gitlab
Se connecter à un projet Github
Il faut indiquer à quelle source se nourrir.
Si vous avez déjà un projet sur Github que vous souhaitez copier en local,
git clone https://github.com/user/monprojet.git
Adaptez user/monprojet
à l'adresse url du projet et n'oubliez pas le .git à la fin. Le projet sera copié dans le dossier où vous êtes.
Si vous n'avez pas de projet sur Github (mais un compte),
git init
Cela créé un dossier caché où git stockera les infos. Vous pouvez ensuite ajouter l'adresse via la commande suivante :
git remote add origin https://github.com/user/monprojet.git
Il faudra ensuite “push” vos modifications vers le projet en question.
Pour contrôler que tout va bien :
git remote -v
Afin de ne pas retaper son mot de passe à chaque “push”, vous pouvez configurer ssh pour vous connecter directement à votre compte.
Commencez par générer votre clé ssh si ce n'est pas déjà fait et assurez-vous que l'agent ssh est lancé :
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
Ouvrez le fichier ~/.ssh/id_rsa.pub
, copier tout, puis rendez-vous sur Github. Dans “Setting”, dans votre compte, sélectionnez “SSH keys”. Copiez votre clée publique. Indiquez ce que vous voulez en titre, seul vous le verrez. Cliquez sur “Add key”, entrez votre mot de passe. Pour vérifier que tout marche bien, faites :
ssh -T git@github.com
Si vous pouvez vous connecter c'est que ça marche.
Nous ne recommandons pas de passer uniquement par Github ; comme tout organisme centralisé et propriétaire, il est susceptible de dérive. Mais c'est actuellement une plate-forme connue et très utilisée, une façon comme une autre de commencer. Jusque là, il n'y a eu aucune alerte sur leurs pratiques.
Notre instance gitlab n'est pas très puissante et, de ce fait, uniquement ouverte aux projets en rapport avec Khaganat.
Pour les projets sur notre gitlab, il faut se connecter via ssh. Regardez l'adresse dans Dépôts
> Clone
. Cela devrait être quelque chose comme
git clone ssh://git@git.khaganat.net:3543/monuser/test.git
Si l'adresse change, pour indiquer la nouvelle, c'est la commande suivante :
git remote set-url origin ssh://git@git.khaganat.net:3543/monuser/test.git
Commandes de base
Pour lister ce qui est à jour dans votre dossier :
git status
Les fichiers qui ne sont pas synchronisés seront en rouge, ceux qui attendent d'être placés dans un commit en vert.
Ajouter les nouveaux fichiers à git (en local) :
git add hello.txt git add *
Avec l'option *
, tous les nouveaux fichiers seront ajoutés.
Pour mettre à jour ce que vous avez ajouté/modifié :
git commit -m 'bla bla'
Les fichiers auront en commentaire votre “blabla” à cette version des modifications.
Ensuite, envoyez tout ça à un serveur :
git push
Cela utilise par défaut l'adresse que vous avez auparavant indiqué. Si vous envoyez sur Github, votre nom d'utilisateur et votre mot de passe sera demandé.
D'une branche à l'autre
Si vous ne voyez pas certains fichiers ou modifications, c'est sans doute qu'ils n'ont pas encore été intégré à master et sont sur une branche à part (voir l'organisation gitflow du travail).
Pour lister toutes les branches, y compris celles qui ne sont pas décompressés depuis votre clone/pull :
git branch -r
Pour voir la liste des branches sur votre installation actuelle, qui ont été décompressées (l'astérisque devant une des branches indique celle sur laquelle on est) :
git branch
Récupérez le nom de la branche, puis changez :
git checkout develop
Pour récupérer directement une branche précise (par exemple ici le client) :
git clone -b develop ssh://git@git.khaganat.net:3543/khaganat/mmorpg_khanat/khanat-client.git
Et si vous voulez récupérer sans l'historique, par exemple juste pour tester le client en question sans s'encombrer, c'est l'option --depth 1
qui va être utile :
git clone -b develop --depth 1 ssh://git@git.khaganat.net:3543/khaganat/mmorpg_khanat/khanat-client.git
Voir aussi
- Branche de suivi distant sur Git Ready
Importer les nouveautés de Ryzomcore
J'utilise un fork de ryzomcore sur github à partir des sources
cd khanat_opennel_code git pull git checkout ryzomcore git remote add upstream https://github.com/ryzom/ryzomcore.git git fetch upstream
Essayer ça si vous utiliser les même sources
git merge upstream/develop git push origin
Et voila, c'est à jour :)
Si il y a des problemes de merge en changeant de source, mais ça reprend de zero
git reset --hard upstream/compatibility-develop git push origin ryzomcore --force
Annuler les modifications locales
Parfois, lors d'un pull, ce message apparait : “error: Vos modifications locales aux fichiers suivants seraient écrasées par la fusion”.
Soit on fait un commit, on push, soit si ce n'est pas des trucs qu'on veut garder, on fait le bourrin et on efface :
git restore *
Un git status
ensuite devrait montrer que tout va bien et qu'on peut tirer depuis la branche amont.
Aider la compilation de nos projets
Gitlab permet aux utilisateurs d'aider à la compilation d'un projet en proposant la puissance de calcul de leurs ordinateurs personnels.
Installer et configures docker. En super utilisateur (faites sudo avant sinon), installez ce qui suis :
sudo apt install docker.io sudo systemctl start docker
Si vous voulez que le service docker démarre automatiquement avec votre ordinateur, vous pouvez aussi faire
sudo systemctl enable docker
Toujours en root :
docker pull gitlab/gitlab-runner docker pull gitlab/gitlab-runner:alpine docker run -d --name gitlab-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner:alpine
Explication rapide :
-d
pour que ce soit en arrière plan,–name
pour donner un nom,–restart
va le redémarer automatiquement (au lancement de docker ou en cas de crash).-v
va lier des dossiers externes à des dossiers internes, sous forme de “[dossier interne]:[dossier externe]”. Ici par exemple, /etc/gitlab-runner sur le container sera lié à /srv/gitlab-runner/config sur votre machine.- enfin, il y a la sélection de l'image : ici, l'image “alpine” de gitlab/gitlab-runner.
Note : en cas de mise à jour de l'image, il faudra faire les commandes suivantes pour avoir l'image à jour supprimer le container :
docker pull gitlab/gitlab-runner:alpine docker rm -f gitlab-runner
puis recréer un container avec la commande précédente (docker run -d –name gitlab-runner –restart always -v /var/run/docker.sock:/var/run/docker.sock -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner:alpine
).
Docker fonctionne selon logique pull → rm → run.
À partir de là, nous avons un container docker “gitlab-runner”, qui va commander le docker de l'hôte lui-même au travers de “-v /var/run/docker.sock:/var/run/docker.sock”. C'est un socket unix, imaginez-le comme une connexion internet interne.
Il faut ensuite enregistrer ce “runner” sur le CI1).
sudo docker exec -it gitlab-runner gitlab-runner register
Vous aurez besoin d'information spécifique de votre projet. (à savoir l'URL et le “registration token” [définit : settings - CI/CD de votre projet GIT])
Ex.: https://git.khaganat.net/khaganat/mmorpg_khanat/opennel-pymanager/settings/ci_cd https://git.khaganat.net/khaganat/mmorpg_khanat/khanat-opennel-code/settings/ci_cd https://git.khaganat.net/khaganat/khanat/runners
Question | Réponse possible (à adapter) |
---|---|
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci): | https://git.khaganat.net/ci2) |
Please enter the gitlab-ci token for this runner: | Uxhiv1oGgNd6FECKDMn53) |
Please enter the gitlab-ci description for this runner: | un nom pour vous identifier dans la liste des runners, par exemple pseudo+OS |
Please enter the gitlab-ci tags for this runner (comma separated): | Docker,Linux |
Whether to run untagged builds | true |
Whether to lock the Runner to current project | true |
Please enter the executor: docker-ssh+machine, docker, docker-ssh, parallels, shell, ssh, virtualbox, docker+machine: | docker |
Please enter the default Docker image (eg. ruby:2.1): | ubuntu:16.044) |
Dans votre fichier .gitlab-ci.yml [présent dans votre GIT], il faut s'assurer d'avoir un tag identique (par exemple Docker)
Ressources utiles
- http://git-scm.com/book/fr/v1 : Un livre complet, en ligne et en français, sur comment utiliser Git. Très clair et détaillé.
- http://rogerdudler.github.io/git-guide/index.fr.html : un guide rapide, assez graphique.
- http://christopheducamp.com/2013/12/15/github-pour-nuls-partie-1/ : Un tuto un peu plus long, où chaque commande est expliquée
- http://ndpsoftware.com/git-cheatsheet.html : Un pense-bête très bien fait pour retrouver les commandes.
Grafikart propose une formation en ligne gratuite à Git, de très bonne facture.
Il y a en tout 16 chapitres et plus de trois heures de vidéo.
Vous pouvez soutenir son travail en vous abonnant sans que cela ne soit nécessaire pour visionner les cours.
En voici la vidéo d'introduction :
Voir aussi l'utilisation de Mercurial, un autre système de gestion de version.
Forges alternatives basées sur Git
Forges indépendantes documentées :
- NotABug.org : basée sur leur fork de Gogs dédiée à l'hébergement de projet sous licence libre. C'est un des projets de The Peers Community.
Divers membre du collectif C.H.A.T.O.N.S :
- TeDomum.net, association loi 1901, forge basée sur Gitlab CE, hébergement en France, semble ouvert à tous et à tout usage.
- roflcopter.fr, idem.
Autres forges moins documentée :
- en-root.org : basée sur Gitlab CE
- Forge de l'Adullact : basée sur Gitlab CE, orientée logiciels libres métier
- gitnet.fr : basée sur Gitea