Prendre des commits d'une autre branche
git cherry-pick <commit>
git diff <file-name> # Check the diff in a file git diff --cached # Check the diff when staging
Changer l'URL d'une branche remote
git remote -v # Check the URL of the remote git remote set-url origin <new-url> # Change the URL git remote -v # Check the new URL
git remote -v # List the remote branches git branch -v # List the local branches git branch -u origin/dev dev # "Connect" the remote and local dev branches git push origin --delete <branch_name> # Delete a remote branch git branch -d <branch_name> # Delete a local branches
Delete stale remote branches
git branch -a # to check all the branches git remote prune origin
git tag vX.Y git push origin vX.Y git tag -a "<tag_name>" -m "my message" # Make an annotated tag with a message
e.g. git tag -a v1.4 -m "my version 1.4"
Delete a Tag
git tag -d vX.Y # Delete locally git push --delete origin vX.Y # Delete on remote
Ziper le code
git init # on the root of the project folder git add . # note: android studio already created .gitignore git commit -m 'ready to zip sources' git archive HEAD --format=zip > /tmp/archive.zip
Revenir au dernier commit, supprimer les modifications
git reset --hard HEAD
Effacer le dernier commit mais sans supprimer le code
git reset --soft HEAD~1
Changer le message du dernier commit
git commit --amend
Supprimer une branch
git branch -d <branchName>
git push origin --delete <branchName>
Don't forget to do a git fetch --all --prune on other machines after deleting the remote branch on the server. ||| After deleting the local branch with git branch -d and deleting the remote branch with git push origin --delete other machines may still have "obsolete tracking branches" (to see them do git branch -a). To get rid of these do git fetch --all --prune
Gary's deluxe merge
Il y a 2 branches, la test a des commits d'avances sur la master mais celle-ci a eu des commits par d'autres dev.
git checkout master git pull --rebase git checkout test git rebase -i master
git mergetool git rebase --continue
Une fois terminé:
git checkout master git merge test git push origin master
Scala repository hygiene manifesto
As git history is forever, we take great pride in the quality of the commits we merge into the repository. The title of your commit will be read hundreds (of thousands? :-)) of times, so it pays off to spend just a little bit more time to polish it, making it descriptive and concise. Please take a minute to read the advice most projects agree on, and stick to 72 or fewer characters for the first line, wrapping subsequent ones at 80 (at most).
When not sure how to formulate your commit message, imagine you're writing a bullet item for the next release notes, or describing what the commit does to the code base (use active verbs in the present tense). When your commit title is featured in the next release notes, it will be read by a lot of curious Scala users, looking for the latest improvements. Satisfy their thirst for information with as few words as possible! Also, a commit should convey clearly to your (future) fellow contributors what it does to the code base.
Writing the commit message is a great sanity check that the commit is of the right size. If it does too many things, the description will be unwieldy and tedious to write. Chop it up (git add -u --patch and git rebase are your friends) and simplify!
To pinpoint bugs, we often use git bisect, which is only effective when we can count on each commit building (and passing the test suite). Thus, the CI bot enforces this. Please rebase your development history into a sensible list of self-contained commits that tell the story of your bug fix or improvement. Carve them up so that the riskier bits can be reverted independently. Keep changes focussed by splitting out cleanups from refactorings from actual changes to the logic.
This facilitates reviewing: a commit that reformats code can be judged quickly not to affect anything, so we can focus on the meat of the PR. It also helps when merging between long-running branches, reducing conflicts (or providing at least a limited scope for each one).
Please do not @-mention anyone in the commit message -- that's what the PR description and comments are for. Every time a commit is shuffled through github (in a merge in some fork, say), every @-mention results in an email to that person (the core team treats them as personal email, straight to their inbox, so please don't flood us :-)).