Git Internals - Rewriting History and Overcoming Gitsasters - Part 1

Understanding the concepts of git can help us in many cases. Sometimes, it can help us when things go wrong - for example when we did something we did not want to do, and we would like to go back in time. We will call these cases - `gitsasters`, that is, disasters when working with git.

This video, as well as the next one, will provide you with some superpowers. After these two videos, you will feel confident when things go wrong in git. When someone commits to the wrong branch, they will call you, and you will be able to help out. When a team member loses important changes they have made, you will be the person to consult with.

In these two videos we will deepen our understanding of git while acquiring new tools, especially for rewriting history. We will also apply these tools to real-life scenarios.

======================

📕 My book "Gitting Things Done" is officially out!

Or read it for free at:

=====
Feel free to leave comments on the videos, Like on Facebook, or follow on Twitter :)

======================
Support this channel:
My mission is to create free, accessible, visual and practical tutorials. If you would like to support me on this, you can buy me a coffee :)

Thank you!!
======================

======================
How do I make videos?

I often get questions about the tools I use to create Videos - so here they are :)

(When available, I may use affiliate links and may earn a commission, with NO additional cost to you)

======================

Video created by Omer Rosenbaum. All rights reserved.

[ArduinoRR]

Fantastic videos! Putting the command line side-by-side with the graphical model is just what I needed. A lot of tutorials I've seen neglect the fact that seeing two levels of abstraction side-by-side is a huge boost to comprehension.

[shadabsearching]

Now, I can say I can confidently mange git history and really resolve commit related problems in git. Thanks for the gold mine🥇

[anastasiosarvanitis]

The best git tutorial out there! Thank you so much!!

[tylergoffinet]

Love the side by side with whiteboard and cli. Really well thought out animations and slow explanations. The magic is dissolving! Can’t wait to see how rebasing and other “complex” concepts come into play.

[NirArad]

Excellent videos, thank you!
I want to point out that at 19:20 in the video, a 'git reset --soft' would have worked just as well.

[subba]

Very well Explained with Pictures.. Can not wait for Part-2

[christianhoney]

Awesome series man. Recommending it to all my developer colleagues. Go get a nice coffee!

[stayfoolish]

Bro your GIT series and this one too is just great. Keep up this good work man!

[tanchienhao]

Please keep these tutorials going!! Totally awesome resource

[highspparow]

Well Explained, can't wait for the next part !!!

[alfonsnylen]

When will you get back to networking? Those videos were super-helpful!

[jorgecalle]

Thanks for creating these videos! I'm looking forward to the next one :)

[Arunnn]

With reset soft, your changes (2.txt) should be in staging. With mixed, your changes (2.txt) should not be in staging but remain in your working tree. With hard, your changes (2.txt) should not exist at all in staging or the working tree.

To undo your previous commit so you can change the commit or message, use 'soft' so that you keep your files and keep them in staging. You could also use 'mixed', but then you have to re-add the files to staging.

[talyawertenteil]

Hi! Great video!
In your demonstration of resetting the main (minute 20) you used reset hard.
Can you please explain why?
I thought you would use reset soft since you still wanted the file to exist in the index for branch "features_branch" to point to it.

[yusun]

Great video as always. First, it will be great if you can cover reflog later in the series, and use reset to get back to a previous state. Perhaps explain a little bit like how to reset a rebase. Secondly, you can think about doing a "tutorial" type of video, where you propose the current and desired state, then provide your solution. That would be a very good exercise to practice the Git skills.

Just to comment a bit here, so you defined a working tree as any directory that has a git repo in it, then you create a directory using git init and you call it my_repo. Would it maybe be better to call it working_tree?

[moloko]

I didn't get it. Why are the files that just have been commited are still in the staging area after the commit? The staging area should be clear / empty after the commit. Am I right? 🤔

[allsunday]

Great stuff! Any idea when is part 2 coming out?