 Hello, everyone. Welcome to today's Bite Size Talk. If anyone is interested to ever give a Bite Size Talk, please contact me on Slack. We are always happy for new speakers. And of today's topic, we're looking at using CLI Client for GitHub and VS Code when working with Git, with Phil. Thank you very much, everybody. And thanks for your intro, Fran. Yeah, please do jump in if you have any ideas for NF Core Talks or if you would like to talk about a pipeline you're working on or just anything you're interested in really, please do give us a shout on the NF Core Slack. We've got the Bite Size Channel. We're always looking for people to new speakers and new topics. And even just ideas for topics is great to have. We kind of keep a big list of things and we try and rotate through them, and we've got a bit low on ideas because we've had lately, which is why you've got me talking to you today with another kind of slightly last minute topic. But it's a bit of fun. And this is one that has been bouncing around for a little while. The topic today is using Git and GitHub and different ways of kind of interacting with that and managing your workflow. It's a topic I've been quietly ignoring for as long as I possibly could because I think it's a bit of a pandora's box. The way that you interact with Git and the way that you have these workflows is a very personal thing. Everyone tends to have their own preferred way of doing things, their own setup. It depends on what your preferences are, whether you like graphical tools or command line tools. It depends on how long you've been using these tools, how familiar you are with them. It depends what order you learn things in and what tools are available when. So this is by no means an authoritative guide whatsoever. I don't expect anyone else to end up with the same workflow as me, but it's just to give you a taste of some of the different tools which are available. Talk through a little bit of when you might find them useful and why. And yeah, maybe we can have a lively discussion at the end where you guys sort of chime in and say, there's a much better way to do that. Don't ever do it that way because that's terrible. Hopefully we might even have another talk or two queued up after this where people go into other workflows and maybe talk about other ways to do things. I know that Edmund had some fancy ideas with tools I'm not familiar with. Okay, sorry, I'm rambling. Let's get on with it. So this is basically not really any slides for this talk. It's just me freestyling it. So we'll crack on and I'm going to start off by, okay, there's like two slides. I dug out these old slides from a talk in 2010 and in person hackathon just to do a quick, quick, quick recap of what is Git and what does the terminology mean. Just for any of you who are watching, you might be kind of fairly new to this. So Git is a source version control software or source code software version handling user whatever set of words in different order. Basically when you're writing code, you can keep control of the history of the files of a code. You're working and you can collaborate with others using this tool. So with Git, you have a repository which is your project and then you have all the code within it and each time you do some work, you kind of hit a checkpoint and you make a commit which is like a bundle of work. You keep working and you make another commit and another commit and each of those commits is like a point in time and a history. With Git, you can also branch at any point where you kind of go off and work on two different things side by side and you can also then merge those branches back in together. And so this is typically used if you're multiple people working on one repository or if you're working on different features in parallel and it's basically always good practice to work on a branch so that you don't end up kind of, especially if you're waiting for other people to review a certain bit of code or something, you can work on things asynchronously. Repositories can also be forked which basically means you make a copy of a repository from one account to another on GitHub, for example. So here I've made a fork of an NF call repository to my own personal account and that duplicates everything but it also GitHub knows that my fork came from that one and when I'm using Git, the Git client can interact with the different remote repositories which were sat on GitHub rather than on my computer. So I can then do development on my own fork and a bit like working on a different branch, I can then make a pull request to merge those changes back into the original repository which I came from which is usually called the upstream repository. Okay. That was Git. Quickest intro you've ever seen. Hopefully basically everyone that's watching is fairly familiar with Git already. So to do today's talk I thought I would just basically do some work with you guys just live do it. I'm going to start off using VS Code and then afterwards I'm going to introduce you to the GitHub command line interface with the CLI tool and touch on a couple of different ways that I personally use it. All of the stuff with VS Code there's this documentation page which I found so I'm just going to pop the link into the Bite Size channel in Slack because it talks in more detail about the stuff I'm going to talk about now and how to use Git within VS Code because there's a lot of stuff you can do. So if in doubt go and check that out and don't listen to me. But the first thing I'm going to do is I found this Bite Size talk from a couple of weeks ago where Chris gave a really nice talk about using custom scripts in NextPlay and I noticed that Phan does an amazing job of Bite Size maintenance but she hasn't yet added the YouTube URL to the web page. So I found something to do. The video is on YouTube but it's not linked into that page. So nice simple thing for us to do. You can just jump in and add this URL. So I'm going to copy that YouTube URL and then on the NFCore website you can always just scroll down to the bottom to find the URL of the source file which the web page is generated from or you can click the edit button. I'm going to click the edit button. This takes us to github.com and I'm now looking at the markdown file here. I could actually just edit this directly in GitHub but that's not very much fun. So I'm going to do this first bit using Gitpod which I previously, we've got a couple of talks about using Gitpod and it's actually the main reason that I started using VS Code to manage Git rather than the command line because when you're running in a Gitpod environment you're kind of in VS Code by default basically and everything is there for you. So I've just spun up a new environment. I'm not familiar with Gitpod. It's basically running on Gitpod servers now and I'm in VS Code and it's just putting on a code for me here. So it was markdown, events, 2023, or 2022 sorry and what was the file called Bitesize Custom Scripts. There we go and you can see up here I think the other ones will have YouTube embed. So that's the change I'm going to make, embed and just paste the YouTube URL. Maybe it should be the proper one. That's not a short one. Okay, that's my change. It's pretty simple. What next? So I actually have a terminal down here but I'm going to ignore that for now. So at the moment I'm working on just the main master branch of the repository. I've been working on this project here when I launched Gitpod. I could equally be running on a local clone of a repository but I've cloned manually. But anyway, I'm on the master branch. In fact, you can see it down here in Gitpod in VS Code. So the main thing I'm going to be using here is this but on the left-hand side of VS Code called source control. If I click on here, this is where I sort of manage all the changes I'm doing and interact with Git. And this is the same if you're working locally or Gitpod, forget about the Gitpod thing for now. So the first thing I want to do is I want to make this on a feature branch. Like I said, I don't want to do it directly on master. And so I'm going to, you can either click this. You can see it came up with this option there, create new branch and you can also do it through this drop-down menu. So branch and I'm going to do create branch. I'm going to do bright size, add U2. Okay. Now you can see that has changed down here now and now I'm running it on a different branch, which is just local. Now when you're using Git, you have different kind of phases of using files. And the first thing is when you've made a change to a file, it's called like understaged. And I need to first stage that file so it's ready to be committed and when I do the commit. So you can see down here, it says there's some changes here but nothing is actually staged for a commit yet. So first things first, I can double click on this and it shows loads up a diff, a diff viewer so I can see what's changed in that file, which is really, really nice to be able to just quickly double check what's changed and make sure that it looks as I expect. So that looks good. And then I'm going to hit this plus button. It says stage changes. And it pops from changed up to stage changes. You can imagine I could have lots and lots of files here under change and then I just stage the ones I want to. And I can understand it again and I have a feeling you can either be sort of clever about staging parts of a file and stuff within VS code if you want to. So I'm going to stage that. And then I'm going to type up here a commit message. Added huge tube. I'll look to bite size. And then I hit commit. Great. That has now done git add to add the files and it's done git commit to make a commit but it's still on the local copy of the repository, which I have on git pod. GitHub doesn't yet know about it. So the next thing to do is I'm going to click publish branch, which is going to push this new branch I created back to GitHub. There we go. That's gone. And it's even come up with a little thing saying, do I want to create a pull request? First, I'm just going to show you on the NFCore repository here. Look, it's seen I've created a new branch here. So that's correctly gone to GitHub. I was too slow. I could have clicked to create. Right. That's the end of the git source control part of VS code. The source control bit is pretty blunt. It works with basically any, like Git lab or Bitbucket or anything. It does not specific to GitHub. The next part then is specific to just a github within VS code. And that comes down to this next one here. Now I can't actually remember if this is a plugin for VS code or if it just comes with a vanilla install because it's basically always been there since I first started using VS code. So I'm not sure. I have a feeling it's part of the vanilla VS code. I'm going to click GitHub and it gives me a whole bunch of stuff to hit to here. I can navigate the pull requests for this repository and the issues and look at all of these as if I was kind of browsing the website itself. I think. I don't do this very often. You can kind of tell. And so, okay, I can open up like description as if I was browsing GitHub without going off to the website. But right now what I want to do is I want to create a new pull request and I'm going to do that by clicking up here. I could, of course, do all this through a GitHub web interface, which is personally what I actually usually do. So I usually go in and hit compare and pull request and do it through GitHub. But this is about VS code. So I'm going to do it in VS code. Right. The interface looks pretty similar to the web. I'm saying, where's it coming from? It's coming from this repository from this branch. I just created and I want it to go into the master branch. I'm going to add a title for the pull request and the description. And you can see, excuse me, again, we've got the changes down here and I can double click and look at those changes and again, see the diff. Right. That is done. What do I do now? I've forgotten. Where's the button create? I'm blind. You can see I could create it as a draft if I want to. But I'm just going to hit create and off it goes. And it's created a progress. It's now opened up progress also within VS code. And you can say it's like a similar thing where I can leave comments and assign reviewers and everything. And of course, it looks just like the native GitHub interface here. That's it. Without leaving VS code, I've just made changes up here. I added them and source control made a new branch committed them, pushed that branch. And then the GitHub interface I then created a new pull request. And it's ready for someone else to review and merge. Pretty cool. OK. You can also then see that I can do reviewing of other people's progress. And that's going to be what I come on to next. It's what a big part of being part of a community is about not just doing your own work and pushing it to other people, but also looking at other people's code, reviewing it and merging it in. And so you can see within the GitHub tab here again, I can also see all these pull requests and kind of look through them. And it's the same as looking at the list within GitHub. But it will say you have some different views such as waiting for my review and assigned to me and stuff. So I can also look at fans pull request here. See the changes that she made. And see whether I agree with her pull request and stuff. Right. What was I going to do with this next? I think this might be where... Yeah. OK. I was going to update this to the local branch. So one more thing about this on VS Code before I go on, which is within VS Code, you also have a terminal browser, terminal, new terminal. So if you want to, you can still do stuff that you might be more used to in the terminal down here within VS Code. So which is good if you're limited to using VS Code on GitHub or whatever. So I can still do get the status and get the checkout master because you can see I'm still on this feature branch down here. What's the... So you have both of those options when you're working within VS Code. Yeah. So next thing I'm going to start talking. I'm going to... As far as I'm going to go with VS Code, you can do lots more stuff in VS Code. There's also a lot of really cool plugins, which I'm not really going to talk about. One of the ones which is very commonly used is called Git Lens, which is really powerful. And it's... You can just do like absolutely tons of stuff with it. It has lots of cool analysis. One of the things I quite like is if you have it installed, it says on Gitpod. Hang on. I open up VS Code for... This is my local VS Code now running a local repository. If I look at a file and if I hover over a line long enough, Git Lens should... It's not going to do it. Okay. And maybe I've disabled it or something. I think I have a feeling I might have disabled it the other day, but it will show up a history of that line of code, which is pretty cool. Something else I can do. Sorry. I keep thinking of things as I go along. These buttons up here, these will actually walk you through the history of a file as well. So I can click that button. That's why it's because there's no history. Okay. I'm not quite sure what's going on in this live demo, but it's clearly not working. But usually if you click these buttons, you can walk through the history of that file through the different commits and see what changes each time, which is pretty cool. Yeah. I don't quite know what I've done to Git Lens, but it's really unhappy. Apologies. Right. Next up, GitHub command line. I'm a bit of a command line junkie. So I quite like this. And this has been a real game changer for me, this command line tool. Typically when you're working with Git on the command line, you'll be used to doing things like, just going to switch to my fork here. So you can do, you'll be used to doing things like Git clone. Okay. So clone repository. You'll do Git clone, blah, blah, blah. And do you do get out, get commits and all these commands with Git. That's not what I'm talking about. The Git command line is obviously central to working on the command line. This is the GitHub command line, which is GH. And this is specifically for interacting with GitHub. So first thing is that differentiation. You can just do brew install if you want to Mac, but it's pretty easy installation. And by do GH minus minus help, it tells you about how to use it. I think one of the first things you have to do is you have to do GH off, which just opens up a window to log in to GitHub. Once you have the GitHub command line installed, you can do some stuff really, really nicely. One of my favorite things is you can clone repositories using the GH command instead of a Git. And it's basically just as Git clone, but it's a little bit more clever. And it's especially useful when you're working on a fork. So this is my personal fork of the, the NF core website here. If I'm in a blank directory here, if I do copy that command I just pasted, it's going to clone that repo for me. It's actually the same as if I did Git clone. So I should use a smaller repository. There we go. And if I go into that directory, it looks exactly the same as if I didn't get clone. But one of the clever things it's done is it has already set up two remotes for me. So it knows about my, my forks origin remote, which is what Git would have done if I just cloned it normally. But it's also, because it was a GitHub client, knows that I forked this from the main NF core repository. So it's already created a separate remote called upstream, which is just really helpful because it's just one viewer step and it's just there and it's just easier. So that's one of the simplest things you can do with GitHub. What else can you do? You can basically do everything you would do on the web through a command line with the, with the GitHub command line. So you can do GitHub repo and it knows, I mean, the current directory is in a cloned GitHub repository. So it knows which repository I'm talking about. And I can do GH repo view. It says ask me which does that want says which one's there. And now I'm looking at the review for this. That's cool. I can do minus, minus web. And it basically always just opens a tab in your browser. This is really quick way to get there from a command line. Now, one of the most powerful things you can do with the GitHub command line is work with pull requests. So I'm finally after lots of waffling, going to get on to reviewing a poor request by Fran here. Now I've looked at her poor request. She's done some, added some nice stuff. It's a nice transcript for another bite size talk. She's added in the URL for YouTube nicely. This all basically looks great. Good to go. However, one thing I've noticed is, this poor request has got out of date with the main branch. Other things have been merged in and her brunch is now sort of behind the head. It's probably fine to merge as it is, but let's just update it quickly. So what I'm going to do is I'm going to get used GH and I can do GH PR list. If I wanted to. Oh, GH PR list. And I can see all the poor requests listed. So if I wasn't sure about the name, I could do it through a command line. And I can also do GH PR view. The number of fans, poor request and it shows me this on the kind line as well. So a bit like the S code, you can do all the web stuff that you're maybe used to doing through GitHub.com and the terminal if you want to do on the terminal. The one I'm going to use is I'm going to do GH PR checkout. And the name of this poor request. Now what this does is it takes fans code and it checks out into a new branch locally. And now in my working directory, I have all the files with her changes. What I could do is I can quite open up the S code now. I can actually make changes to the things she's done. Let's see if I can do anything which is pretty non-destructive. What can I do? Which doesn't matter. Markdown events. Adds two dots here. So get status, get diff. I've added a minor change here. Minor change as if I was working myself. But remember I've got her poor request checked out. Now if I do get push, I've CLI set up all the remotes and everything properly to track this poor request. And I've now pushed to fans fork of this repository. And because of that, it's updated her poor request with my change. And I've added a few more things here. Which is in this case a bit irritating. But this workflow is brilliant when you're reviewing other people's code. Because if you've got lots of minor changes, like wording things, instead of making loads and loads of comments on the GitHub interface or whatever, if there are things you're confident about, you can just go in and you can just edit them and commit them and just push them to the poor request yourself directly. Which saves everybody loads of time. Because you don't need to wait for the other person to respond. They don't need to apply all the things you've suggested. This is of course really good if there's multiple people working on the same poor request as well. And the GitHub command line client just takes out all the thinking, all the configuration to be able to do that. You just do GHPR, check out the number, do your work, commit push. There are some cases where this won't work, but for the majority of times this works. Super, super cool. Right. And then quickly, I'm going to quickly just make sure that my master branch is up to date with that bad fork. Which it wasn't. GHPR, check out. Go back to fans and poor request. And I'm going to update it now by get merge master. So I'm bringing in my master fork, which will update her branch. And I'm going to get push again. And it will push in the updates here. So now that's if I refresh that should be gone. Yeah. Now her poor request is up to date. This is also really useful when there are merge conflicts, because if I'd done get merge master and there'd been merge conflicts, even really complicated ones, I could then resolve them locally in my, in BS code or however, take as long as I want to commit that and push it to the poor request. So that's usually how I resolve merge conflicts is by doing GitHub command line, check out the poor request, fix it, push it. Right. So that's good to go. Now I can actually go a bit for the next step. I'm going to go, I just got master. I can now merge her poor request. I'll just give it a thumbs up. I bet I could do this. Let's see if I can do this from the command line. I bet I should be able to do it through VS code or the command line. If I want to do going to review it when I'm going to do HPR merge. See what happens. It's a bit of a merge conflict. Done. All through the command line. Pretty cool. And final, final thing. I'm running a bit late. That's a GitHub command line. You can do loads of stuff. Look, this is all just with poor requests. You can also do GHPR view and minus, minus web and stuff like that. Get up command line client is loads of stuff. So check it out and see if it can stream on your workflow. One of the things I also use it for is I have a couple of helpers. You might have actually seen me use one just then. I have one called G update master, for example. You can see this in my, my dot files over here. This is a little function. All it does is it takes this argument and it pulls it from, pulls my local changes from my fork. And then it pulls the changes from the upstream fork, assuming that there's an upstream. And then it pushes those changes back to my fork again. And then it cleans up any dead branches which have been merged. So that's like a little helper function which I find really helpful. And you can see, maybe it doesn't. I was thinking it used the GitHub command line client. This one does GHPRs. It actually uses the GitHub command line client here and exports Jason and then uses JQ to do cool stuff. So because the GitHub command line client knows your authentication, does clever stuff with Jason, you can do really powerful little bash snippets using a GitHub client if you want to get fancy. So yeah, check out these. If that would be helpful for you. GS, I use all the time, G update and G clean. I use all the time. Just little kind of shortcuts so your fingers get used to. Right. I've been talking too long and I'm waffling on and on and on. So let's, let's go on, see if we have any questions or any discussion and any, any things that I've done badly which you think you could do better yourself. Thank you, Phil. Now I know what it takes to get my code reviewed and merged. So are there any questions in the audience? I think everyone is just amazed. So if there are questions coming, you can always go to Slack. And in the bite-size channel or you can ask Phil directly. Yeah. If there are no questions otherwise, then I would like to thank Phil for this. Yet another impromptu. Bite-size talk. And of course, as usual, the Chan Zuckerberg initiative for funding the talks and all of you for listening. We've got any volunteers to show me how to use GitLens properly. That would be a good follow-on talk. Thanks.