Up and Running with Git Transcripts
Chapter: Introducing Git
Lecture: Why use GUIs for git?
Login or
purchase this course
to watch this video and the rest of the course contents.
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.