The concern is documenting the conceptualization of git reset

1. why confusing?

  • you need to understand both the 3 main areas of git (work, index, repo) and the branching
  • 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
  • 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. run git reset
  2. that branch becomes the current commit → the branch is taken “back in time”
  3. 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
  • git reset — hard HEAD^ →going back to the commit before HEAD
  • git reset — hard HEAD~1 → equivalent to “^”
  • git reset — hard HEAD~2 →going back two commits before HEAD
  • usecase → committed in the wrong branch
  • if --mixed → this is the default option
  • just move the branch in a repo and leave index and working area untouched

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

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

4. sources

Technical Support Engineer/Technical Writer (Snowplow Analytics). with a passion for Python / writing documentation. More about me: