https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options

https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options

Utilisation classique :

g++ fichier.cpp -std=c++11 -Wall -Wextra -o fichier_executable

-o fichier_executable

-o pour output, permet de définir le fichier de sortie. Si absent, le fichier créé est nommé a.out

Détermine le langage standard:

-std=c++14

Compilation simple (sans assemblage) :

Configuration

Pour commencer, travaillant essentiellement sous GNU/Linux (Ubuntu), les fichiers doivent être codés en UTF-8. Pour définir cela dans Eclipse :

Window -> Preferences -> General -> Workspace : Text file encoding, UTF-8 et mes accents sont correctement affichés

Oui mais les mots français sont marqué mal orthographiés, oups, eclipse is not french native !-)

http://www.eclipse.org/babel/downloads.php

Une ressource précieuse:

Politique de contribution open source de l'État

miniature du schéma d'Oliver Steele

Comme beaucoup, j'ai utilisé git pendant des années sans utiliser l'index. C'est alors qu'un collègue se met à git et me parle de l'index… pas clair!

Et le hasard faisant bien les choses, arrive un cours Git avancé de Matthieu Moy, dont la page 21 reprend ce graphe très clair d'Oliver Steele dans sa page My Git Workflow:

horloge du dôme de Florence (src: https://commons.wikimedia.org/wiki/User:Watchduck)

La date est incontournable,

le sysadmin (ASR) a parfois besoin:

Et on monte encore d'un cran : git sur mon serveur local :

Actuellement, on privilégiera plutôt une implémentation de gitlab community editions (ce)

liens utiles pour cette partie :

https://www.sheevaboite.fr/articles/installer-serveur-git-auto-heberge-partie-1

http://git-scm.com/book/fr/v2/Git-sur-le-serveur-Mise-en-place-du-serveur

après avoir commencé à utiliser git sur ma machine, je souhaite maintenant déposer les sources sur un serveur de fichier pour en avoir une copie au chaud… et éventuellement partager ce projet.

sur le serveur (ubuntu, debian like)
sur le(s) client(s) (ubuntu, debian like)

Les lignes ci-dessous s'inspire largement du tutoriel sur sheevaboite.fr (cf. lien ci-dessus):

installation :

sudo apt-get install git-core

création d'un utilisateur spécifique pour l'utilisation de git :
sudo adduser --system --shell /bin/bash --group --disabled-password --home /var/git/ git

Création du répertoire pour le(s) certificat(s):

sudo mkdir /var/git/.ssh

Copie du certificat du developpeur 1 :
sudo scp developpeur1@nom_pc_client:/home/developpeur1/.ssh/id_rsa.pub /var/git/.ssh/

cd /var/git/.ssh/

Création du fichier authorized_keys avec la clé publique du 1er développeur
sudo mv id_rsa.pub authorized_keys

Création d'un dépôt :

cd ~
mkdir depot.git
cd depot.git/
git init --bare

installation

sudo apt-get install git

Génération des clés privée/publique pour l'accès au serveur

ssh-keygen -t rsa

Copie de la clé publique sur le serveur

scp .ssh/id_rsa.pub git@nom_serveur_git:/var/git/.ssh/

Extraction du dépôt vide créé sur le serveur

git clone git@nom_serveur_git:depot.git

Se placer dans le répertoire du projet

cd depot/

Création d'un fichier de code source
cat > test1.c

Ajout du fichier précédemment créé
git add test1.c

Configuration de git

git config --global prenom.nom "p.nom@serveur_email.fr"
git config nom_developpeur.email "p.nom@serveur_email.fr"

Edition du fichier de config de git pour ajout des raccourcis (cf. tout haut de cet article)

vim ~/.gitconfig

Premier commit
git ci -m "1er ci" test1.c

Synchronisation avec le serveur
git push origin master

Création d'un second fichier source
cat > test2.c

Ajout d'un second fichier

git add test2.c 
git ci -a -m "add test2"
git push origin master

Visualisation du log
git log ou git log --decorate

On se repositionne plus
cd ..

on crée un nouveau répertoire et on s'y positionne

mkdir test
cd test/

Puis on récupère à nouveau le projet pour vérifier qu'on y retrouve ce qu'on vient de créer (test1.c et test2.c)

git clone git@nom_serveur_git:depot.git
ls depot/

vous devez retrouver votre dépôt copié sur votre machine !

… à part tous les fichiers et répertoires qui se trouvent dans .gitignore.

Si vous souhaitez néanmoins que votre dépôt les inclus, il faut recourrir à git annex

… ou bien les enlever de .gitignoreet donc les ajouter… en y ajoutant au besoin des attributs de fichier binaire :

voir .gitattributes …à suivre….

Dans la pratique, on a généralement un projet existant qu'on veut déposer sur le serveur.

On commence par créer le dépôt vide sur le serveur, comme ci-dessus :

sudo mkdir depot_projet_existant.git
cd depot_projet_existant.git/
sudo git init --bare

 

 Si le projet existe bien, en revanche, il n'est pas associé à un dépôt distant. Le fichier .git/config ne doit pas

contenir de [remote "origin"].

Pour créer ce lien, on tape :

git remote add origin git@nom_serveur_git:depot_projet_existant.git

et maintenant, on peut pousser notre projet dans le dépôt vide :

git push origin master

 

Et maintenant, nous sommes deux développeurs (ou 1 avec 2 machines, ça fait presque pareil):

PC développeur 1

qui travaille sur la branche master

PC développeur 2

qui développe sur la branche future_version

Rien de bien particulier ici, ce développeur fait ces commits en local puis de temps à autre un

git push origin master

Le développeur 1 doit maintenant aussi travailler sur la future_version

git fetch origin

ce qui va récupérer sur son poste "la branche" future_version déposée par le développeur 2…

j'ai mis des guillemets autour de la branche car elle n'est pas vraimment créée,

donc pour la créer, on tape :

git co -b future_version origin/future_version

 ou si conserve le même nom de branche (comme ci-dessus), alors on peut taper à la place:

git co --track origin/future_version

C'est ce qui s'appelle une branche de suivi, et nous permet d'utiliser les commandes

git push et git pull pour se synchroniser avec la branche distante.

au début, il faut récupérer le projet :

git clone git@nom_serveur_git:depot.git

on crée la branche future_version :

git co -b future_version

on ajoute, on enlève des fichiers… bref, presque comme sur un nouveau projet, on commit, on tag…

et on "push" la branche sur le serveur (et le(s) tag(s) éventuel(s)) :

git push origin future_version

git push origin --tag

Si ce développeur doit fair une modif sur la branche master, il se repositionne sur le "tronc"

git co master

puis, pour récupérer les modif faites par le developpeur 1:

git pull origin master

et pour récupérer les tags ajoutés:

git pull origin --tag

 

 

Que ce soit pour la remontée de bugs, assurer la compatibilité entre machine ou simplement s'assurer que l'on dispose d'une version à jour, il est souvent indispensable qu'un logiciel contienne un numéro de version. Il peut-être géré de multiples façons. Si vous ne l'avez pas déja lu, je vous invite à lire l'article sur la "Gestion sémantique de version" en copie ci-dessous

Premier pas

Afin d'avoir un fichier VERSION qui contient le numéro de version du programme, j'avais créé tout d'abord un script tag.sh avec: