White Cat lighting board

White Cat Lighting Board Documentation

Outils pour utilisateurs

Outils du site


recettes_pour_git

par George modifié par Anton

Inutile de réinventer l'eau chaude, nous ne sommes pas les premiers à utiliser Git.

Ci-dessous, une liste de bons tutoriels, avec un bref commentaire pour chacun :

Documents recommandés par Léo le 27 janvier

Le Livre de Git est assez bien fait : http://git-scm.com/book/fr/

Il y a aussi : http://fr.openclassrooms.com/informatiq … e-avec-git (Les 2première pages)

Mais le top a l'air d'être http://www.miximum.fr/tutos/1546-enfin-comprendre-git (que je conseille de lire en premier)

Nos recettes pour Git

Petite introduction à git pour participer au projet whitecat.

Git c'est quoi?

Git, en vulgarisant, est un gestionnaire de versions et un outil de partage de code source. Non seulement il conserve un historique des diverses évolutions du code, mais tous les développeurs (dev) du projet auront accès au code en permanence, quand ils le voudront. Le code évoluera dans leur propre dossier de projet, mais aussi en fonction des avancées des autres dev. Ils pourront suivre ces modifications, les inclure ou pas, et travailler à plusieurs avec les autres.

Sur git chaque participant est un administrateur, le respect du travail collectif et individuel de chacun est donc de mise.

Si vous désirez juste télécharger les sources pour rester sur une version de whitecat purement personnel, vous le pouvez en cliquant à droite Download.

PARTICIPER AU PROJET OPENSOURCE

Si vous souhaitez participer au développement de WhiteCat sur des release existante, il va falloir ouvrir un compte Github pour être accepté comme collaborateur et pouvoir ainsi partager avec les autres via Git les améliorations et fonctions que vous avez développé.

Forker le dépot

Si vous désirez d'abord vous familiariser avec la gestion des sources avec git ou créer votre propre évolution du code sans être déranger, ou que vous n'êtes pas autoriser pour l'instant par ex à faire des modifications sur le dépôt central partagé ou que vous voulez juste faire des tests ou des changement sur les dépôt git sans polluer le dépôt central, vous pouvez toujours faire un fork.

Si vous n'êtes pas trop à l'aise avec git et la procédure de participation au dépôt commun, ou que vous voulez développer une autre partie de Whitecat, ou que vous n'avez pas encore lu intégralement le wiki git de whitecat (cette page), c'est même conseiller, n'hésiter surtout pas sur la page d’accueil du dépôt à vous connecter avec votre nom d'utilisateur sur git, et cliquer sur le petit bouton Fork. Un nouveau dépôt sera créer à votre nom, ce travail vous appartient désormais, il vous à été donné, il est opensource, vous en faite à présent ce que vous voulez, si vous le modifier ou l'améliorer et diffuser votre travail, vous devrez aussi diffuser les modifications que vous avez faites, les contributions des autres et le code sources d'origine afin que votre travail puisse profiter à d'autre, être réutiliser par la communauté whitecat, de la même manière que ce travail vous à été donné (licence GPL v2).

Si vos modifications faite dans ce Fork sont suffisamment clair (dans des branch indépendantes) et que vous souhaiter les partagé, les administrateurs, si la communauté le souhaite, pourrons réintégrer par la suite au dépôt commun votre travail et il sera profitable à tous, de la même façon que le travail précédent vous à été offert.

Participer sur les dépots commun

La lecture intégral de ce wiki est aussi nécessaire à la participation au projet global directement sur des dossiers partagés.

Attention, sur Git, chaque collaborateur est aussi administrateur, et chaque modification se répercutera aussi sur tout les autres et sur toute la communauté, donc le respect du dépôt, du travail collectif et individuel de chacun est de mise.

Un post de présentation est ouvert sur le forum. http://www.le-chat-noir-numerique.fr/forums/viewtopic.php?f=35&t=2355

Git est un vaste outil et permet énormément de chose, mais si vous travailler sur le dépôt partager, s'il vous plaît n'utiliser pas d'autres fonction que celle décrite dans le wiki, afin de ne pas faire trop d'erreurs sur les sources et le dépôt partagé par tous, et surtout facilité le travail des autres participant et administrateurs.

Les sources de whitecat sont codé en C et souvent de manière globale, et chaque modification dans un fichier peut avoir facilement des répercutions plus loin, donc:

