Articles avec #version control tag

Publié le 4 Mars 2015

Au niveau des modifs de l'historique je trouve que Mercurial n'est pas aussi souple que git.

Mais bon on peut quand même supprimer un commit à l'aide de l'extension mq.

Pour activer l'extension mq il faut ajouter la ligne suivante dans le fichier ~/.hgrc:

[extensions]
mq=

Ensuite on peut supprimer n'import quel commit avec la commande hg strip (l'option -r permet d'indiquer la révision - numéro de commit -  à suprimer):

hg strip -r 12345

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 4 Octobre 2013

J'aime bien utiliser git en ligne de commande mais les commandes 

git branch

pour savoir sur quelle branche on se trouve, et

git status

pour savoir s'il y a des changements à committer sont assez longues à taper à la longue justement!!

Heureusement on peut mettre en place une petite astuce pour afficher la branche courante dans le prompt de la ligne de commande.

Effectivement ça semble pas mal mais si en plus on pourrait l'afficher d'une couleur différente en fonctions de l'état du workspace (c'est à dire s'il y a des changements à committer ou non) ça me simplifierai assez la vie.

Et bien c'est possible en recopiant les lignes ci-dessous à la fin votre ~/.bashrc:

# change prompt when in a git repository
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
 c_reset=`tput sgr0`
 c_user=
 c_path=
 c_git_clean=`tput setaf 2`
 c_git_dirty=`tput setaf 1`
else
 c_reset=
 c_user=
 c_path=
 c_git_clean=
 c_git_dirty=
fi

git_prompt ()
{
 if ! git rev-parse --git-dir > /dev/null 2>&1; then
   return 0
 fi

 git_branch=$(git branch 2>/dev/null| sed -n '/^\*/s/^\* //p')

 if git diff --quiet 2>/dev/null >&2; then
   git_color="${c_git_clean}"
  else
   git_color=${c_git_dirty}
 fi

  echo " [$git_color$git_branch${c_reset}]"
}

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w [\033[00m\]${c_reset}$(git_prompt)\$ '

 

Ensuite ça donne une ligne de commande suivante:

bliz@patatos:~/git/projet [dev]$

On sur la branch 'dev' et il y a des changements non committer car 'dev' est en rouge. Dans le cas contraire il est vert

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 17 Août 2013

Selon votre IDE préféré vous avez différents fichiers qui apparaissent à la racine de votre projet:

  • .classpath et cie pour Eclipse
  • *.iml pour IntelliJ
  • ...

Sur notre poject il a été décidé de ne pas ajouter ces fichiers aux .gitignore des projets, cependant il faut quand même éviter de commiter ces fichiers (même par accident).

Et bien chaque développeur peut facilement mettre en place un .gitignore global sur ça machine.

Cela s'effectue en 2 étapes:

  1. Création du fichier .gitignore_global:

    Utiliser votre éditeur préférer pour créer un fichier ~/.gitignore_global
    Dans le fichier ajouter les fichiers à ignorer. Par exemple:

    .classpath
    .project 
     
  2. Configuration de git pour prendre en compte le .gitignore global 

    #  git config --global core.excludesfile ~/.gitignore_global

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 7 Août 2013

Sur mon project nous avons 2 branches: master et dev.

Lors d'un push de master vers origin/master on utilise la commande:

# git push orign master

similairement pour la branch dev.

Comme nous n'avons qu'en seul remote: origin et grâce à la commande

# git config --global push.default current

on peut réduite le push à la commande:

# git push

qui aura pour effet de pousser la branche courante sur le serveur: origin.

C'est pas grand chose mais ça simplifie la vie.

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 12 Juin 2013

Pour connaître toutes les branches disponibles sur un serveur git on peut utiliser la commande:

# git remote show origin
 * remote origin
 Fetch URL: http://bliz@patatos.org/scm/BLOG/blog.git
 Push  URL: http://bliz@patatos.org/scm/BLOG/blog.git
 HEAD branch: master
 Remote branches:
   dev              tracked
   master          tracked
 Local branches configured for 'git pull':
   master          merges with remote master
 Local refs configured for 'git push':
    master          pushes to master          (up to date)

On voit ici que le serveur contient 2 branches: dev et master (mais seul master est utilisée en local).

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 21 Mai 2013

Par défaut gitk n'affiche que la branche courante ce qui n'est pas très pratique pour savoir où on en est par rapport aux autres devs. 

Heureusement il est possible d'afficher simultanément toutes les branches avec l'option --all

gitk --all

affiche ainsi toutes les branches disponibles.

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 12 Mai 2013

Un repo distant sous git s'appelle un remote et la commande pour connaitre les remotes est donc simplement :

$ git remote
origin

On voit ici que ce projet a un seul repo distant (mais il pourrait y en avoir plusieurs). Ce remote est celui à partir duquel le projet a été cloné, il se nomme donc "origin" par convention.
En revanche on ne voit pas l'URL correspondant à ce repo. Pour l'afficher il faut utiliser l'option "-v" :

$ git remote -v
origin http://bliz@patatos.com/var/git/repos/mon_projet.git (fetch)
origin http://bliz@patatos.com/var/git/repos/mon_projet.git (push)

On voit ici l'URL complète. On obtient 2 lignes car ce remote peut être utilisé à la fois en lecture (fetch) et en écriture (push).

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 13 Février 2013

Pour faire un dump SVN on utilise normalement la commande :

svnadmin dump /var/svn/repos > repos.dump

Le problème est que svnadmin dump ne fonctionne qu'en local mais il existe une solution pour faire un dump à distance en utilisant:

svnrdump dump http://server/repos/projet > projet.dump

La documentation sur svnrdump se trouve dans le SVN book : http://svnbook.red-bean.com/en/1.7/svn.ref.svnrdump.html.

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 15 Janvier 2013

Voilà la situation:

J'ai un fichier archivé sous Git. Je travaille dessus et voilà je ne suis pas satisfait de mes modifs et je veux récupérer la version originale (celle avant que j'effectue mes modifs).

Et bien sous Git c'est très logique, il suffit d'extraire à nouveau le fichier depuis Git :

git checkout mon_dossier/mon_fichier

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0

Publié le 17 Décembre 2012

Oops j'ai commité alors que je n'aurai pas du! Pas de problème avec Git (tant que le commit n'est pas parti sur le remote) il suffit de faire :

git reset HEAD^

et le tour est joué. Quel commit, déjà ? :-b

Voir les commentaires

Rédigé par Bliz

Publié dans #Version control

Repost 0