usecase

The concern is documenting the conceptualization of git reset

  • NOTE: POTENTIALLY DESTRUCTIVE

contents

1. why confusing ?

  1. you need to understand
    • 3 main areas of git (work, index, repo)
    • branching
  2. it has many usecases

2. what does it do ?

2.1. in general: 4 ways of moving a branch

  1. commit
  2. merge
  3. rebase
  4. pull
  • however, NONE OF THEM IS A SPECIALIZED COMMAND TO MOVE BRANCHES explicitly
  • these 4 general ways to move a branch is a side-effect of the commands aimed at something totally different

2.2. enter git reset: fifth & specialized way to move a branch

  • usually current branch
  1. pick a branch
  2. run git reset
  3. that branch becomes the current commit → the branch is taken “back in time”
  4. notice that HEAD is not moved — still pointing to the same branch. Branch is moving

2.3. confusing part and 3 types of reset: hard, mixed, soft

  • not what it does to the repo
  • what it does to the remaining 2 areas
2.3.1. git reset –hard
  • if --hard
    • copies

hard_copies_from_repo_to_both

2.3.2. git reset –mixed
  • or just git reset
  • if --mixed → this is the default option

mixed_copies_from_repo_to_index_only

example_unstaging_git_reset

2.3.3. git reset –soft
  • if --soft → do not touch neither index nor working area
    • just move the branch in repo and leave index and working area untouched

soft_does_not_change_files

3. how can you lose files ? don’t commit your changes & run git reset –hard HEAD^

  • this seems to me irrevertible (just done it by mistake and it hurts)
  1. you commit a file
  2. you change the file in the working area and do not commit it
  3. you run git reset --hard HEAD^
  4. the branch is moved to the HEAD-1, and the state of that move is copied both to the index and the working area
  5. if you made any changes to either work or index, that’s all irreversibly lost
  6. repeat after me: no commit, no restore