On code on code, on commit, et bientôt on va merger sa branche sur master.

Oui mais en faite, un des commits est vraiment enorme et pourrait etre splitté avant le merge final.

J’utilise ce mode genial git rebase -i

D’autre facons son possible.

Ce qu’il faut :

  • Ne pas avoir déjà pushé ou
  • Ne pas être sur master

Au début

Je suis sur la branche fake-branch, en retard ou pas par rapport à master je lance le rebase :

git rebase -i master

# et sous mon éditeur préféré apparait

pick e21512bd881e9eb183eafc81738e0e817ddcaa52 first commit
pick dbd709da1e78fcd4c3a700583c6fed514bb55011 second commit
pick 8e7a606fd6797f8a52e83a08378e70d0eb26a151 very big big commit
pick 3fd93497ec8741d960b69e2d651e31339f5517ab last commit before merge

il faut modifier ‘VERY BIG BIG COMMIT’ ce qui donne

pick e21512bd881e9eb183eafc81738e0e817ddcaa52 first commit
pick dbd709da1e78fcd4c3a700583c6fed514bb55011 second commit
e 8e7a606fd6797f8a52e83a08378e70d0eb26a151 very big big commit
pick 3fd93497ec8741d960b69e2d651e31339f5517ab last commit before merge
# :wq

on quitte le rebase, il passe first et second en haut de master

puis on arrive ici

Stopped at 8e7a606... VERY BIG BIG COMMIT
You can amend the commit now, with

        git commit --amend

        Once you are satisfied with your changes, run

        git rebase --continue

Le commit à déjà été appliqué, on est juste apres, pour preuve :

git --oneline -1
ff85617 VERY BIG BIG COMMIT

donc il faut reprendre et splitter

Reprendre le precedent commit :

cette command supprime le dernier commit et remet toutes les modifs dans “Changes to be committed:”

git reset --soft HEAD~1

maintenant, supposons qu’on avait commité les fichier a.txt et b.txt mais que chaque fichier suffit par commit :

on enleve b.txt

git reset HEAD b.txt
git commit -m "file a remove empty char"

git add b
git commit -m "file b.txt remove compute length"

là notre commit ‘VERY BIG BIG COMMIT’ n’existe plus, il a été remplacé par “file a …” et “file b.txt…” .

On peut reprendre le rebase toujours en cours :

git rebase --continue

git log --oneline
dd9198a Last commit before merge
86253b0 file b.txt remove compute length
f4bc3e5 file a remove empty char
22fc7b8 second commit
e8c71d9 first commit

notre branche est nickel, on merge

git checkout master
git merge --no-ff -
git push
  • --no-ff “no fast forward” donc meme si je suis en haut de master et donc qu’un merge est inutile je le garde quand meme, comme ca dans mon historique je vois clairement ma branche. Pratique pour revert

  • - (le tiret à la fin du git merge) Vous connaissez cd - ‘retourne au dossier precedant’ maintenant vous connaissez git checkout -

Salut, vous venez de récupérer un backup qui n’a pas géré les droits.

Résultat vous vous retrouvé avec des permissions bizarre, et pire, la coloration de ls sous zsh est horrible ?! Voici la solution :

(Je pars d’une config basic qui ne propose aucun fichier de type “execution”)

Restaurer les fichiers :

find . -type f -exec chmod 644 {} +

Restaurer les dossiers :

find . -type d -exec chmod 755 {} +

Supprimer ces .DS_Store chiant

alias rmDS='find . -name ".DS_Store" -depth -exec rm {} \;'

2014-11-15 18:25

Pour commencer, un classique, des infos qu’on retrouve dès les premières recherche sur stack overflow à propos de git.

Pas de mis en page, juste un post pour retrouver facilement mes trucs et astuce git.

Tout d’abord mes alias, quand on tape ces commandes 100 fois par jours, les alias c’est le bien

Config

$ cat ~/.gitconfig

[alias]
  st = status
  br = branch
  co = checkout
  cm = commit -m
  ca = commit --amend

  di = diff
  dic = diff --cached
  diw = diff --color-words
  diwc = diff --cached --color-words

  l = log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)<%an>%Creset' --abbrev-commit --date=iso
  ll = log -5 --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)<%an>%Creset' --abbrev-commit
  lll = log -10 --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%ci) %C(bold blue)<%an>%Creset' --abbrev-commit
  l2 = log --graph --decorate --pretty=oneline --abbrev-commit --all
  l3 = log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"

  wc = whatchanged -p

  # you can do this if you didn't push. commit is lost but all the changes return to "stagged for commit"
  undo-commit = reset --soft HEAD^

Tips

Si vous êtes sous mac, et nul avec vimdiff, je vous conseil cette commande :

$ git difftool -t opendiff -y

Pour chaque fichier différent, il va ouvrir l’excellent “FileMerge”.

Tag

$ git tag -a v1.3.4 -m "add debug"

Récupérer un ancien fichier

$ git checkout 12fdfd234654fd file/to/restore

Diff apres un git pull

Vous venez de faire git pull et vous avez supprimé le commit..commit ? pas de panique :

$ git diff master@{1} master
$ git diff --stat master@{1} master

Le stash

Perso, j’essaie de ne jamais dépasser 3 stash dans ma liste et jamais rien d’important.

Pour sauvegarder le travail en cours sans commit

$ git stash

Pour sauvegarder le travail en cours sans commit et avec un message

$ git stash save "mon message"

Lister les stash

$ git stash list
> stash@{0}: WIP on master: e71813e..."

Appliquer le dernier stash, attention cela le supprime de la liste

$ git stash pop

Appliquer un stash spécifique. Le stash restera dans la liste.

$ git stash apply stash@{0}

Supprimer un stash spécifique

$ git stash drop stash@{1}

Récupérer les branch

Si pour X raison vous etes désynchro d’un repo (disons upstream) et que lorsque vous tapez git branch -r il n’y a pas tout, faite :

git fetch upstream
//Pour tous :
git fetch --all

Cherry pick

Cherry pick permet de prendre un seule commit pour le ramener sur la branche en cours :

$ git log feature
> 23dc12f - Merge remote-tracking branch 'upstream/feature/my-selection'
> 9b8d100 - When user add boat to favorites, use javascript to reload part
> dbf9526 - Change assets to display well jquery ui calendar on production

$ git checkout master
$ git cherry-pick 9b8d100
// le commit 9b8d100 se trouve maintenant sur master :)

Meilleur utilisation de git :

Pour faire une sorte de code review avant le commit.

git add -p