- En cas de commit(modification du code source) non valable ou pas assez détailler pour être lisible directement sur le dépôt et sur une branch en cours, les divers membres de la communauté de dev se réserve le droit de faire un retour en arrière.

- En cas répétition de commit changeant trop de fonctions pour être lisible, sans les séparer en multiples commit, sur des branch commune, merge ou modification répéter du dépôt finalement nuisible ou illisible, ou l'utilisation d'outil non décrit dans ce wiki sans demande d'autorisation préalable à la communauté, ou du non respect de la procédure de partage (nouvelle fonction codé directement par ex dans la branch master au lieu d'une branch indépendante, commit illisible), un des administrateurs peut temporairement retirer des autorisations de participation au dépôt commun, afin de ne pas être submerger par la gestion du dépôt.

N'en soyez surtout pas vexé. Il ne s'agit pas forcement d'une remise en cause de vos capacités. En cas de problème avec git ou sur les sources n'hésiter pas à poser la question sur le forum .

Les dépôts @ChristophGuillermet sont les dépôts pour l'instant partager par la communauté, traiter les s'il vous plaît avec respect.

Si vous travailler directement sur le dépôt commun ChristophGuillermet/whitecat_crossplateform Veuillez s'il vous plait à suivre la procédure de collaboration décrite dans le guide de survie et le lire au moins une fois si vous travailler directement sur le dépôt de Christoph Guillermet afin de ne pas surcharger de travail les administrateurs:

- ne jamais travailler sur la branch master

- Les commits doivent être court, pas trop de changement de ligne de code, seul les modifications que l'on a réellement voulu faire doivent apparaitre dans le commit, avec un petit texte explicatif le plus détailler possible, afin de permettre aux autres développeurs et aux admins de ci retrouver.

- vérifier régulièrement son ou ses commits avant dans reposter, voir aussi les commits des autres, sur la page d'accueil git du dépôt whitecat.

- toujours créer une nouvelle branch à partir de la branch master si vous vous ne travailler pas sur une fonction particulière déjà en cours de dévellopement

La procédure est un peu laborieuse, mais permet de garder un équilibre sur les dépôt partagé.

Git en ligne de commande

Git s'utilise essentiellement en ligne de commande, par une console. Mais il est possible de l'utiliser aussi via une interface graphique (GUI). Pour Windows le plus simple est d'utiliser http://windows.github.com/.

L’installeur comprend l'application GUI GitHub et un shell (fenêtre en ligne de commande) configuré pour git.

C'est dans ce shell que nous rentrerons par la suite les différentes commande du tuto.

Installer Github Window

Créez vous un compte sur Github.com, c'est libre et gratuit. Vous aurez besoin d'un pseudo et d'un mot de passe vous permettant d'être membre de la communauté Github. Grâce à cet identifiant et ce mot de passe, vous pourrez participer au développement de Whitecat en mettant à jour le dépôt avec vos propres sources.

Pour pouvoir être considéré comme un collaborateur officiel ( et donc pouvoir faire des dépôts sur github) merci de demander des droits de collaborateurs via le forum: http://www.le-chat-noir-numerique.fr/forums/viewtopic.php?f=35&t=2355&sid=d5cfe8164ab179171ff3aaff34faf22f

Télécharger ici le logiciel: http://windows.github.com/

Connectez vous dans le logiciel Github avec votre identifiant et votre mot de passe.

Guide de survie pour participer sur git au développement de Whitecat

Récupération du code de Whitecat, la première fois

Lors de la première récupération des sources on va créer ce que l'on appelle un ==clone==. C'est un dossier qui va être créé sur votre disque dur avec les sources présentes sur Github. C'est dans ce dossier que git à créé que l'on va coder et faire les modifications depuis Code Blocks ou Dev-Cpp.

Pour ce, via la console il faut se positionner dans le dossier sur votre ordinateur ( commande cd ).

On va taper dans la console ==git clone== avec l'adresse du dépôt sur le serveur, ce qui permet de cloner le répertoire (dossier git) là où l'on est placé avec la commande cd.

Deux dépôts existent pour l'instant sur le git de Christoph:

Le dépôt originel des sources avec DEV-C++ et GCC 3

Le dépot des sources originelles, avec un kit de développement pour l'IDE DEV-C++ (uniquement windows). DEV C++ est un environnement de développement guère plus maintenu, et assez dépassé. La dernière version officielle (4.9.2) était pour windows XP: http://www.bloodshed.net/dev/devcpp.html et a servi à écrire et compiler schwartzpeter et whitecat. Ces sources ne fonctionnent pas avec la mise à jour d'Orwell de Dev Cpp en version 5.6: http://orwelldevcpp.blogspot.fr/

