distante : git push origin --delete [nom_de_la_branche]
git reset --hard past_commit
git reset current_commit
git commit
Pour enlever des fichiers d'un commit lors d'un rebase interactif : utiliser le keyword 'edit'
Ensuite git reset HEAD^ path/to/file/to/revert
Ensuite git commit --amend
Ensuite git rebase --continue
git rebase -i $(git merge-base HEAD master)
alias grbb='git rebase -i $(git merge-base HEAD master)'
Pour modifier un commit sur sa branche qui est déjà plusieurs commits derrière HEAD
1) modifier les fichiers..
2) git add les fichiers
3) git commit --fixup $hash_de_l_ancien_commit
A partir de la un nouveau commit avec le commentaire fixup! est créé
Ensuite on peut lancer le rebase interactif avec l'option autosquash qui va ordonner tout ça proprement :
git rebase -i ancien_commit --autosquash
il y a aussi l'option --squash pour git commit qui va squash dans le rebase interactif au lieu de fixup
via Martin
git tag -a 1.0.1 -m "1.0.1"
git push --tags
Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.
git merge-base branch2 branch3
050dc022f3a65bdc78d97e2b1ac9b595a924c3f2
git merge-base HEAD origin/master
Add this to your user's ~/.gitconfig under [alias] to make it globally available:
lsch = "!f() { git diff --name-status -r "HEAD~$1"; }; f"
You can invoke this to retrieve all affected files in the last 7 commits like so:
$ git lsch 7
Instead of using -f or --force developers should use
--force-with-lease
Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.
git rebase -i $parent_hash
git rm file
git commit --amend
git rebase --continue
he Base Script
This bash "one-liner" displays all blob objects in the repository, sorted from smallest to largest.
For my sample repo, it ran about 100 times faster than the other ones found here.
git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
| awk '/^blob/ {print substr($0,6)}' \
| sort --numeric-sort --key=2 \
| cut --complement --characters=13-40 \
| numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest
This will generate nice human-readable output like this:
...
0d99bb931299 530KiB path/to/some-image.jpg
2ba44098e28f 12MiB path/to/hires-image.png
bd1741ddce0d 63MiB path/to/some-video-1080p.mp4
Filtering
To achieve further filtering, insert any of the following lines before the sort line.
To exclude files that are present in HEAD, insert the following line:
| grep -vF "$(git ls-tree -r HEAD | awk '{print $3}')" \
To show only files exceeding given size (e.g. 1 MiB = 220 B), insert the following line:
| awk '$2 >= 2^20' \
Output for Computers
To generate output that's more suitable for further processing by computers, omit the last two lines of the base script. They do all the formatting. This will leave you with something like this:
...
0d99bb93129939b72069df14af0d0dbda7eb6dba 542455 path/to/some-image.jpg
2ba44098e28f8f66bac5e21210c2774085d2319b 12446815 path/to/hires-image.png
bd1741ddce0d07b72ccf69ed281e09bf8a2d0b2f 65183843 path/to/some-video-1080p.mp4
for branch in git branch -r | grep -v HEAD
;do echo -e git show --format="%ci %cr" $branch | head -n 1
\t$branch; done | sort -r
To clean old file in repo
Or "how to search text in git diff history"
git log -p -S "string"
cat prepare-commit-msg
NAME=$(git branch | grep '' | sed 's/ //'|cut -d'/' -f2|cut -d'-' -f1,2)
echo "$NAME $(cat "$1")" > "$1"
for dir in $(ls); do cp prepare-commit-msg $dir/.git/hooks/prepare-commit-msg; done
text=" [FIX] ()
🔄 [MOD] ()
✅5 [ADD] ()
🔀 [TEST] ()
[DOC] ()"
echo "$text $(cat "$1")" > "$1"
The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).
Suppose the old commit was HEAD@{5} in the ref log:
git reset --hard HEAD@{5}
What will happen if I use git pull --rebase ?
git pull --rebase is roughly equivalent to
git fetch
git rebase origin/master
i.e. your remote changes (C) will be applied before the local changes (D), resulting in the following tree
A -- B -- C -- D
What will happen if I use git pull --ff-only ?
It will fail.
git pull --ff-only corresponds to
git fetch
git merge --ff-only origin/master
--ff-only applies the remote changes only if they can be fast-forwarded. From the man:
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward
Since your local and remote branches have diverged, they cannot be resolved by a fast-forward and git pull --ff-only would fail.
I've edited my .vimrc to add fugitive plugin and commited it by using fugitive
Voir fichier à un commit :
git show HASH:path/to/file
Hash du commit initial :
git rev-list --max-parents=0 HEAD
Voir liste fichiers modifiés entre 2 commits :
git diff --name-only SHA1 SHA2
git log --name-status --oneline HEAD~6..HEAD
git log --name-status --oneline HEAD~6..HEAD |grep -vP '^\S[^\s]'|sort|uniq
Voir modif sur un fichier entre 2 commits :
git diff SHA1 SHA2 main.c
Trouver l'ancetre commun le plus vieux
git config --global alias.oldest-ancestor '!bash -c '\''diff -u <(git rev-list --first-parent "${1:-master}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne "s/^ //p" | head -1'\'' -'
git oldest-ancestor
git rebase -i [HASH parent]
man -7 gitrevisions
HEAD
HEAD~1 HEAD^ HEAD^1
HEAD~2 HEAD^2 HEAD~1^
HEAD~3
10:10 V /tmp/git_test [master L|V]
$ git lola
HEAD^ is the revision before the current
HEAD~2 is the same as HEAD^^ and the revision before HEAD^
git branch -a --sort=-committerdate
je découvre ce plugin vim qui a l'air juste magique pour interagir avec git
il faut que je me fasse au workflow "Branch updater"
The -m option specifies the parent number. This is because a merge commit has more than one parent, and Git does not know automatically which parent was the mainline, and which parent was the branch you want to un-merge.
When you view a merge commit in the output of git log, you will see its parents listed on the line that begins with Merge:
commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James ben@example.com
Date: Wed Aug 17 22:49:41 2011 +0100
Merge branch 'gh-pages'
Conflicts:
README
In this situation, git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0, and git revert -m 2 will reinstate the tree as it was in 7c6b236.
don't fucking commit useless binary files !!
.ssh/authorized_keys
environment="GIT_AUTHOR_NAME=Arnaud M",environment="GIT_AUTHOR_EMAIL=arnaud@foo.bar",environment="GIT_COMMITTER_NAME=Arnaud M",environment="GIT_COMMITTER_EMAIL=arnaud@foo.bar" ssh-rsa .....
Peut être pratique quand plusieurs personnes commit depuis le même serveur (pour avoir un historique git avec les noms..)
Un workflow git qui a le mérite d'être simple : le cactus
Ptetre qu'un jour je passerai à zsh (ohmyzsh)
En attendant je bricole
Pour cancel un commit qui n'a pas encore été push
git reset --soft HEAD^
Show what will be deleted with the -n option:
git clean -f -n
Then - beware: this will delete files - run:
git clean -f
Pratique pour cloner en http
servir betement avec apache
git config receive.denyNonFastforwards true
via alk
GUI pour le log de git
Une couche permettant de faire de la review
On peut se connecter à gitter avec IRC
Testé et approuvé
via Skunnyk
Je prends de plus en plus le réflexe de "git init" dans certains dossiers un peu chaud qui bougent beaucoup comme des dossiers de configuration..
Et là arrive le moment où je me pose la question : qu'est ce que j'ai touché depuis que j'ai fais mon git ini ? Et voilà la commande magique qui répond à ma question :
git diff --name-only SHA1 SHA2
Après si vous voulez la liste entre le premier et le dernier commit :
git diff --name-only HEAD $(git log --format=%H | tail -1)
nouvelle hierarchie de commit mise en place par symfony
conseils pour les messages de commit
Quelques commandes git expliquées visuellement et dynamiquement
Quelques trucs sympas, mais encore un peu avancés pour le moment
Tiens je ne connaissais pas du tout ce wrapper.. pratique, à tester
Before you can start working locally on a remote branch, you need to fetch it as called out in answers below.
To fetch a branch, you simply need to:
git fetch origin
This will fetch all of the remote branches for you. With the remote branches in hand, you now need to check out the branch you are interested in, giving you a local working copy:
git checkout -b test origin/test
ou : git checkout -t origin/test
Ignorer un fichier versionné :
git update-index --assume-unchanged path/to/file.txt
Des workflow git pour l'intégration continue
Workflow for continuous integration environments
Y'a rien à dire sur ce book, c'est clair, concis, bien schématisé. Je viens de me faire la partie sur les branches car je commence à en avoir besoin sur plusieurs projets comme Piclodio2
After doing a git fetch, do a git log HEAD..origin to show the log entries between your last common commit and the origin branch. To show the diffs, use either git log -p HEAD..origin to show each patch, or git diff HEAD...origin (three dots not two) to show a single diff.
Un autre site avec plein d'article sur git
Great interactive cheatsheet
Quelques solutions pour backup un repo git