You can find the lecture notes and exercises for this lecture at missing.csail.mit.edu/2020/ve... Help us caption & translate this video! amara.org/v/C1Ef9/
Definitely one of the better introductions to git that I have seen. In one and a half hour, Anish succeeds in explaining the theoretical model behind git, and then goes from basic git usage over branching and merging to using remotes. And this all in 85 minutes. Well done!👍
Those terrible video tutorial probably are made for getting ads revenue, where the presenter might not even know or good at what they want to teach, and those terrible video are probably similar because they might refer to the same material from invalid or bad source (that's why valid good sources and citations are so important).
@@LesterFD Reading the docs is no substitute for videos such as this, or other deliberately didactic material. Docs are useful for reference, but do not do a good job of explaining the bigger picture, or the right mental models to use. Learning new systems is hard, because everyone reaches this point with their own thoughts and expectations, and the docs may or may not align. (Look up the video where Linux evangelizes git to the Google crowd, I think in 2007. The introducer says "no-one understands this"). One cannot memorize the entire documentation set, make all the needed logical connections, fill out the missing details, etc. For creations like git, human instruction is a big time saver. I write my own notes as I learn, to steer my mental models in the right direction. Stackexchange has been incredibly valuable. Git has its own concept of "time", of what version control means, etc. These are explained to some degree in the documentation intros, but it can be a challenge to understand. The writer of the documentation always makes some assumptions about the audience, and cannot (or will not) explain everything to its last logical detail.
This is exactly the kind of lecture on Git that I was looking for. Too many of these "crash courses" just settle on teaching you the cmds and that's it. I think it's crucial to have an intuitive understanding of what's happening internally within git. The absolute best advice I could give someone trying to climb the otherwise steep initial learning curve, is to first fully comprehend the simple data/object model: how the repository tree is represented and versions of it are maintained; and the use of SHA-1 hashes to represent both file/object content, and most importantly how a hash (as a commit) handle uniquely defines a versioned state of the repo tree. I don't believe this point can be stressed enough: without an intuitive high-level understanding of what's going on internally, the task of learning GIT degenerates into a exercise of memorizing seemingly unrelated command invocations.
Although I would bash the git CLI api as much as the next person, I struggle to find a way to fundamentally improve it. I guess git is trying to give you really fine grained control over what happens with your repo, and it's hard to design a concise API to do that
This proves first "It's the teacher who teaches" and then "It's the student who learns ". The way the video is articulated shows how much effort the faculty has put in. Kudos to the teacher and to all the students you finally understood GIT from its core.
you probably dont give a damn but does someone know of a method to log back into an instagram account? I stupidly lost the password. I love any help you can give me!
@Gannon Graysen I really appreciate your reply. I got to the site through google and im trying it out now. Looks like it's gonna take quite some time so I will get back to you later when my account password hopefully is recovered.
It was a unique lecture, you didn't just do commands like others but you explain the data model of git and things behind it. Thank you for this really missing things.
At 13:35, it is said that the code of one branch could influence the behaviour of the code in another branch, and you wouldn't know before merging those branches. While this is very true, it is *not* necessarily a merge conflict. It could very well be fast-forwarded (ie. the 2 branches never changed the same line of code) and yet a new bug might occur. Only continuous automated tests can detect those defects, not merge conflicts.
This is the best Git Tutorial I've ever seen. And I've been using Git for more than a year with very little confidence. This gives me immense confidence in handling all the changes that my team does.
11:08 I love how the arrows point in the correct way. Too many examples make the arrows point into the direction of the future. A new snapshot is based on an older one, thus the arrow should point towards the older snapshot!
Yeah, I learned that from git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell . Some things (like git log's output) make a lot more sense when you know that each commit has pointers to its parents, but not to its children.
This is the best demonstration of git mostly people starts with commands and make some repos on github which is a very abstracted way of teaching git to anyone but in this demonstration they also explained the underlaying structure of git which makes it more intuitive to learn. I wonder why people start directly with commands. This is the perfect way to demonstrate the git to a beginner.
All i can say is wow. Wanted to skip over this as i know a little about git but the way you explained the inner workings i really don't see how i can go wrong ever. Great foundation to start with look forward to re watching and studying this video and going thru the notes. Thanks!!!
What are your favorite commands from this lecture? I found all the best stuff to be in the last 10 minutes. My favorites are: *git add -p * (interactively stage changed hunks of a file rather than the entire file) *git show * (shows commit message and changes) *git bisect* (binary search commit history to find where a bug or change happened)
This is the best video for git. Totally worth it. Whenever I have to recommend someone for git,I'll recommend this and say don't watch any video from RU-vid until you finish this one
@@ThunderAppeal I would be very interested to see how your pedigree absolves you from recognizing that even very intelligent people can take a lot from these lectures.
Here's my explanation of a hash function: You input some data and the output is a hexadecimal number. If you change the input a little bit, the output will look wildly different. You can use this to confirm you have an unchanged file from a website. If I have program P and I say the hash is X, you can download it, recreate the hash and if you *don't* get X, you'll know it's an edited file. Well known algortihms are MD5 (outdated), SHA1 (outdated, though still often used), SHA-256 (current), though there are many more algorithms. An input/output example for SHA-256 is: input: Hello World! output: 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069 input: Hello, World! output: dffd6021bb2bd5b0af676290809ec3a53191dd81c7f70a4b28688a362182986f As you can see, the hashes differ wildly, even though I only added a comma to the text!
Pretty much true but a hash function is defined as a function which take some data. Play with its bytes and returns a hash. Its not necessary to return a hexadecimal value. But a each input should have a unique and consistent hash.
@@ezio934 There are some relatively important details - The input data size to a hash function is arbitrary but the output size is a fixed number of bits. The algorithm should exhibit 1st preimage resistance (given y, it is difficult to find an x such that h(x) = y), 2nd preimage resistance (given x, it is difficult to find a second preimage x′ ≠ x such that h(x) = h(x′)) and collision resistance (it is computationally infeasible to find any two distinct inputs x, x′ that hash to the same output). Sadly SHA-1 Which is used by git does not have all these properties.
I have been studying the pro git book but has been not efficient enough in learning. Following along the basic tasks of git with this video gives me a very speedy overview of the branching and merging. Now I feel confident to get back to the pro git book and learn the details. Thanks for the tutorial, Anish!
Git has never made sense to me like it does now (despite using for several years) thanks to this video. I plan to rewatch it without coding along just to further cement all this in me. Wonderful job.
I have been "using" Git for years. Struggling would be a better term. It's so bad that I'm considering getting out of software development. Had enough. Git is making my life hell. It's a massive time waster. It is completely unintuitive.
The lecture was informative with lots of repository in depth ways to grab data efficient time saving which I really like grab a certain command and everything's there at your disposal also ,this no where near what it's capable of man god stuff
This is awesome. I've just cloned my GitHub repo of my Qt hobby project to my laptop and commited some test changes. I think using git with the command line is better than say the Qt Creator IDE integration since the former is universal. Great introduction that successfully got me started.
professional projects do not use the console, or command line. actually, in bigger projects, with pro teams, they will force you to use git tools that show you the git flow graph. only noobs work with the console. the console is great if something messes up, but otherwise you are prone to make mistakes, you do not see your whole project and team progress, where git flow issues might have happened in the mean time, and so on. so, if you can, grab sourcetree (not those awful gui tools from github), or any git tool with a graph, and learn to use it, or else your cto or tech lead will complain. git is not rocket science. also, in a real project with potentially dozens or hundreds devs, you will never be allowed to use many git features as described in this video, regardless of whether you are a junior or senior. for instance, in many projects rebase and revert are forbidden, etc.
@@misterbeach8826 Linux kernel devs are noobs because they use git console? I think it's just a matter of preference or a project mandates tools, as you said. No harm in trying it out for a hobby project though. Clicking buttons in a GUI doesn't really teach me anything about how things work.
@@godDIEmanLIVE How's pressing buttons any different though? If you press the "Pull" button, all it does is send a "git pull" command, so I don't see how one teaches you more than the other (unless you're talking about advanced stuff). There are two main differences (I can think of) between using the console or a GUI: 1. Like you've said, the console is universal. (Though you could argue that GUIs can also be universal, as long as they're 3rd party, such as Sourcetree.) 2. The console gives you more control. With a GUI you're basically stuck with whatever that GUI offers. Good ones, however, cover 95% of your needs (just throwing in some random number). Sometimes it doesn't cover a use case, and then you eventually want to use the console. The advantages of a GUI are self-explanatory ("visual"). I prefer to use a GUI (if Jetbrains IDE, the integrated one, otherwise Sourcetree). Others at my workplace mostly use the console, but they occassionally use GUI features, too (e.g. when viewing the commit history of a class or method). But yeah, I wouldn't call people who use the command line noobs. I'd argue the opposite tbh.
You should review tags, signing and audits in the basic GIT lessons. It's REALLY important for developers to understand why they need to sign their code and sign their commits, not to mention carrying a proper audit across the GIT tree. Otherwise awesome GIT lecture.
"On a higher level....nevermind, I think this is sufficient - you can ask me afterwards" - Hash Functions I relate to that so much when explaining, THAT becomes so big, really quickly
I thought that Subversion for example was all about the snapshots which is why it didn't record as much information for solving merge conflicts while Mercurial and Git don't think in terms of snapshots but changesets which works better with merging.