Ce dépôt doit être installé sous la racine C:/ du disque pour fonctionner et n'est pas vraiment optimisé pour git.

Si vous désirez cependant utiliser Dev Cpp 49.2: Ouvrir le git shell et taper:

cd c:/ 
git clone git@github.com:ChristophGuillermet/WHITECAT_opensource.git

Pour ceux qui connaissent pas bien la console, l'instruction “cd” permet de naviguer dans les répertoires de votre ordi et donc de se placer dans le dossier dans lequel on veut faire le clone, ici c:/

Si vous ne voulez pas écrire manuellement tout le chemin (path) d'un dossier ou d'un fichier, vous pouvez simplement faire un drag and drop du dossier vers la console, ou copier le texte d'un click droit depuis le wiki, puis le coller d'un click droit dans la console.

PS: Si vous n'utiliser pas la console windows cmd dans le gitshell, mais une commande bash sur windows, vous devrez mettre votre path entre “” pour qu'il soit reconnu.

Le nouveau dépôt pour le cross-plateformes

https://github.com/ChristophGuillermet/whitecat_crossplateform

Un nouveau dépôt est destiné au cross-plateformes ( un même projet compilable sous Linux / Windows / Mac ). Le code originel des libraires à été mise à jours et compiler pour MinGW gcc4.8.1 et l'organisation du dépôt WhiteCat_Opensource a été retouché par Anton, les sources ont été debuger et nettoyé pour pouvoir être compilé par la communauté et sous différents OS, dans un projet unique.

Il contient des projets d'IDE configurer, CodeBlocks, dev-c++, et netbeans intégrer par Ruis Serge. Les sources mises à jour avec les derniers debugs, des pas à pas et un début de commentaires des sources pour la doc doxygen.

Une doc minimal de L'API Whitecat avec Doxygen est aussi disponible dans ce dépôt, elle est encore à compléter, mais contient une brève description de chacun des fichiers de l'API. Vous trouverez aussi un tutoriel sur comment créer sa première fenêtre whitecat, dans le fichier my_window_file_sample.h de la doc.

Ce dépôt peut être installé où on veut sur l'ordi tant qu'il n'y a pas de caractère nationaux dans le path du dossier.

Pour l'utiliser et coder avec, taper dans la console git:

cd <path du dossier ou on veut installer le repertoire whitecat_crossplateform> 
git clone git@github.com:ChristophGuillermet/whitecat_crossplateform.git

Il y a ensuite deux autres dépôts qu'il faut cloner dans le répertoire whitecat_crossplateform. Vous pouvez, si vous ne voulez pas cloner l'intégralité des deux dossier, trouver sans doute des prébuilds plus légère à l'adresse http://www.le-chat-noir-numerique.fr/coding/

Le dépôt Whitecatlib contenant:

-les sources des libraires utilisées et leurs dépendances à compiler soit même, pour si vous utiliser un autre compilateur que MinGW_GCC4.8.1, et les libs déjà précompiler et linker pour minGW4.8.1. A terme sans doutes des précompilations pour d'autres plateforme.

Le dépôt whitecatbuild contenant:

- les applications whitecat compilées pour chaque plateforme suivant l'avancement du projet, les dll et les dossiers nécessaire à whitecat dans le dossier to_copy_in_the_executable_folder.

Pour lancer whitecat avec windows par exemple, il faut décompresser les zips whitecatfolders.zip et MinGW4.8.1dll.zip qu'on trouve dans le dossier to_copy_in_the_executable_folder dans le dossier white_cat_with_mingw, dans lequel se trouve Whitecat_Crossplateform.exe pour windows.

Pour cloner les deux dépôt complet, dans la console git

cd <path du dossier whitecat_crossplateform> 
git clone git@github.com:ChristophGuillermet/whitecatlib.git
git clone git@github.com:ChristophGuillermet/whitecatbuild.git

Pour les mettre à jour après.

cd <path du dossier whitecat_crossplateform/whitecatlib> 
git pull
cd <path du dossier whitecat_crossplateform/whitecatbuild> 
git pull

Un MinGW4.8.1 compresser avec toutes les librairies, à décompresser dans C:/, est aussi à l'adresse https://github.com/ChristophGuillermet/MinGW

INSTALLER L'ENVIRONNEMENT

