Up and Running with Git Transcripts
Chapter: Introducing Git
Lecture: Why use GUIs for git?
0:00 Why do we want these GUI tools for our git work? Well, the same reason that I might use a proper editor rather than no pad
0:09 or text edit to write Python code, but let's expand on that. Now. I realize you might not know anything about GIT.
0:17 So I'm gonna show you three commands real quick. Just follow along. You don't have to be able to do them or anything.
0:23 Let's imagine you've written some code. We're here in this gray box, the terminal or command prompt and I want to tell git these changes.
0:30 I just did I'm ready to commit them and then share them with my team. Why do we need GUI's? Because look,
0:36 it's so easy. You type git add . and you say cool, three files added and then you want to actually commit them.
0:44 So git commit -m, give a description like latest images from the UI Review those get checked in.
0:50 That seems to have worked and now we want to share them with our team will do a git push up. It goes everything succeeded.
0:59 See that's easy, Michael, why do I need to do this? Why? Why don't I why do I need these GUI tools? Why can't I just do this?
1:05 And to be fair, if you want to, you can. But let me show you some awesome stuff that you get by working with
1:11 the UI tools that I keep proposing are a good idea. Both for beginners and for experts. Here we are in VS code.
1:19 I've checked out the c Python source code. This is the runtime for Python from git hub. And I've opened up one of the larger,
1:27 more important files in c Python called C eval.C. There's a huge loop that rips around and basically runs every statement of Python in any
1:36 Python program And this is part of it. Now notice online 5,509 right there, there's this little odd gray text.
1:46 What is that? That doesn't look like source code. This is coming from something called git lens which is part of and be added to
1:54 visual studio code and it says right there, Guido Van Rassum made a change in source control 30 years ago. And what did he change here?
2:04 What part of? Why did he why was he in this section? We'll he said changes so that user defined classes can implement something or other.
2:13 That's the commit message from when he checked in that code 30 years ago. And just as I move through this piece of software,
2:22 visual studio code will tell me here is the last person that touched this line and why they made the changes that they did there.
2:30 You don't get that on the terminal, do you? What about the statuses of files? Well I'm here in my editor this time.
2:37 I'm in PyCharm and notice there's some colors going on. I've got an app.py and install.py and the setup.py and
2:46 they have these different colors. Those are version control or git colors.
2:50 They tell us about the status of those files with regard to our Git hub repository
2:54 That PyCharm understands app.py is blue because it was previously in the
3:00 repository but it's changed. Setup is green because it's new but added ready to be
3:06 committed and install.py is red because it's neither known by git or ready to be committed. It's basically untracked by
3:15 git you see that there, you also see it up here. So as you're writing code you're like,
3:18 oh something about app.py has changed just as you look at the project. Super cool. What about visualizing those changes?
3:27 You might wonder. Well it said that changed. How did it change? We can go to that section up there and if we
3:33 want to know the difference is what has happened. Just double click app.py and boom PyCharm busts over into this side by
3:41 side diff view And in the yellow box you can see on the left the old stuff. The right the new stuff says on line 19.
3:50 We've written two lines of code in a blank line. It says register logging, logging enabled.
3:55 Oh cool. So the change of that blue file is that we've enabled, logging all of this stuff is immediately accessible to us because of reason UI tools.
4:07 You want to understand how all these different branches fit together,
4:11 parallel feature branches and stuff. Look at all the colors in the history and the
4:15 exploration here, you can see like some webcast registration recently had stuff moved over from
4:21 the blue branch which is the master branch or main branch and it hasn't yet been
4:28 committed. Its changes but it's basically in sync with what is happening here.
4:32 I can tell you that immediately by looking at source tree and it shows me how all these branches fit together again. Not so easy on the terminal.
4:44 Finally, let's talk about merging. If you make these changes says I'm going to have to do a git pull,
4:50 get some new stuff maybe either because I worked on a branch and then another branch
4:56 I want to bring these together that sort of parallel work I'm doing or the team made some changes. I need to bring it in.
5:02 You might get this morning merge conflict better, better fix those. How do I fix them? Well, it's a little bit tricky.
5:09 You edit them, find a bunch of double arrow stuff, you might even end up in something that looks like this that is running vim for
5:16 reasons you're not totally sure about it says you encountered emerged conflict kind of leaves you
5:21 out of context, you're just supposed to write some messages about resolving it. So it's not the best experience,
5:29 you can set up some GUI merge tools and diff tools that are going to be really awesome actually, even from the command prompt or terminal,
5:35 that's part of the final chapter. The tips and tricks. Last advantage of GUI's that I want to just highlight
5:42 now. There are more but just to highlight now is viewing the changes of a file over time. So we're back in c Python, we're back in visual studio code.
5:51 And one of the things we can say is say I want to see everything that happened to this file over time and be able to coordinate.
6:01 So for example, there's two things on the right hand side here, the far right is the code that we were talking about before,
6:07 but on the left, this is what's called git blame and you can see there's an icon for the user, there's a 22 years ago or 7 years ago for
6:17 the time ago and then the message and the line it applies to. So for example, online 5322 Thomas Worters said apply sf patch,
6:26 whatever, adding import module 22 years ago. So then I can click on Thomas and see the other places in the file.
6:34 He made changes 22 years ago when he was also doing that fix and you can
6:40 just explore and quickly click around through our app through our code and see what who who has been in this file.
6:49 What changes have they been making and what change in one part is related to another
6:55 change in another part. All of these things are incredibly accessible and easy as long
7:00 as using the right tools, so that might be a little bit long winded for you. But I also wanted to highlight just some of the awesome things that we're
7:07 going to get to as we go through this course, using some of these tools.