git - pierregermain/MyTux GitHub Wiki
- The seven rules of a great Git commit message
- Useful Git Links
- Git checkout fresh copy from master
- Git cherry-pick aka Apply one commit from branch A to master
- Pretty Git Log
- Anti git commit
- Git-Flow Workflow
- Undo Delete
- Hotfix / Patching
- Creating releases
- Discard unsaved changes
- Recover Git Modes
- Creación de Branch
- Borrado de Branch
- Squash / Borrar commits con rebase
- Búsqueda de commits
- Merge
- Merge Tools
- Merge conflicts
- Save user / password
- Parches
- Prepend Issue number to commit messages
- Undo public commit
- push force
- Get master into my branch
git log --graph production
The seven rules of a great Git commit message
Example:
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
- Separate subject from body with a blank line
- Sometimes a single line is fine:
git commit -m 'git message' - If you need a body configure your git client.
$ git config --global commit.template ~/.gitmessage.txt $ git commit
- Sometimes a single line is fine:
- Limit the subject line to 50 characters
- consider 72 the hard limit
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- It's like giving an order to git.
Clean your desk Take out the trash Close the doorRefactor subsystem X for readability Update getting started documentation Remove deprecated methods Release version 1.0.0- A properly formed Git commit subject line should always be able to complete the following sentence:
If applied, this commit will <your-commit-message> - Wrap the body at 72 characters. Configure Vim:
:set colorcolumn=72 - Use the body to explain what and why vs. how
- In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that’s what source comments are for).
- Just focus on making clear the reasons why you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did.
- Example
git checkout master
git reset --hard origin/master
git status
If you have untracked files to be removed use git clean: https://koukia.ca/how-to-remove-local-untracked-files-from-the-current-git-branch-571c6ce9b6b1
https://frontendlabs.io/3084--aplicar-un-commit-otra-rama-con-git-cherry-pick
git checkout A
git log --pretty=oneline # Get the hash of the commit you need
git checkout master
git cherry-pick your-hash-from-branch-a
~/.gitconfig file:
[alias]
lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all
lg = !"git lg1"
Now you can use:
git lg
git lg1
git revert <your-sha>
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
If you have deleted files but not commited them and want to recover them just do
git checkout -f
Just keep in mind that this will also delete files that have not been commited!!!
# Create the Patch
git diff hotfix-branch dev-branch > hotfix.patch
# Apply the Patch
git apply --stat hotfix.patch
git apply hotfix.patch
git tag
git tag -a v1.4 -m "my version 1.4"
git push origin v1.4
You should use releases with 3 numbers and apply them directly to master.
# Step 1 is to show what will be deleted by using the -n option:
git clean -n
# Step 2: Clean Step - beware: this will delete files:
git clean -f
# stash modified files
git stash
# stash modified and untracked files
git stash -u
# show the list of available stashes (yes, you can have multiple stashes)
git stash list
# apply a specific stash
git stash apply <stash-name>
# drop a specific stash
git stash drop <stash-name>
# apply and drop the last stash
git stash pop
# clear all stashes
git stash clear
git diff -p | \
grep -E '^(diff|old mode|new mode)' | \
sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' | \
git apply
git checkout master
git pull origin master
git checkout -b tu-branch
git push origin --delete tu-branch
Sirve para borrar commits pasados de un branch
git checkout MI-BRANCH
git rebase -i origin/master
- Va a salir un editor con todos los commits. Mira los comentarios del mismo editor que te sale (al final del mismo) para entender lo que hay que hacer.
- Básicamente lo que vas a hacer es quedarte con un "pick" y los demás ponerle un "s". Guardas el fichero.
- Te va a salir otra pantalla, borra todas esas lineas que ya no necesitas. Quedate con un mensaje para el nuevo commit.
Para proseguir con el squash por si te sales del editor, puedes usar:
git rebase --continue
git log --diff-filter=M --summary | grep cadena-a-ser-buscada
Donde --diff-filter=M puede ser:
- Added (A),
- Copied (C),
- Deleted (D),
- Modified (M),
- Renamed (R),
- have their type (i.e. regular file, symlink, submodule, …) changed (T),
- are Unmerged (U),
- are Unknown (X),
- or have had their pairing Broken (B)
$ git log --all --grep='cadena-a-ser-buscada'
Sin Rebase:
git fetch
git checkout master
git pull origin master
git checkout your-branch
git merge master
Con Rebase:
git checkout master-branch
git pull --rebase
git checkout your-branch
git merge master-branch --no-ff
o mas rápidamente usando
# asegurarse estar en tu "your-branch"
git pull origin develop --rebase
- Meld
Others that I did not try: Kdiff3, Atom Merge Conflicts package, Beyond Compare, Kaleidoscope
1. Fetching upstream
git fetch upstream
2. Go to your master. Never develop here.
git checkout master
3. Bringing your master up to speed with latest upstream master
git merge upstream/master
4. Go to the branch you are developing
git checkout my_feature_branch
5. It will not be fast forward
git merge master
6. Solve the conflicts. Get a decent 3 views visual diff editor. I like Meld
git mergetool
7. Commit all the changes. Write an intelligible commit message
git commit -m "Decent commit message"
8. This will push the branch up on your repo.
git push origin my_feature_branch
git reflog
# you will see a list of every thing you've done in git, across all branches!
# each one has an index HEAD@{index}
# find the one before you broke everything
git reset HEAD@{index}
# make your change
git add . # or add individual files
git commit --amend
# follow prompts to change or keep the commit message
# now your last commit contains that change!
git commit --amend
# follow prompts to change the commit message
# create a new branch from the current state of master
git branch some-new-branch-name
# remove the commit from the master branch
git reset HEAD~ --hard
git checkout some-new-branch-name
# your commit lives in this branch now :)
git config credential.helper store
Aplicar
patch -p1 < fichero.patch
https://gist.github.com/jonnyparris/0a10cc63af281de23a4fd34116fed3e6
git log
que nos muestra los siguientes commits
commit a49000 (commit privado)
commit 691000 (commit privado)
commit 33b000 (commit publico malo)
commit ce1000 (commit de merge bueno)
commit d33000 (commit bueno)
Hacemos un nuevo branch por si las moscas
git checkout -b failcommit
git branch
git log
Miramos los últimos commit
git show
git show HEAD~
git show HEAD~1
git show HEAD~2
git show HEAD~1
git log
Vamos reseteando lentamente
git reset --hard 691000
git log
git reset --hard 33b000
git log
git revert -m ce1000 (se hace con -m al ser un merge)
git revert HEAD~0
git log
Bajamos el commit bueno
git checkout ce1000
git branch
git checkout failcommit
git checkout master
git status
git reset --hard 33b000
git log
git revert HEAD~0
git log
git branch
git pull origin master
git push origin master
git push origin TU-RAMA --force-with-lease
hace que el commit anterior sea cambiado por el actual.
--force-with-lease is a safer alternative to the --force option in Git. It allows you to force-push your changes to a remote branch but with an additional check to prevent overwriting changes that you are not aware of.
Imagine you pushed your branch with a commit and forgot to commit something but you do not want to create a new commit: So you can do the following:
git add your-modified-file
git commit --amend --no-edit
git push origin your-branch --force-with-lease
- Disable pager in git
git config --global core.pager cat
- Commit all your changes
git fetch origingit rebase origin/master