4 ms·

Don't forget `rebase -i`, `reflog`, and `bisect`. Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo

Don't forget `rebase -i`, `reflog`, and `bisect`. Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo and you have to do a bit of surgery to fix it. Bisect of course isn't required knowledge but by god is it one of the most useful git commands a developer could know.

csours 6y ago
Or you just do a handful of memorized commands and delete your repos when you break something and start from scratch.
0xffff2 6y ago
I think I've used `reflog` maybe... twice in a decade of daily git use. It's crazy to me that anyone would think that it's a daily use command. I don't even know what bisect is off the top of my head.
- simiones 6y ago
  Bisect is a debugging utility - it helps you do a binary search for the commit which introduced a bug by checking out code at certain commits, having you compile and run it, and tell git if the bug was there or not, and then going back or forward in history until you can identify the 1 commit that caused the bug to appear. I've never used it, but it sounds like a nice tool of last resort.
  - account42 6y ago
    > it sounds like a nice tool of last resort It is actually a great first debugging tool for regressions (unless you already have a hunch where the problem is). It's usefulness is greatly enhanced if you keep your commits small.
    - simiones 6y ago
      Usually, I prefer to investigate a bug starting from the code rather than the history, if it's possible. In my experience, most bugs have taken longer to reproduce repeatedly than to understand from code. Besides, there's no guarantee that a bisect will land at the right commit if the bug is not reliably reproducible. But I have been in situations where I had to manually bisect the code because I just couldn't understand how the code could reproduce the problem, and having git bisect would have been a significant help.
- jacoblambda 6y ago
  I don't use `reflog` often but I've found that 9/10 times you make a serious mistake in git, it ends up being the go to solution. As for `bisect`, it's magic. It is used to binary search git commits back to X point in time. You can use it to manually go through previous commands to find what code/how long ago a bug was introduced. You can also rig it up with a test command (say a unit test that you copy out of the working tree/keep in a separate worktree) and have it automatically sift through the commits and tell you the first point where it starts to fail.

csours 6y ago

Or you just do a handful of memorized commands and delete your repos when you break something and start from scratch.

0xffff2 6y ago

I think I've used `reflog` maybe... twice in a decade of daily git use. It's crazy to me that anyone would think that it's a daily use command. I don't even know what bisect is off the top of my head.

simiones 6y ago
Bisect is a debugging utility - it helps you do a binary search for the commit which introduced a bug by checking out code at certain commits, having you compile and run it, and tell git if the bug was there or not, and then going back or forward in history until you can identify the 1 commit that caused the bug to appear. I've never used it, but it sounds like a nice tool of last resort.
- account42 6y ago
  > it sounds like a nice tool of last resort It is actually a great first debugging tool for regressions (unless you already have a hunch where the problem is). It's usefulness is greatly enhanced if you keep your commits small.
  - simiones 6y ago
    Usually, I prefer to investigate a bug starting from the code rather than the history, if it's possible. In my experience, most bugs have taken longer to reproduce repeatedly than to understand from code. Besides, there's no guarantee that a bisect will land at the right commit if the bug is not reliably reproducible. But I have been in situations where I had to manually bisect the code because I just couldn't understand how the code could reproduce the problem, and having git bisect would have been a significant help.
jacoblambda 6y ago
I don't use `reflog` often but I've found that 9/10 times you make a serious mistake in git, it ends up being the go to solution. As for `bisect`, it's magic. It is used to binary search git commits back to X point in time. You can use it to manually go through previous commands to find what code/how long ago a bug was introduced. You can also rig it up with a test command (say a unit test that you copy out of the working tree/keep in a separate worktree) and have it automatically sift through the commits and tell you the first point where it starts to fail.