Si vous êtes sur windows ou une autre plateforme et que vous voulez compiler les libraires, s'inspirer du pas à pas BUILD_LIBRARIES_INSTRUCTIONS_for_MinGW.txt pour installer l’environnement de développement, les librairies si besoin et les devkits et compiler une première fois les sources.

Sinon sur Windows, suivre plus simplement le pas à pas PREBUILD_INSTALL_WITH_CODEBLOCKS_AND_MINGW4.8.1.txt

Une fois ceci fait, c'est parti mon kiki !

Ça compile bien, Youpi au travail, on peut commencer à coder whitecat !

… oui, mais quand on travaille à plusieurs mains, c'est bien de voir si les autres ont progressé depuis la dernière fois.

Pour savoir où on en est « dans quel état j'erre ? »

La commande, c'est

git status

elle renvoie la liste de toutes les modifications, celles qui ne le sont pas encore uploader sur le serveur, celles qui ne sont pas encore commit, la branch sur laquelle se trouve les sources du dossier, les nouveaux fichiers ou dossier dans le dossier du dépôt mais qui ne sont pas encore synchroniser au dépot, les erreurs etc. En gros entre chaque commande git on va écrire un petit git status pour vérifier qu'il y a pas de problème, c'est préférable.

La commande

git reset --hard

Permet de mettre à jour vos donnés et le dépôt sur votre disque

Dans la console git

cd <path du dossier clone whitecat crossplateform>
git pull

Ça permet à Git de récupérer toutes les nouveautés qui sont apparues sur le dépôt central des sources de whitecat. Si une des modifications en amont est en contradiction avec une des modification suivies localement, des messages informatifs apparaissent et on dispose d'un moyen simple pour résoudre les conflits. ou alors: git pull nom_de_branch_sur_laquelle_travailler (voir chapitre branch). ex pour mettre à jour que la branch principal:

git status
git reset --hard
git pull origin master
git reset --hard

Les branch

Ne jamais travailler sur la branch master Chaque dépôt peut contenir plusieurs branch, comme les branches d'un arbre, c'est à dire des évolution séparées. Les branches peuvent évoluées un moment de manière séparer pour développer un gros changement de code et une modification plus importante qu'un simple commit, puis après se fusionner avec la branch master (la branche principal) pour prendre en compte une fois qu'un développement est terminé, les modifications et évolution des deux branches.

En gros à chaque fois que sur un dépôt ou va vouloir travailler sur un changement important de whitecat, ex: ajout de l'osc, changement de la librairie audio, test de doc avec doxygen etc.. on va créer une nouvelle branch sur laquelle on travaillera. Ainsi les test et changement provisoire de code ne polluerons pas la branch master pour les autres développeurs, et il ne se retrouverons pas tout à coup avec un code en cours de construction, mais que ne compile plus.

