Transcription
Do you know that? You are in a project and you make intermediate saves, so to speak, versions, and at the end you have 15,000 versions simply in your folder and have no overview anymore. All of that belongs to the past, and has for a very long time, because for that we developers have Git, and that's why in this video we'll clarify what Git is, what GitHub is, and how they connect with each other, how you can actually simply send things remotely, meaning to the cloud, to then have access to your project everywhere and to all the versions, and that perfectly sorted. And so that it all makes sense for you, at the very end I'll also show you how to present yourself perfectly on GitHub, so definitely stay tuned. If you don't know me yet, I'm Kevin, and I work at the Developer Akademie with a strong team of mentors, working to enable people to achieve their dream of working in IT through a career change. To follow this tutorial, you'll need three more things, and we'll take a quick look at them. First, Git installed on your system. This means on git-scm.com you'll find everything you need. You go to Downloads at the bottom, and then you can download Git for your system. Furthermore, you'll also need, at least my recommendation, VS Code as an editor, so that you can do exactly the same as I do. And you can choose one here. In fact, if you need something else, just go to the download button, and then you can choose something for your operating system. And last but not least, you'll also need a GitHub account, because when we put something together with Git, code something with VS Code, we need a place where we can essentially send it to the cloud, and that would be GitHub in this moment. So, do these three things very quickly, and then we'll see each other in the next section. So, I'll give you a very small recap of Git, because Git works as follows. Imagine you have a working directory, meaning your folder where you are currently with your project, you want to test something new, and for that you create two new files. This means you can now test your new feature here without actually changing the old code. But that's nonsense, because for that we can actually just use Git. Git sets up a new folder for you, in which there are then two new fields. Namely, a file called the Staging Area. There we will essentially record everything you have changed. And when you are sure that you want to save this as a version, then we take that and put it into the Commit Folder. This means you change a file, and we move that into the Staging Area. We summarize all of that in a commit, and you can then save many of these commits for yourself, and thus of course always rummage around in your small collection of versions if you want to. We start at the beginning when there's nothing in there yet, when the whole thing still looks relatively empty, and that's exactly how it is. I don't actually have any files in my folder, but I do have a folder already opened with VS Code, and that's where we'll play around now. Please just ignore the Gitconfig-Demo here. That's only because I had everything installed already, and this way I can bypass it. This way we can actually go through it all together from scratch. I have already opened a terminal here. You can do this by going to Terminal in VS Code, then New Terminal, and then you have your terminal open. So, we start with that, or even better, I'll reveal, I'll open the folder myself. You see, there's nothing in there. That's important, because if I now type Git, you always start with Git, because you want to execute a Git command. This tells you, okay, I'm looking for Git commands, and then init. Git, to initialize your repository. That's exactly what it says here. I've started with an empty repository. And if we look at the folder again, you'll see that a small Git, or rather a .git folder, has been created there. That's your repository, everything is in there. The commits we'll make are in there. That's the staging area, and so on and so forth, to throw in a few technical terms. But everything concerning your repository can be found there. Good, then I'd say let's move on directly, and for that we'll naturally need a file. I'll just call this thing Test.txt. But it could also be an HTML, it could be a JavaScript file, it could be a Python file, it could be code, but it could also be a PDF, it could be, I don't know, your new project where you just jot things down. It could be Excel, and so on and so forth. All of that is possible, but we want to limit ourselves to programming here. That's why I have to write Hello World into this TXT, because that's just how it's done. The first thing you always do. I save it, and now we have a U here, and that means untracked. Basically, Git doesn't know about it yet. It doesn't know whether to put it into a commit, meaning a version you want to save. And accordingly, we have to tell Git about it once. And before we do that, I might even want to set up a file so that we can test one more thing, namely Test2.txt. I'll save that too. It's also untracked now. And now we have to execute Git. Add, meaning I execute it or I add it. We could directly enter one here, like test.txt as a direct link. I've added a new file, and I want to track it. That means I want to select it for a new version. If I have it here, it's also marked as edited. That's the advantage of VS Code. That's the reason why we recommend VS Code. But Test2 isn't in there yet. And that's why my advice to you, you can enter each one individually. But that's super annoying, and that's why we just do git@P, and with that you add all of them at once, because if I press Enter now, you'll see that A stands everywhere. That's how it should be. And to create a saved version of your project, you make a commit. That's exactly saving the entire change from one version in a file, so to speak, like a change sheet or something. That's a commit, and we can also name it. This means I enter M, meaning I want to add a message, and put two quotation marks, and write in there Test txts Edit, because that's what I added. You write in there in a very, very short form what you've done, so that it remains traceable in the end. You can actually also write Version 1 or Version 2 in here. That's also possible. So, that you best know what happened there. Now I press Enter, and it will go wrong. And I've left it in there on purpose, because it will go wrong for you too, so that we can solve it together, because this error is actually very, very interesting, because Git needs to know who you are, and therefore you naturally have to provide your email address and your name here, and you can do that, right? It says author identity unknown. That means Git doesn't know who you are. And we want to do that right away. The nice thing is, I could have shown you the commands, but honestly, when the error comes, it just gives you the commands completely, and that's naturally super practical. So, I'll enter an email here, and it will be my private email. So you won't see this, but that's not so bad, because an important point, and please remember this, the email you enter here must also be the email of your GitHub account, which we'll set up later, because then Git will know, and the name is irrelevant, you can enter a different one, but through the email you are identified on GitHub, so that when you see commits on GitHub that you've made, it will also say, hey, this actually belongs to this account. Otherwise, I could just put Your Name, we'll enter a name there again, Kevin Gowat. And we'll send that off, I'd say. Now we're registered, and now we'll execute this command again. That means I'll clear everything. We can now perform this whole thing again here. And now it's here. Everything is in there now. We've committed, and everything is done. Now you might think, okay, and for that I'll open the bar here again, so that you can see it a bit better. On the side here, we can actually also look at the Source Control Panel of VS Code, because we'll do the whole thing again with the Source Control Panel. That's also super practical. You can see the commit we made here, right? Test txt Edit. You can see it's there. You can also see the branch here. That's thinking a bit further ahead, but all of that is possible to see here. And you can also follow this Git add and so on visually quite well here. This means we'll add another file and change one. There's nothing in Test2.txt yet. Let's put Hello World 2 in there. Save it, and then I'd say let's add a Test3.txt. In that, let's just put nothing. We'll save that too, and then I'd say let's look at the Source Control Panel, because it's actually in here, right, that the Git Config is modified, the name has moved in there, that's why it's modified. But Test2 is modified. We've changed something in there, and that's shown to you here. That's quite good. And Test3 is untracked. It was added. So, if we now just execute git . at the bottom again, it had a bit more in it. Sorry. Git .. You can see it here. I've entered that and sent it off. Then it's actually cleared up here. And you can see it here too. It's now in the staged area, right? changes. Further down, if I were to do more. And all of that is up here. Now we have two different options. Either we'll enter this Git commit - M and so on again, or everyone here is lazy, we make it easier for ourselves, just use VS Code, because it's the same. If I now enter, for example, Test2 edited, and Test3 edit. We want to, right? That's the message we write after Git commit - M. That's exactly this message. When we commit it, it's the same as if we entered it in the console below. And now we actually have here, I hope you can see it well, let's zoom in properly. Now we have another one here. This means you see, it's the same as how it was created, only that we used the button up there once and the console once. Now you know how to just commit, how to secure your states for yourself. Now we just need to look at how to get it to GitHub. So, naturally, everything starts with GitHub when we want to post it on GitHub, and for that we want to look at this page. This is github.com itself, assuming you've created an account there. You should do that beforehand, before we look at it in detail. It's a bit like social media for developers, only that you won't find funny cat videos here or anything, unless someone puts them in a repository, because what you'll see here are changes that someone is making. Someone is now following me, and things like that. Or here on the right, what are my favorite repositories doing right now? Is there anything new? So all of that is essentially what's automatically posted here. When we want to start, we have two options. Either this green button here, which is already very call-to-action-like, or on the right, your Repositories, we go in there, and then you'll see all your created ones. And if you don't have any at the beginning, you can easily create a new one here, and that's what we'll do now. We'll create the YouTube or the YouTube Test Repo to check everything. You can enter the name there. You can even create things like that from templates. It's probably a bit overkill for now. You can add a description, it's optional. This part will also become a bit interesting. With repositories, it's usually set to public, everyone can see it, but you might want to write code that you don't want to present at the beginning, or at all, then you can set it to private. That's absolutely no problem. This way, no one can see it, but you still have it stored on GitHub. That's super practical. Otherwise, you can add the three main files here that are important for a repository. First, the Readme, which is displayed under your repository at the end and can tell a bit about your repo if you want. The Gitignore, a file that lists all the data that should not be uploaded to GitHub when you do that later. And a license, which indicates, if you have it public, whether your repo can be used or not. We'll leave all of that out for now, just so you've heard of it. And then we press Create Repository. And GitHub is very kind to us. GitHub itself actually tells you how to do it. If I want to set up a new repository on my computer, I can do that with this section, or if it already exists, with this one. You can see it quite well here. I'll zoom in a bit. Git init, does that sound familiar? Git add, and you'd have to create a Readme first. A Git commit, First Commit. All of that is interesting. We've already done that. So we can skip that. What we need to do are these three commands below. Because git remote origin. Oh, that sounds long, but it's not that bad. Git, you know, we use that to start, right? to say we want to work with Git here. Remote is the counterpart to being at work, being at home. No, Remote is essentially the path to Git, and I want to add something there, namely the origin, and then you have the URL to your Git repository. This means, from that moment on, we can, or we have the idea, of where it should be sent. And that's why we'll enter it exactly like that. So, we enter exactly that. It worked. No problem. So far, and then we'll move on to the next command. Git branch -M sets it to Main. We can skip that a bit here. Theoretically, we won't do it now. We'll execute the whole thing now, because then the next one, let's do it like this, the next one will actually make sense. The next command, namely git push -U origin Main. We can neglect this -U origin a bit for now, not because we've defined origin above. Where should it go? Which origin should I take, right? So, where does it come from, where should it go? Push. Anyone who has ever operated a door with push and pull buttons on it, when I push, I send something away from me. Where to? To the origin, meaning to GitHub, and then Main means what we defined above, the Main branch. As I said, branch might be a bit overkill at this point, but if you just copy and paste that, then my GitHub extension wants me to verify myself on GitHub. You can do that. That's one way to do it. And then I have the option to log in in an extra window. I'll do that very quickly in an extra window, without you seeing it. And then I can open it again, and then it's uploaded. That's one way to do it. I'd also like to show you a second way, in case a window comes up where you can also enter a key, for example. These keys are the PATs, and we'll look at those later. First, I naturally need to provide proof that it's working. You'll only believe me when you see it. And that's right, only believe when you see. So, I'll reload the page briefly, and there it is. It's there. You can see the Test.txt, the Test2.txt, the Test3.txt. In Test2.txt, if I click on it, it's Hello World 2, and all of that is now online. And I think that's incredibly powerful. So, basically, you've already learned everything to do version control on your PC and to then simply push it nicely to GitHub. In a brief summary, we can even go through it very quickly before we look at the PAT. So, we can also just create a new file here quickly, so that you see again that it works afterwards. Test4.txt. We'll enter that quickly. We'll go back to our Source Control Panel or enter git add git commit. But we'll do it here because it's faster. Test4 edit. I commit it. No stage changes. Ah, sorry. Of course, you have to stage it here too. You can see it here, right? We entered this Git . earlier, and VS Code warns us about that. That's very, very good. You can also just bypass Git here with this plus, right? Either we enter git, or we enter the file here with this plus. And now I can commit. And now we have the advantage, either we enter git push in the console here, or we press Sync Changes. But we'll do it with the console, because git push is all we need from that moment on to push the state we have here with all the commits, it doesn't have to be one commit, it can be 15, back to GitHub. So that you believe me too, that it's also, right, we have to check it, so that you believe me that it's like that. We currently see nothing here. Reload the page briefly, because it doesn't do that automatically. And we see the Test4.txt here. It's empty, of course, we haven't written anything in it, but it's also uploaded within seconds, and that's naturally extremely cool. So, as I said, there's also the Personal Access Token. This means that when you call up exactly this window that we had earlier, it's possible that you can also enter a token there if you can't log in directly with GitHub. So, we go to the profile, look down at Settings. You can still see it despite my picture. In Settings, go all the way down, at least for the left column, all the way down, to Developer Settings. There you'll find GitHub Apps, OAuth Apps, and Personal Access Tokens. And in these Personal Access Tokens, there are two variants. On the one hand, Token Classics. It's relatively easy, quickly created, but not quite as powerful as Fine-Grained Tokens. A Fine-Grained Token, as the name suggests, can be set up much more intensively with many more possibilities, and that's why we'll click on it and generate a new one. This Fine-Grained Token has the advantage that I can say, I want it to expire after 7 days. And why? Because, for example, I have Seven Days Vacation, meaning vacation in Italy. I know I'll have a laptop available there. It's something like that. Well. It should be able to push, pull, and so on. It should be able to work with the repos, but after 7 days, the thing should just expire, and then I can't do anything with it anymore. I can add a description. It's not that important now. I can even, and this is this fine-grained part here below Account Permissions, everything is switched off by default, but I can even say: "Hey, this token or the user of this token can change my email address, can create events, can block other users, can do anything, right? You can see here, it's very possible. Just so you've heard of it, that's why I like to use them. Or this here above, what can it change? What does it have access to? For example, All Repositories. We could hypothetically even select some here if we say, okay, it should only be parts of it. But for now, I'll go all the way fine, so that it can use every repository, upload code, change it, download it, and so on. So, I'll generate this token now, I'll generate the token, you'll see it now, I'll delete it afterwards, right? But copy this thing, because what's written up here is really the point. You see, you'll never see it again afterwards. So, save it somewhere and don't upload it anywhere. Keep it to yourself. It's like a key to your GitHub account. That's why it's so important that you make the settings for it so that no mischief can be done with it. Otherwise, just copy this thing, and then you can use it for authentication in the same way. Super practical. This way, you have a quick way if you're stuck at the point in the tutorial where you had to authenticate and select a token, then it's possible in exactly this way. So, I owe you a little bit more, why you should use GitHub. GitHub is so incredibly powerful, and we've already seen this social media aspect here, but and this is important, if I, for example, Angular, we teach that in our further education, so I always have to be up to date, and therefore I'd say I'll just enter that into the search and see the repository for it. There are two options that are super important on how to deal with such a repository. And I'm not talking about downloading the code and so on, because you're generally not allowed to do more than that, but I'm talking about these two places here. First, the Issues, translated as Problems. There you can, look, two hours ago, and there was apparently a critical bug found, a problem that was found, and we need help to solve it. You click on it, Option A, you know the solution and can provide it. Option B, you might have the same problem. A new version has come out. You wanted to use it right away, and this bug occurred. This way you can report it and actually help make this app better. How else can you help? Through Pull Requests. Pull Requests are, and you can see it here. Basically, you pull the code. You try to solve a bug yourself, comment on it, and describe it very well, and then you can offer this code. This means, I offer that you can implement this code. It will then be reviewed. So, we, or the users, or rather the owners of this repository, will look at it and say, okay, we'll take it or not. This way, you can help both through the forum by reporting bugs and providing potential hints on how to solve them. Equally, you can even add code, of course, only after review. And that's what makes GitHub so incredibly powerful, and that's this whole open-source thing. Everyone contributes a little bit. Nevertheless, it's somehow monitored, and it doesn't just happen that anyone can mess it up, but it's simply that we get the best possible code this way, and that makes us so incredibly strong in the community. So, you're totally hyped to really use Git and Git and all of that with a cool project. You can find these cool projects at the Developer Akademie. So, just check it out and schedule a free consultation, and we'll find each other and then, of course, build your cool projects together, and of course, use a lot of Gitup in the process. So, as promised, at the end I have something for you, namely how to present yourself perfectly. This means we'll go straight in and take a quick look at GitHub again. I'll be so bold. Flo, forgive me. I'll go to his account, because I know that there's not much to see here compared to mine, because this gentleman still has to set it up and watch this video. Because here we only see his favorite repositories and a bit of information here. And if we look at my account and go to the profile, we see significantly more. And what exactly is that? I can actually edit it here, but only after I've set it up, and that's by, we see it here, right? There's quite a bit of information that comes in addition, by creating a repository that has the same name as me. This means we go to Repositories, and it should be visible right at the top. It's public, of course, and in this repository we see what? Basically, just a Readme.md. The other two are just there to make this snake work. You can get this put together using various generators on the internet, but mainly the information goes through this Readme file. This means, if I adjust it once, and here's a very important note, this is a markup language, so not HTML in that sense, you can't do that much, but that little bit is enough to really spruce up your profile page. This means headings. Yes, just with two hashtags and then write a big heading, right? A table is also possible, and we can also implement some images, as long as they are in your repository, right? Here, for example, under Assets, you'll find some. You can of course feel free to look at my repository and get inspired by it, or use one of the many generators you find on the internet for it. Mainly, it's, take exactly your name. We'll go to my profile again. This doesn't mean the name, but the one below it. So, your GitHub name, use it, create a repository with the same name, and then GitHub will say: "Hey, this is special" and then put a Readme.md in there that looks the same, or whatever you want to present here at this point, and then it's definitely very, very cool. Furthermore, down here, you can even customize your pins in your repositories. With that, you can choose your repos that you like best, and that naturally makes a big impression. Of course, always maintain this information on the side, put a nice picture of yourself in there, or some cool avatar, and then you'll definitely have a much, much cooler presence on GitHub. Wow, what a journey again. I think we've learned a lot, especially how to present ourselves. Git profiles are rarely mentioned, and yet everyone looks at your Git profile, for example, recruiters. So, not only how to use it, how to fill it, but how to present yourself there. In summary, we've learned here. So, very, very cool, I'd say.