git - pierregermain/MyTux GitHub Wiki

Git log only one 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
  1. 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
      
  2. Limit the subject line to 50 characters
    • consider 72 the hard limit
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. 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 door
    
    Refactor 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>
    
  6. Wrap the body at 72 characters. Configure Vim: :set colorcolumn=72
  7. 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

Useful Git Links


Git checkout fresh copy from master

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

Git cherry-pick aka Apply one commit from branch A to master

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

Pretty Git Log

~/.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

Anti git commit

git revert <your-sha>

Git-Flow Workflow

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Undo Delete

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!!!

Hotfix / Patching

# Create the Patch
git diff hotfix-branch dev-branch > hotfix.patch

# Apply the Patch
git apply --stat hotfix.patch
git apply hotfix.patch

Creating releases

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.

Discard unsaved changes

# 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

Only Stash unsaved changes

# 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

Recover Git Modes

git diff -p | \
grep -E '^(diff|old mode|new mode)' | \
sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' | \
git apply

Creación de Branch

git checkout master
git pull origin master
git checkout -b tu-branch

Borrado de Branch

git push origin --delete tu-branch

Squash / Borrar commits con rebase

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

Búsqueda de commits

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'

Merge

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

Merge Tools

  • Meld

Others that I did not try: Kdiff3, Atom Merge Conflicts package, Beyond Compare, Kaleidoscope

Merge conflicts

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

Go Back in History

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}

Change last commit

# 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!

Change last commit message

git commit --amend
# follow prompts to change the commit message

Undo Commit to Master and create a new branch for that

# 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 :)

Save user / password

git config credential.helper store

Parches

Aplicar

patch -p1 < fichero.patch

Prepend Issue number to commit messages

https://gist.github.com/jonnyparris/0a10cc63af281de23a4fd34116fed3e6

Undo public commit

     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 force

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.

Git push to last commit

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

Some tricks

  • Disable pager in git
 git config --global core.pager cat 

Get master into my branch

  1. Commit all your changes
  2. git fetch origin
  3. git rebase origin/master
⚠️ **GitHub.com Fallback** ⚠️