Pour créer une nouvelle branch dans le dépot origin (clone d'origin voir chapitre fork et remote si on utilise un autre mot clef que origin).

Exemple: on veut développer whitecat pour qu'il reconnaisse l'osc

Dans la console git, dans le dépôt taper dans l'ordre:

Pour créer une nouvelle branch, on part toujours de la branch master, osc étant le nouveaux nom de la branch.

git checkout master

Ce place sur la branch master à partir de laquelle on veut créer une nouvelle branch

git checkout -b osc

Crée la branch osc et se place dessus pour les prochains changement.

Avant chaque fois qu'on veut reprendre le code de la nouvelle fonction osc de whitecat, on va donc ouvrir et taper dans la console avant de coder et d'ouvrir son IDE:

git pull osc

pour récupérer tout les changement effectuer sur la branch osc (ou git pulléventuellement pour récuperer toutes les nouvelles branch entre temps sur le serveur, y compris les changement d'autres dev dans la branch osc)

pour se placer dans la branch osc avant travailler dessus et updater les sources qui sont dans le clone sur l'ordinateur afin qu'elle soit identique à la branch osc

git checkout osc 

Il est fortement conseiller d'ajouter

git reset --hard origin/osc 

Pour que les sources sur l'ordi soit identique à celle sur le serveur.

On va donc ensuite ouvrir l'ide, puisque le code de notre dépôt sur le disque dur sera mis à jour, coder nos petit changement à cette branch en faisant à chaque fois, après avoir un peu coder, un ou des commit que l'on va envoyer vers le serveur comme décrit précédemment.

git status

pour afficher les changements et verifier la branch sur laquelle on travail. Si des modification sont en rouge, c'est qu'il y a des fichiers qui n'ont pas été tracker par git, dans ce cas ajouter les fichiers que l'on souhaite modifier avec

git add nomdufichier.ccp

Si tout est en vert ou que les fichiers que vous vouliez modifier apparaisse en vert vous pouvez passer directement au commit.

git commit -m "description des changement"
git status 

pour vérifier que tout est bon

<code>
git push origin osc

pour envoyer nos changement vers la branch osc du serveur sur laquelle on travail

Les fusion de branch etc.. pour adapter le code finit de la fonction osc sur la branch master seront vu dans un autre tuto ou chapitre, sinon plus de doc se trouve à l'adresse http://git-scm.com/book/fr/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0%3A-les-bases

Les commit

Le principe de git est simple,pour chaque petite modification de code, ajout d'une petite fonction dans un fichier, changement des commentaire et de la doc, debug d'une fonction, etc..

on va poster un commit qui décrit la modification des sources. Ainsi dans l'historique du dépôt , un autre dev pourra aisément suivre pas à pas les modification qui ont été faites, et les lignes qui ont changer dans chaque fichiers seront visible.

Le principe est donc de poster des commit très régulièrement pendant qu'on code, à chaque fois qu'on finit un petit changement. Une seule fonction doit être contenu dans un commit pour que le changement puisse être pris en compte, un type de debug sur une fonction, ex: debug de deux ou trois lignes sur la fonction midi, ne rajouter pas en passant un autre debug sur la doc doxygen. Les commit doivent représenter toujours le changement de code le plus petit possible, mais fonctionnel (ça ne sert à rien de poster un commit sur l'ajout d'une fonction qui n'est pas encore finie d'être écrite aussi dans le fichier .h ou les fichiers qui font appel à cette fonction par ex).

On aura donc pendant qu'on code, toujours la console git ouverte avec:

 cd <path du dossier whitecat_crossplateform> pour être dans le clone du dépôt git sur lequel on code.

A partir de maintenant, nous allons considérer que la console git est toujours ouverte et que le path de la console mène vers le dossier du clone git sur lequel on travail avec la fonction cd.

De temps en temps, pour poster un commit dans le clone git sur notre ordi, rien de plus simple, on va taper dans la console:

git commit -m "description de ce que on a fait entre temps comme changement sur le code, ex debug de icat, doc doxygen" 

Puis pour poster notre commit sur le serveur central sur le site de git hub, si on est autoriser, pour qu'il soit disponible pour les autres.

git push origin nomdemabranch

La fonction “git push” permet de uploader les changement commit dans les fichier sources vers un serveur

“origine ” définit le serveur vers lequel on veut uploader, origin est un mot clef définissant l'url du serveur à partir duquel on a fait le clone qui va être utilisé pour uploader les changement, dans notre cas git@github.com:ChristophGuillermet/whitecat_crossplateform.git En général c'est toujours dans ce dépot sauf exceptions que l'on va travailler. Donc origine est le mot clef du “remote” (c'est comme ça que s'appelle) qui pointe vers l'url du serveur d'origin. Nous travaillerons presque toujours sur cette remote, mais pour plus de détails voir le chapitre plus loin “Les Fork”.

“master” définit la branch (voir le chapitre suivant) vers laquelle ont va uploader nos commit et nos changement

Si on code sans connexion internet. c'est pas grave. on va au fur et à mesure du code faire seulement des commit.

git commit -m "petit changement que je veux faire"

une fois que l'on auras une connexion internet pour mettre à jours les changements:

//pour récupérer les changement fait sur le dépôt depuis sans les merger, intégré à notre code sur l'ordi
git fetch origin nomdemabranch
git push origin nomdemabranch

Ça peut parfois merder si il y a des changements qui rentre en conflit sur le serveur avec les changement que vous avez coder depuis.

ajouter des nouveaux fichiers ou des dossier à suivre dans le dépot après les avoir créer

C'est la commande git add Pour un fichier

git add nom_de_fichier_à_suivre
// ex: git add MinGWpackageinstalled.rtf

ou pour ajouter tous les fichiers contenu dans un dossier ex: si on est dans le répertoire principal du dépot whitecat_crossplateform comme d'hab avec la commande cd et qu'on veut ajouter au suivi le dossier OSC qu'on a par ex créer dans le dossier Src pour y mettre les fichiers du code destiné à la gestion de l'osc

git add path_du_dossier_depuis_l'endroit_ou_on_se_trouve_dans_la_console/ *
git add Src/OSC/ *

Pour rescaner tout le répertoire

git add --all

Puis effectuer un commit

git commit -m "ajout du répertoire IDE/CodeBlocks au dépot"
git push origin osc
//pour uploader vers la branch osc créer précédement sur le dépot sur le serveur

Les tags

Lorsqu'un version est finie une grosse fonction marche bien etc.., Si on veut garder une sauvegarde de cette version de whitecat et pouvoir à l'avenir la télécharger même si il y a des changement commit depuis, on va la tager.

Je ( — Georges Khaznadar@free.fr 2014/01/26 18:19) me souviens que quand j'habitais en Lorraine et que je coupais mon bois de chauffage, on avait une habitude pour marquer les tas de bois : un trait de peinture (à la bombe) sur le tas qui permettait de retrouver les bûches qu'on avait placées avant telle date

tas de bois marqué

Quand on dépose un tag dans Git, c'est un peu pareil. Celui-ci permet dans le future de récupérer exactement l'état des fichiers qui existaient et qui étaient « commis » au moment de la création du tag.

Les commandes pour cela sont :

git tag

pour voir la liste des tags existants

git tag nomDunNouveauTag

pour créer un nouveau tag localement, qui marque tous les fichiers « commis ».

git push --tags

pour remonter les tags locaux vers le dépôt central. Quand le dépôt central est géré par GitHub, il crée automatiquement un lien qui permet de récupérer le projet dans une archive .zip ou .tar.gz

La gestion des tag et des release est presque plus facile je trouve depuis la page https du dépôt en cliquant sur le petit bouton releases pour afficher toute les versions déjà tagger et éventuellement en télécharger une en particulier.

Sur cette page en cliquant sur le bouton <draft a new release> on peut facilement créer un nouveau tag prenant l'état des sources à ce moment.

Les remotes (formellement interdit sur les dépôts partager, uniquement pour les administrateurs sous peine de bannissement immédiat, à n'utiliser qu'uniquement sur votre propre Fork)

Pour mettre à jour votre fork depuis le dépôt à partir duquel vous l'avez créer, vous devez créer donc une nouvelle remote pointant vers le dépôt à partir duquel vous avez forker. Ex :

git remote add depotchristoph git@github.com:ChristophGuillermet/whitecat_crossplateform.git

depotchristoph étant donc le nom de la nouvelle remote (nous avons donc origin et depotchristoph comme remote) suivit de l'url du dépôt vers lequel cette remote pointe.

L'url du dépôt peux se trouver par ex sur la page https du dépôt, sur le coté droit, en dessous par ex de ssh clone url (ou https clone url ou Subversion clone). Pour un même dépôt pourrez trouver et utiliser selon votre convenance l'url https, l'url ssh, ou l'url subvertion. J'utilise en général le ssh, moins bugger que le https en cas de coupure de liaison internet , mais c'est en fonction des préférences de chaque utilisateur.

Pour connaitre quelles sont les remote de votre dépôt git

git remote -v

Synchro entre dépot et Merge (!! à ne jamais utiliser sur les dépôts partager)

Pour synchroniser mon dépôt avec les mise à jour effectuer par ex entre temps sur le dépôt de Christoph, je vais faire dans l'ordre sur la console en étant situer dans mon clone :

git fetch  depotchristoph

pour récupérer les mise à jour sur son dépôt

git checkout -b mergesourceChristoph

Pour me placer dans mon dépôt sur une nouvelle branch mergesourceChristoph que je veux mettre à jour et sur laquelle je travaille, ou n'importe quelle autre branch en changeant seulement le nom master par le nom d'une branch de travail. Puis

git rebase depotchristoph/master

Ce qui aura pour effet de mettre à jour mon dépôt sur mon disque dur, la branch master avec la branch master du dépôt de christoph Si le résultat me plaît, je peux mettre à jour mon dépôt sur mon serveur git en tapant comme toujours

git add --all

pour que git regarde les différences dans tous les fichiers

git merge depotchristoph/master

pour fusionner et garder l'historique git du dépôt de Christoph

Vérifier que tout va bien avec un

git status

Puis

git push origin master

Pour mettre à jour SON dépôt sur le site de github.

Git avec un environnement graphique

CodeBlocks

Eclipse

recettes_pour_git.txt · Dernière modification: 2014/03/18 15:28 par anton