 Okay, and welcome to Esmeralcom for 2022 and this workshop on collaborative coding and version control and introduction to git and github. This workshop is being live streamed to YouTube and has a group of participants taking part live. So very warm welcome to you. If you're watching via YouTube and have a question for our presenter, please reply to their tweet in the at ES hackathon Twitter feed and we'll try to reply to these as soon as possible. And we would like to draw your attention to our code of conduct available on the Esmeralcom website at esmeralcom.github.io. And if you're with us on zoom and you have a question, please feel free to put it in the chat or raise your hand and we'll get to it again as soon as possible. Our workshop presenter is Matt Granger over to Matt over to you. Thank you very much Chris. Just share my screen. Okay, can you see my screen. Yeah. Okay everyone. Nice of you to join us here today. First word of warning, I've got a small puppy next to me so she may attack me any minute. So if you see my computer going moving really strangely, then that's that's her going on she's asleep at the moment so she stays that way. Neil asked me to talk about GitHub and our studio and how they interact and getting get itself. I really really started to use GitHub when I first joined with the evidence since hackathon 2018. So I'm by no means an expert in this at all. And it's basically what I've learned. I've learned things in the wrong way in a very cumbersome way, but I'm very old and I'm lucky to change now so there's. But, so take take what I say is not the best way it's just a way for doing things. So what is Git and GitHub. Well, Git is open source version control system. It was developed by a Finnish American linus took to us in 2005, and it allows you to set up to track the changes in a set of files. It was basically set up for allowing people to collaborate on coding for software open source software. Just want to note here that GitHub has been recently taken over by Microsoft or acquired by Microsoft, and there's lots of talk now about people concerned about the open source nature of it. So a lot of people are beginning to move over to GitLab. Now GitLab and GitHub as far as I can see a pretty much the same thing. There's a few minor differences, but a lot of the things I say for about GitHub, you can pretty much say the same thing for GitLab. So why would you use either use Git, which is this process, or GitHub, which is basically a hub for Git. And the idea really is it sort of track changes for code and other files. If you're aware of the track changes in Microsoft Word, this does pretty much the same job. It tracks all the changes you make, logs them over time, and importantly maintains the previous versions so that you can actually go through and go back in time to find out what you did and when you did it. There's changes you made, where the mistake was made, where the bug is. So what it does, it gets rid of this issue of constantly having this final, final version, or final, final, final, final, final version four. It's important to have those sort of ways of maintaining a version control and tracking what you've done over time. And as I said, it was mainly designed for coding, but actually, you don't really need to just do coding there, you could do documents, you could do any sort of file. There are people who use GitHub from our, from my community, the ecologists, things put data on GitHub. This is actually frowned upon by many sort of developers, but small data sets are probably okay to anyone there. So when should you start using GitHub now so we can start using GitHub straight away. You don't have to be an expert. You don't have to be amazing at this sort of thing. You don't have to be a coder. You don't have to be even that good with computers. I'm not. So if I can do it, you can do it. That's my message today. I'm talking about collaboration and collaboration, but you can also collaborate with yourself. So it's not just like working with you. Matt, sorry, we just had a question from Rebecca who's asked, why is it frowned upon to put data on GitHub? She suggested maybe privacy concerns, but just wondering if you had any ideas to expand on that. The reason is because it often gets too big and then you have problems with interacting with it. There's lots of, privacy is a really good, good example, but there's lots of ways you can maybe interact with data on the open science framework, and using R is quite easy to link the two together. There's plenty of other places to put data. If you need to have it on GitHub, there's this large file storage service on GitHub now, which allows you to save some bigger files on there. It basically links to this storage place from your GitHub, but it's best practice to maybe leave off the large data sets and have a link to them on a repository somewhere. Thanks Matt. So yeah, as I was saying, you can collaborate with other people, but also you basically collaborate with yourself. If you don't work on a project for a while, it's important that you can go back quite easily and find out where you left off. Often, when I look at my own code from the past, it's like completely different persons written it, so it's important that you know, you have this control over the versions. So the basic workflow of GitHub is that you've got your collaborators. So I've done these little drawings here. There's two different people in different parts of the world, and they're working on their local files on their own computers. They can edit the files there, but there's a, on GitHub, there's a version on the cloud, and each person can push up their changes to that version on the cloud and pull down the new versions. So it's an interaction between your local and a remote workspace, basically. So the biggest thing for me with learning about how to use GitHub, particularly with RStudio, was there's lots of these things called shell commands, and these are commands that you can talk to Git with. And a lot of them are quite confusing, and you need to learn what they are, and it's sometimes quite difficult, and I found that the biggest barrier to working with GitHub. With RStudio, though, you can actually get quite far without having to use any of those shell commands. Well, as soon as you get into any sort of more complex things, then you need to look at the shell, but you can start off with the pushing and pulling quite easily from RStudio. I like this cartoon because it basically says how wonderful this Git process is, but their person has no idea what they're doing. They just delete and make a new copy each time. That is one process you can do, and I've shamed to myth that I've done it myself several times as well. When everything goes wrong, you just delete your local file and pull down the one that's on the cloud. So I'm going to switch my screens now to show you how I initialize my own project from GitHub and how I link that to RStudio. That didn't work. Hang on. Let's go stop sharing and then try again because it's not working. Here we go. So you should see my GitHub profile now. So this is my GitHub profile, lists, which repositories I have, which one's the most popular, has a little bit of blow about me. So if I want to do a new repository, I can go up here. Nice plus button says new repository, click on there. And then I can set up a new repository. GitHub allows you to use a template so I could use a template from another piece of the repository that I've worked on. I won't do that today. And then we have a name. So let's call this as we've gone for example, the description. This is an example. You can choose to be either public or private. With GitHub now, you have a limited number of private repositories. So if you're using, if you've got some data that's maybe public health data, for example, you could actually have it on private so people can't see it. But I'm going to keep mine as public. Here you can initialize the repository with a read me. So that's really important for people to have a read me so they know what the repository is about. So I can add that in there. A git gnaw. Sorry, the dog's in the bark now because he's dreaming. A git gnaw allows you to ignore certain files that will be pushed up from your R session. So I can go to the templates and I can search for R. And then that tells git to ignore certain files that come locally from my computer. There they are history file for example, you don't want to push that up each time. And then you can choose a license. There's lots of different licenses you possibly choose and it's really up to you to have a look at these. You can just use a public license for this one. And then you can create the repository. Sorry, Matt, we've got another question from Matt Jones. So Matt has asked on the private repository, if you start up repository as private and then make it public, will the version control history then become public? That's a good question. I think it does. Yes, I think it does, but I will double check for you because I'm not 100% sure what I think it does. And my understanding is it does as well. I think what once you make it public that in top because of the way git works that entire repository is then public. Okay, so this gives us this page and gives you a link here and we can copy that link so the copy thing there. And then we can switch over to RStudio. RStudio I can press for a new project. And then go down to this version control, git, and then paste in the repository. And then you'll see there this EsmerConf example. Great, that project. What that's doing is bringing down a local version of the GitHub repository in the form of an R project. So we don't have many files in there because we've just initialized it. But what we can start to do is to use this repository to store our code or whatever we might be doing. And then we can push it up to GitHub. So I'll show you how to do that. So first of all, let's make a change in the readme. So we've got the readme it says this is an example. So that's our readme now is just changed every few ways to that. And each time you make a change. You want to keep. You can do a thing called committing. So you commit a change down here in RStudio you've got your git. So it shows you whether when there's a change being made. And what we want to do is to commit this change so that we have a record of it's being changed. This will be our first commit. So we can change the readme. Click on commit. It shows you what the changes are. The old version and the green is the new version. And then we can just add a commit message. Now I'm really bad at this, but it's really important that you actually give yourself a very good descriptive commit message because the amount of times I've just gone commit number one and then gone back in time and thought why the hell did I do then. So try and give yourself something to remember it by but I think that's probably an art rather than anything else. Matt, sorry, I don't think that that windows popped up and visible on your screen. Unfortunately, I think it's only sharing the main RStudio window. So let me see if I can share that then. Yes, we can. Yeah, sorry about that. So yeah, this is the commit window. You can see that the readme. We changed. Here is the old version. This is an example. We've changed that now and add this green version here. This is an example setting up hub repository for RStudio. So here's where you write your commit message. So Again, that's probably not really good commit message. Resistant to change. And then you can click here commit. So what that does is it logs that change. So you can see that it says one file changed and one insertion. It's found that it's showing the change that's happened. I can close that. I'm going to close this window and then go back to the main one. So share again. You should see my RStudio now. So what you have to do now to get this up to GitHub is to push. And down here you've got a green up button and a blue down button. So you can push with the green one and pull down with blue one. So it's good practice to always pull down first. Particularly if you're collaborating with other people because you might miss a change. So you can pull down and it gives you a message saying everything's already up to date. Which you might not be able to see on your screen. And then I want to push up. And then once that's done, I'm going to switch screens again and show you what that looks like on the Git side. So, sorry, Matt's just asked to double check. Pull is like download and pushes like upload basically. Yeah, basically that's perfect Matt. Yeah. So it gets a bit confusing because the terminology is it gets a bit difficult. But yeah, basically you're pulling it down from the cloud and then you're pushing it back up in the cloud. That's how I think of it for these two commands. Yeah. As I say, it's important that you remember to pull before you push. Yeah. Keep remembering. It's not a push me. It's not a push me pill you. It's a pull you push me. There should be that way around. How you do. So you can see here that on this repo we've got it's changed. Now it's changed this. Read me for us and it's changed out of the edit. We've got it on there. So that is basically how you commit. How you commit your changes and each change you make is important then to sort of any major changes to commit. Otherwise you might lose it. So there is a possibility that your computer dies or whatever. If you have committed your changes and push them up, then you couldn't actually pull that back down again. So Nicholas has asked how would conflicts be resolved? For example, if another collaborator has done changes at the same time. Give me a chance. I'll get to that. I didn't want to scare you yet. That will come in a little bit longer. But remind me if I haven't said it. I'll go through how that works. No worries. If you don't cover it before the end, I'll nudge you. Thank you. Thanks. So that was the part, the most simple part, basically pushing and pulling, making changes. With GitHub, what you can have is several. I'm going to change my screen again. Sorry. Just struggling a little bit. So we go back to my slides. That's all right, Matt. Virginia's got a question about having asked you to own GitHub desktop. Couldn't create the new project using Git like it was shown. It tells me Git was not detected on the system path. I can potentially answer that, Matt, if you're trying to get back to your slides. So you need to install the Git as well from git-scm.org. If it's not included with your RStudio install. And as part of that install process, there's an option to add it to your path. Yeah. Thanks, Chris. That's really helpful. Can you see my screen now with that branching? Thank you. Okay. So we've committed our changes. But one thing you can do that's really useful in GitHub is you have multiple versions, concurrent versions of the same repo. So what can happen is that you have your main version. So you have your commits, the different changes you make over time. But what can happen sometimes is you find a bug and you want to fix that bug. But you don't want to work on the main one because you don't want to screw things up for yourself in the future. So you can actually branch off and I'll show you how to do this now, but you can branch off. It makes a different copy of the repo. And then you can bring these back into the main. So you can do that for fixing bugs or adding new features to testing and see if they work. Again, typically people like to work off the main branch. I've worked with different people who have different feelings about this, but most people say that the main branch is sort of sacrosanct. So you can't actually touch it unless you're in control of the project. If it's your own project, that's fine. You can do what you like, but often people are quite reluctant to change until things are working really well on the main branch. So I'm going to again attempt to change screens, we'll see. And again, back in our studio, we can do our branching. So branching in our studio is quite easy to achieve. So at the moment it tells us we're on the main branch. We haven't got any other branches yet. So we need to add a new one. We can add one here using this button. And that gives us an option to add a branch name. Now, I'm assuming you can't see the little window, but the little window that turns up that says the branch name and remote origin. That's what we want to do. I'm going to add a branch name and call it Matt1. What's that doing is setting up the branch on GitHub and then copying over the files that are already there. So everything should be the same. So we have our main branch and we have our Matt1 branch. So if you wanted to make a change onto our Matt1 branch that we don't want to do yet onto our main branch, we can make a change. We've made the change to our branch. We can commit again. So I'm going to do this quickly, commit. You can see this window, but then we can push that up. And again, I should have thought better about this switching thing all the times, but I'll switch again and get us back to the website. So an anonymous attendee has asked if a branch can be thought of as a copy of the entire repository? Yeah, at the start at least. It's a copy. But what happens is that when you make changes, those changes in the new branch will be there. So I'll show you that now. So if you can see my GitHub page now, back on the repository. So this is the main one. I'll read me is still the same. We've got two branches now, and we can switch our branches and we can see on here that we've made a change only in this branch. So it's, it is a copy, but then it allows these different changes over time. So it's another version. It's another instance of your whole thing. So often people use it to do, to fix things or to test out if a, if a new function works or doesn't work without having to sort of go in and change all the code in the main, just in case it doesn't, doesn't work and you have to go backwards, which can be tricky sometimes. So you've, the concepts so far are there's pulling and pushing this version control and committing those, those versions. And then you've got branching. You can, once you're happy with the changes you've made on one branch, you can then pull them to a pull request. This is where it gets confusing. Merge them into the main, main branch, I suppose is the right word. So GitHub's badly, badly worth this because something called a pull request. The pull request is really a merge request. So you're, you're asking to merge one branch with another. So if I show you how that works, you've got compare, compare and pull request here. I can do compare and pull requests. And here you can see it says able to merge. So it does a test that looks to see where the difference is. The question before was about what happens if it's not able to merge. I'll try and show you a bit later on, try and do that. Basically, if it's not able to merge, it gives you the option to hear, to actually edit which changes you want to keep and which ones you want to discard. So it'll highlight which ones are the ones that you have been made in each branch and allows you to then make those changes. So it's important when you're collaborating with lots of different people that you know how this happens because it's quite often you get these merge failures that happen. But here, this is merged. So we've added Mat1, changed the, believe me, this is a note to tell us what the pull request is about. So this is merging request, click on pull request. So it's telling me that my merge request is successfully done and now I can delete this branch. I'm not going to delete that yet, but we can. I'll go back and show you what that looks like. So now we're on the main and you can see that our changes happened here. So that's the basic process of doing that through GitHub branching. It's quite straightforward and quite easy to do. It's not complex in any way. It's just giving you in your mind that you have these different versions. So let's go back to our studio. So I'm switching the branch back to main. I'm going to make sure I pull down any changes. So there's one file that's changed. We know that file is the read me. So pull that down. And now I'll read me. He's up to date. We've got a new hub. So remember to pull before you push and remember to pull down whenever there's any changes being made. Do we have any questions at this point, Chris? None at the moment. I think we've managed to answer them all as we've gone along to be fair. That's good. So the next thing to think about is how you collaborate with other people and how to actually interact with people in GitHub. So one thing that you can do is pretty much the same thing as actually what I've just showed you now, taking down your own repository. You can go on someone else's repository and you can clone their work. So let's have a look at someone else's repository. So I'm going to change screen again. Let's find the right one. All right. So let's find... Okay. So we're going to find one of Neil's packages for BibFix that he's working on. And if you want to collaborate with Neil, what we can do is we'll go through the same process as before. We can, rather than setting up the GitHub repository ourselves, we can go to this green button here and see where it says code. And we can copy the code and go back to our studio. New project again, new project, Azure Control. So we need to do this. I'm just going to change the name because I've changed the name. So this is bringing down Neil's project. Taking all that information, all the code. And there we have it. We have all the code from Neil's project. So what this allows us to do is we can... The way I use this is either I want to look at someone, the way someone's made a package in R, for example, or done some coding in R. And I want to be able to adapt it to my own and basically steal that code and use it for my uses. Of course, giving them... Siting them if I need to. But also it allows us to collaborate with other people with code. So on here, what I could do is now I can make changes and I can suggest some changes to Neil through a pull request. Now I'm going to do this. Hopefully not destroy the whole thing, Neil. Sorry if I do that. So I'm going to make a change to one of these files. I'm going to add a new file. I'm going to put on... New file. Okay. So I'm going to call this... Okay, so complete nonsense is just an empty function. Save that in the R folder. Now I've taken this and I'm sort of wanting to make a change to Neil's thing, but he has some control over whether I can change it or not. So... I'm going to get this wrong, but I will try and invest. It's not working. Yeah, it seems... Okay. It's made to Neil's... So Rebecca's just said she's lost track of what's happening right now. So I was wondering if you could just go back over the little R commands that you typed in and maybe just explain what they did. Sure. So can you see my... Do you do? Yeah. Okay, so what I've done there is... Sorry, I messed up the first time that I got the error message there. So I'm using a package called use this. And use this has a set of GitHub functions that allow you to do pull requests and think of that. So what I've asked it to do is to send a pull request to Neil's BibFix package using this PR push. And beforehand, I had to tell it which branch to use. I've just used the main branch, which is very naughty of me. I shouldn't have done that, but yeah, it's just a lot easier to show you that. So if you look at the use this package, you can find there's a lot of useful tools in there for version control with GitHub. It's quite a nice package to use. I can share a link to the use this package as well. It's quite useful. So all I've done is the same as we did before, we made a change and then we've pushed it up with a pull request. But rather having my own branch on here, I've sent it up directly to BibFix and asking what that does is basically ask the maintainer of BibFix whether or not this can be pushed up. So at the moment, it's empty because I haven't committed, I haven't made that change, but this is just a way of showing you how to do some of these sort of things. I'll show you another way of doing this process, which you might find a bit easier depending on your experience with RStudio. So let me just show you how to do that. Does that answer Rebecca's question? Yes, I think it has. And Matt's just said to use this just an interface to command line get in R. And I think, yeah. I think with the caveat that things like pull requests and stuff are more of a GitHub or GitLab feature rather than something built into Git. So it's an interface to command line get with a bit of extra bells and whistles, really. Yeah. It's interesting that Chris is the guy doing the moderating and I'm doing the talking about this. Chris is an expert on this sort of stuff, but I'm not. So the other way of doing this, you can see here that because I have access to this repository, I can actually make changes on here. So Neil's giving me access. I haven't made changes to where Neil, but if you don't have access to someone's repository, you can actually still take a copy of their repository. And you can do that using this button here called the fork button. And what forking is it is taking a version of this repository replacing it on your own GitHub site. And I'm going to do that. And it's going to ask me where I want to put it. I'm going to put it on my own repository. That'll take a few seconds to run through. And what it tells you is that this branch is up to date with Neil's master branch at the moment. So example of when to use this would be if you find an R package that you're interested in or you found a particular error, or you want to find an R package that you want to use, but it doesn't quite work for your dataset or your data type. You can actually fork it, bring it across to your own GitHub, make some changes there on your own local machine, on your GitHub. And then you can do a pull request from your local machine up to GitHub. And then it pushes it across to Neil's repository. So it's just another way. So if you don't have access to that repository, you can actually still make changes and request that the person looks at those changes. We've used them and maybe brings them in. So I've seen a few things like I've done with one package called Momsim. I found a spelling mistake. So I did this. I just took a fork of their repository, correct the spelling mistake, and then sent them a pull request suggesting that they could change that. And that's what we did with the changing. So simple things like that could make a change. Sorry, Matt. Someone, Matt, James just asked, why would a fork instead of pull the distinction always confuse me a bit? Is it about having permissions? Yeah, exactly, Matt. So yeah, it gets a bit confusing, but it is about since we're having permission to make changes on that repo. So with Big Fix, we both have the permissions to make changes. But if we didn't, then you'd have to fork it to bring it across to your own repositories. What happens is when you, even if you go through the process that I showed earlier with the use this pull request, it won't allow you to actually make pull request directly. It'll say you've got to fork it first and then take you to your own repositories to fork it over. So it's just an extra, I think it's just an extra protection over where you're not actually collaborating yet with the person. So it gives a bit of a space between the two. Yeah, so fork is basically when you don't have those permissions. Okay, cool. Thank you for that. So that's fine. And someone else has said, what's the difference between cloning and forking or repository? Although I think we've kind of covered that. I can repeat it again. Yeah, that's fine. So yeah. So cloning is, cloning would be to bring it down to your local site. And you use this button here to get the code. And you might not have permission to actually make changes to it on the GitHub repository. So, but you can still clone it and bring it down to locally. Then you can push you back up to anywhere unless you pushed it to your own site. And to do that, you want to fork it. That's the main difference is that it's about having permission to do it or not. Does that make sense? If it does. Yeah. So all of these things, you've got these poor requests asking how to, if you can make a change to something. But there are other ways as well to interact with people on GitHub. And I'll show you a couple of those. I'm going to go back to my starting point. So this is just the repository for the slides I've made, the little website. And there's different areas now in GitHub where you can actually start to make some discussions or ask questions and those sort of things. So the first one is these things called issues. So issues are things that you find that you could either be a bug, so something's not working. Or you want to suggest an improvement. So an issue is, so I've added one here. A short note to say what it is about. And I say a list of GitHub resources would be really useful for workshop participants. Okay. That's my issue. Issue number one there to add an issue. So you can add an issue to anyone's repository. You want to. You need to click on here for a new issue. And then you can add an issue. This is styled with markdown. So you can do different markdowns styling. Title. You can add code in there if you want to. Issues are really useful for yourself. So I often use them for things like if I've, if someone's, if I've forgotten to do something or something I'm going to flip my mind, I can just put an issue on. So make sure that you remember to do X. Issue there. You can assign people to the issues. So I can sign myself. It's just here. So I can sign myself to do something. I can also assign Neil to do something on there. And what that does is then sends a message. To your email or notifications. And allows you then it allows you to be reminded that you haven't done this issue. Issues can be labeled to the whole set of labels. A bug needs some documentation. This is a duplicate of another issue enhancement. You'll often see this, which is quite a good one. Good first issue. So if you see that, what that means is that the reviewer, the maintainer, sorry, of the repository probably hasn't had the time to do something that's quite a small change, but they're opening up for other people to have a go with. And it's quite an easy first issue. It's quite an easy thing to do. So people want you to help. Another one is help wanted. So if you, if you see that, they're looking for help on something. And question is also quite common. So these issues are ways of basically tracking any, any sort of. Reclimates that you need to do to make your project better. So I've seen people use it for review request review. They're wanting to reuse from, from papers and things. So that's, that's one way of doing it. You can have them as issues. What's really cool with issues is you can set them up. So if you go into the settings tab, you can find issues. And we can set up with templates. So there's either a bug report feature request or custom template. Let's do a bug report preview. So what this does, it sets up a template. Cause what you want from someone who's looking at your code or your, your R package, you want to know specifics about what the bug was. So what was the bug there? What happened? The steps to reproduce that behavior. What you expected to happen. And then screen slots or what you're using type of system you're using and so on and so forth. And you can, you can adjust this to whatever project you're working on, how you want it to happen. So these templates are really, really useful. I find them really useful to, to actually target what information you want from someone who's commenting on your repository. Thanks Matt. We just had a question in, and I think it's, it's related back to the code itself and, and, and get, but. Uli, Uli has asked, are all changes documented? Where and how, for example, is, is fixing a simple typo documented or what is actually documented in the change log within get. Yeah. So each time you commit is given a unique identifier. And that's what's logs. And you can, you can go back and see those changes. You can see when for this one, I've done two commits, one called the initial commit, one called update, read me. And then you can see what those changes were. Here I've added a lot of text. And here's the commit ID. So each commit has his own unique ID. If you want to go back and find it, we need to find this, get this ID and get that from, from get. So that's how it's done. So each, each change that you commit, then is recorded. So that's the, that's the versioning. So that's why it's important to commit. They say to commit hard, to commit often. So you, you don't actually lose this changes that you make because you could make loads of changes on your local system. And it could crash. If you haven't committed, you'll actually lose all those changes. So you still need to do an action to make it. Keep those versions going. So issues. Yep. So these are some of the issues. I don't know if there's much more I can read about issues. We've just had a question about issues actually. So someone posted an issue to a repository. Am I informed of issues in the GitHub desktop app? Or should I check for that in my browser? And they've also said, thank you for delving into the communicative possibilities in working with GitHub. It seems very helpful for developing a workflow. Thank you. Yeah. So the issues, whatever there's an issue, you can, whatever there's an issue that someone answered, you get a notification. So for me, it goes to my email that's linked to the GitHub, but also you can see this blue dot here. I've got some red notifications. So somewhere, something's happening that I need to be aware of. I can show you that actually. So here is from one of the hackathons. Oh, it's you, Chris. And Chris has written something there about an issue. So it's just continuing the discussion on them had in the past. So that's how we use them really is that the, they allow some discussion, but also allow you to track what you think needs to be done. Back again. So as well as issues, there's now a longer form discussions tab. I'll show you what that looks like. So these basically allow, they're quite similar to issues in many ways, but they allow a bit more of a free form discussion about things. So I've just added one here. And my discussion is we need to come up with a list of resources that works up systems might find useful. And I've answered that with a comment saying, I'll go first. Here's a useful set of resources here. And we continue on adding resources, adding comments on there. What's good about these is that you can actually, it's less formal, I'd say, than the issues. But it allows you to have a bit more of a conversation around things. To be honest, I don't really use the discussions much yet. I haven't found that much more useful than the issues, but they are there if you want to use them. To set up discussions, you have to go also into the settings. And you can add them here, this toggle on off. Okay. So we've got issues as one way of communicating discussions is another way of communicating. You can, if you have a bug report, some of the work, if you go onto the GitHub site for the package, you're looking at the R package, for example, you put an issue there, often people will respond quite quickly to problems and try and help you out. If you do that, it's important to have reproducible code so you can find out what went wrong, all those sort of things. So that's why those templates are quite useful. Okay. We've seen that you can do, committing your changes, pull them up, these merge requests or pull requests across different things. You can discuss things with issues and discussions. So that's the basics, I suppose, of how to do GitHub. I make it sound a lot simpler than it probably is, but it can be problematic sometimes. So what I'd like some of you to try if you're willing. Matt, sorry, before we start with the interactive activity, we just had a question come in from Matt Jones. He wants to go back a little bit back to when we were using RStudio. Yeah. Notice that RStudio has its own GitHub UI buttons and stuff, but they don't always appear. They seem to be activated by our projects working in local GitHub Associated Directory. How do you activate these? Or if you've not seen them, that may be something to dig into the documentation. So, yeah, so Matt, you're asking how to get this stuff up, basically, these buttons here. Is that correct, do you think? Yeah. Yeah. Okay. So whenever you initiate a project with version control, the Git will come up there. But normally, now I can't see it because the top of my screen's gone. So in the project options, you can, so if you haven't gone to a project, so you're just doing it normally, you can go with the options and you can choose a version control system with Git. And the next time you restart R, then these Git buttons will appear. So you can have your own Git repository locally, if that makes sense, rather than actually pushing up to GitHub. And that allows you to do that. Thanks, Matt. Does that answer Matt's question? I think so. I'm sure it'll tell us if it doesn't. Yeah, I don't know why Matt's asking me these questions because I've collaborated with Matt on projects before on GitHub, so he knows everything as well. He's just been kind. Neil's just also helpfully added that sometimes on the GitHub interface in R, sometimes an update to RStudio or lack of an update because the GitHub tab to disappear and a hard restart sorts it out. And Matt said that he's been using GitHub desktop rather than the integrated functionality in RStudio. So that's that. Right, there we go. Cool. OK, so we've got... I'm going to change screens again, sorry. So you're going to try and do a little bit of interactive work. So you can see... I'll copy a link to this site. So this is the site for the workshop. We've got two branches. It's the main branch. I'm going to talk about it in a minute as well. I'm not going to talk about pages, but what I'd like you to try and do is to find this site. I'll give you a link. And then just to put an issue, to add an issue. So let me find how do I get to the chat there. That's the link to the site in the chat. And then if you add an issue on there, you can write whatever issue you want just to practice using issues. You don't need RStudio or coding experience to do an issue. It's straight onto the website. I've just seen Rameez's question about how to deploy it in a website form. But I'll talk about that in a minute, because I think that's quite useful for us. I'll show you that. I think you just sent the link just to the panellists. So let me resend that for everyone. There we go. It's amazing how after two years I'm still really awful with Zoom. So let's see how we get on. We've got an issue there already. So someone's added an issue. Thank you. So with issues, I can either do something with them so I can comment on them and say, thank you for your issue. I'll do that. I could assign them or label them. And that allows you to organize the issues a bit. So you might have some issues that are more important than others, like bug reports might be more important. And you can label them to find out what they are. When you finish with the issue is close with a comment. And that removes the issue says I've finished doing that job. It's ticked off, it's done. So lots more issues coming in. Thank you very much, everyone. It's really cool. So adding issues is quite an easy way to interact with people on GitHub. It's quite a straightforward way. I'll give you a few more minutes to do that. You can just add more issues. That's great. Thank you. I won't reply to all of them, but I'll say thank you. I can close that with a comment. And then that disappears. There's three closed and 10 open issues. So that's how we use issues. Someone asked about. Website, how to make it a website. Get our pages. So. I'll show you this repository. So what you can do, which is really cool and very easy is set up your own website linked to this repository. Now. Here you go to settings. And on this side. Got a tab called pages. You click on pages. The minds already on. So it's here. This is where my websites. Deployed. And you can choose a branch to actually. Deploy from. I'll show you how this works in a second, but I'm using the branch. Give up pages, GH pages. And taking it from the docs file. The folder called docs. If I go back to my code. This is the main branch. There's not much on it. But if I go to my GitHub. Pages branch. See, there's actually. Different files on there. So there's some. RMD files and markdown files. Produced. I'll show you one of those. HTML. Document. So when I knit that in our. And I can show you in our. When they knit that in our. It. Creates an HTML file. And what I can do is. I'm going back to the wrong one. Sorry. You can write a site. YAML. So YAML is another language. Another mark down language. And that's. Allows you to. To. Basically. Write. A website. Controller. This controls the website, let's say. And it's quite straightforward. It's just a name, title, description. The directory you're outputting to, which is docs in my case here. And what the website will contain. So these different HTML files. That we've made with Markdown. So that's basically it. And then. Once you push all that. To GitHub. From this branch. You can actually make it. Produce a website for you. And that's the website you saw before. This one. Can you see that? So I'll show you how to change that. Perhaps in. In. Our studio. And then we can see how. How. Updates. From there. Let's go back to our studio. And just while we're here. Matt has. Just quickly. It's not a question so much as a comment, but I think it might be useful for those who've. Watched live. Live. So he said it looks like to activate the R studio. GitHub interface. You need to be working with our projects. And in the GitHub directory. I had a script in my GitHub repo that I wasn't using. Project for. But when I created a project, the GitHub interface magically appeared. So I think that's. For. Anyone who has a similar issue to Matt. That might answer your question. Yeah. Thanks for that. That's really useful. Yeah. I tend to stick to. Working in projects. Because it's just a lot neater. So maybe that's why I haven't. Experienced that problem before. So I switched over now to that. To this. Other repository, which is. The workshop repository to make this. Get our pages. And. And you can see that. This is my. Get up rages. Branch. We're building the website in. And. I'm going to. Show you the YAML again. And then show you the. So YAML. That. The site YAML just. Describes. The interlinkages between the different pages basically. The good thing is that. After this workshop. You can all go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. You can go and. After this workshop, you can all go and onto this. My github repository. You can claim my repository. And you can build your own website. By just copying. These and changing the. The titles and things. And. All the information is there for you. It's quite easy, easy to do. Yeah, it's very easy to do. So let's change something. So the index is just about just that front page, the first page of the website. And we can do, so we can say, there are some useful resources. Add a link, it didn't actually exist there yet, so I'll have to just change that. All I'm doing here is making a link. Okay, so I've created, I've added this sentence that says there are some resources listed on the resources page. And there's a link to something that doesn't exist yet, so we're going to have to build that file. But first of all, I'm going to save that and then knit it. So that's in our markdown. Knitting to HTML. And what that'll do, because I've got this site YAML that says that the output should go to the documents folder, the docs folder. It will produce that for us in that folder. Okay, and then what we want to do now is we've said we want to have this resources tab, a new file on markdown. So I'm going to save that, I'm going to save it, and then knit it again to HTML. And that because of that YAML will send it to the docs file. There's nothing on that yet, but what we can do is then commit. So we've made some changes. We want to make sure that we update those changes. So we've made changes to the index. So down here, I think again. Make some changes to the R&D file, the markdown file there. We've also made changes to the docs folder, the index HTML file. So that's the two files that have been changed. And here, resources, GitHub, R&D. And then docs resources, GitHub, HTML file. Added those files. I'm going to commit that to the GitHub pages branch. So commit. But again, you can't see that, but I'll just commit. We call it add resources. I've got a question if I may, Matt, just because I'm not usually familiar with our studio. Is there a way of, and I don't necessarily know if there is or not, of just committing all your changes without having to manually choose which files you have changed? Yes. So there's two ways you could use this interactive thing here. You can, when you click on commit, you can stage all the changes. That's one way. The other way, which is probably the way that you might prefer is you can go to the shell, and then you can write the shell commands straight into the shell. Which I won't go into today because it's a bit complex. But yeah, that's probably the quickest way of doing it. That way. Cool. Thank you. So just to check. So if you click on the commit in the UI, there's a stage all changes button for keeping track of that automatically. Yeah. So there's a stage all and then it's not quicker. So one thing I will warn people is that our studio is a bit temperamental, let's say. So if you try to change lots of things all at once, it sometimes gets stuck. And you, yeah, I can give you some examples of how to deal with that. But sometimes it gets stuck and then you, it doesn't push forward and don't do anything. And just, you get this horrible wheel of death going on. So I would say that if you're making big changes to do them in small chunks, that's the key. So I'm going to pull and then push. Don't think that state push up those changes to our GitHub. So what I've done is changed to make sure now I've added a new page to the site. And then we can go back to our GitHub site. You see it takes quite like sometimes three or four minutes to make those changes to appear. And you can see sometimes. I'll share the screen. All our branches here. So add the resources here. It gives you a green tick to say it's all done. And then we can have a look at the site and see if it's actually there. And of course it isn't that. So the resources page here's some help useful resources. So that's updated. But the resources page itself hasn't yet. Oh, yes. There you go. There is there. Brilliant. I know why it's not there because I've gotten to do something important. So I'll show you that now as well. So it does link to it, but let's let's see where I've made the mistake. And go back to it. So when I said about the YAML site, it's really important that tells you what's going on. So I need to add that resources page into the YAML. I just copied that over. Make sure the spacing is the same place because YAML is a bit funny with things like that. All this is saying what the text is. Resources. All the resources GitHub. I'll update that now. I'm just going to commit that pushing these up now. What's changes? Matt. So an anonymous attendee has asked if you could give some guidance on how often you should be committing and I've just lost the window there. That's clever of me. How often you should be committing and pushing as you develop code. Do you just create a working repository, then push it to GitHub and iteratively work on it? Do you build it up bit by bit? How often should you commit and push every tea break, push at the end of the day? Yeah, that's a great question. I haven't got the perfect answer for you. I can't really say what's best, but what I do is whenever I've made, so I make some, make a local branch. So Matt's branch, looking at this problem branch, trying to describe it better than just Matt's branch. Then I do my coding. Maybe I'm testing something or doing a visualization. So I make sure that it's working the way I like it. And then I will commit at that point. But if you do something that's a bit more in-depth coding, it might be useful that perhaps you do it at the end of the day or lunchtime or whatever. So it really depends, but I like to have something that's not necessarily a finished product, but a product that is tangible before I push up. But if it helps as well, when I'm working on quite big projects, I tend to commit just based on adding new functionality. So if I add a new function, if I add a new bit of functionality, that's kind of when I make the commits. Because what I don't want is for my branch to be full of just cluttered with a bunch of commits that don't mean much. So I tend to do that. But if you're at a natural break in your code, so you're about to go to bed, a commit in a push is a good way of backing it up because you can go back. And it's not brilliant practice. And depending on your workflow might be avoided, but you can actually go back and what we call squash the commits together. But that's probably beyond the scope of this tutorial. Yeah, thanks. That's it's really it's interesting whenever you speak to other people because you think you're you're doing the right way and then you speak to someone else and they're doing something different. I mean, that's the right way. But then I don't think there is a right way of doing it. It's just best for you. Definitely. And we've also had another question from Virginia, who says she wanted to ask how do you merge upstream changes from master into a branch. So they use GitHub desktop, not the RStudio GitHub interface and couldn't find the solution on how to do that. Okay. So I'm going to be a typical teacher and tell you that the answer is out there, but I'll tell you where to find it. And so, yeah, if you look, it's again using the shell command, so it's a bit more, a bit more in depth than just in RStudio itself. But there's a great resource called happy git with our, and that gives you how to do that with the merging of the upstream branches. Sorry, puppy started to play ball. You might hear some growling and sparking in a minute. And yeah, if you look at that resource, the happy git with our that will actually give you the exact commands to use in the shell to make those changes. Thanks, thanks Matt. And just to add to that, if you're looking for it specifically, there's a tool called git rebase, which is the specific, specific command. So yeah, thanks Matt. So let's see if it does change the work now. So it should have had time to push up. No, not yet. You get the idea at least. Next sort of thing that you could have a go at doesn't have to be now whenever you, whenever you want to. So I've put my little my little issue here, and saying add resources to the pages site. I've actually put that in the discussions as well. And I linked that happy git with our that I mentioned earlier. So I think it'll be useful for you guys and for me, and for all of us to have a list of possible resources that might be good for getting up with. Sorry, there's a puppy going mad behind me. Excuse the noises. Yeah, a list of resources with for using get up with our. There's a few papers that are quite useful. There's a few blog posts and that sort of thing. But what you could do is you could actually clone my repository this repository repository here. Go on to the download your local machine and go into our and you can actually add to that resources. Markdown file. And then when you've done that, you can see if you can work out how to do a poor request. And I can show you the code again for poor request but another way you'll see is that actually just was you do a change and push up. And then you can do your local get up where you fought my repository from, but then it gives you the option of doing a poor request. So it'll say do you want to do a poor request to the month to the main repo. And that will be the challenge for you today is to see whether you can pull down this repository and clone it or fork it. Use on your local machine, gone to the resources tab, so that RMD file and add some lists of resources there. And we can see whether I'll keep my eye on the site. So if you do a poor request, I can accept that poor request and add up all those resources. Hi Matt, we have had a question. He said not sure I missed it in the start and I can confirm they didn't. But could you talk about the token authentication project with private projects and how to do that? I know it might be a bit beyond the scope of today. So I might want to just ping a link across to the documentation, but if you're happy to just quickly talk through it, that would be fine as well. Yeah, so this has changed quite a lot recently. So I'm a bit out of date, so probably useful to if I can find you the link to that. But again, there is some useful code in use this package to actually help you set up that tokenization process. So once you've got your GitHub profile set up and you sign into GitHub, then there is useful code in use this package, which I will find for you and link to that. So either I can put it onto this site and then you can find there, or unless Chris can find it. Yeah, I'll look for it and answer the question in the chat, but we can also put it as a useful resource in the GitHub page. Yes, that's true. So bear with me. Do you have any other questions? So this is the file you want to change. So you can add your own list of resources here. So I'm going to add that happy git with R1 on there. So I've made a change. I'm going to commit that. First of all, I need to convert it to HTML, which I haven't done. I need to knit that to an HTML. So someone's asked if you can show them the puppy map. Sure. I shall grab it. Also just quickly. So that I'll answer. So it's the person who asked about RStudio and version control. I just posted the link in the Zoom chat. But for those of you watching on YouTube and Twitter, it's just in the RStudio documents. And it talks about setting it up with SSH keys. So you can do that within RStudio in terms of the authentication tokens and stuff. I'll find the documentation from the use this package. Here she is. This is Flick. She's six months old. And she's a border colleague. The mix of Australian shepherd. She speaks three languages, Polish, Norwegian and English. Almost as well as I do. And she likes to make a lot of noise and bite me. Okay. So I've made those changes. I've also committed them. I'm just going to commit them now. So sorry. And for the... So for the... There's a question here from somebody who's just posted it. But I think it's a really good one. I can only clone the main branch and not the GitHub pages. How does that work? So maybe just how to switch between the branches in RStudio. Okay. So you should be able to... Unless I haven't done the settings properly. Just going to check. So you should be able to switch branches. But if you can't, what I'll do is I'll push everything across. That could be my settings on here that I've done something wrong. It should work. So if you show how to switch between the branches on RStudio. Because that looks fine because you can view that branch. Yeah. So on here, you've got the different branches and you can switch between your main and the GitHub pages. It's just this button here. Also, I've again posted the link to the use this GitHub credentials thing in the chat for everyone. But for those of you watching live on YouTube or catching up with this, if you go on the use this package documentation, so use this.r-lib.org, there is an article under the articles tab called Managing GitHub Credentials that talks you through exactly how you can set up GitHub, particularly if you use two-factor authentication. But if you're not able to do this and not be able to get to the right branch, what you can do is you can put an issue, you can list an issue on the side and tell me that you can't do it. And then I can see if I can fix the problem for you from here. The other option might be just in RStudio. Can you show your screen on RStudio? Because it might just be if you go on the settings and then shell. You should just be able to type git check out and then space and then the name of the branch that you want to check out. And it should just switch to it automatically. I don't know how well that works in RStudio. It should work the same as any other git. Okay, so look on here. Made our site. And that's been updated now. So you can see that here we've got the start of the list. Let's get the happy git with R. And then the tab there is list of resources. So yeah, if you, in your own time, if you want to have a go doing a poor request, that would be great. And I can, I'll have a look at them as they come in and merge them across. So I did mention about this issue with having switched back to RStudio. So I mentioned the issue about having when you do too, too much too many commits at once or committing too much stuff at once. You basically get an error message. I'll show you on here. Make sure I can show the right screen. So what happens is that it gets basically stuck. And what it says, it can't push up because it basically freezes. And then it thinks that it's still doing the previous git process is still running in the background because it never finishes. I mean, this happens if you have too much or if you are studio crashes, whatever reason, or you're forced to reset RStudio, and because it freezes. This, this can happen. And the really easy way to, to fix this is to go into the file, the folder that your repository is stored locally in. And you'll see that there's a git, a dot git folder. You'll find something called an index lock. And that's a lock files that's stopping the process happening. And you can delete out that lock file. And that will, and then restart R, restart RStudio. And that will actually clear that blockage. But then it's important if you, if you try to do too many, it's trying to do a bit less. So don't push too much up. So RStudio is a bit funny like that. And that's where they're using this shell makes things a lot easier because it's not using RStudio. It's doing things in a separate process. So if you've got really big commits, then I suggest looking into how to use the shell rather than doing RStudio way. So let me see where we're at. I'm not sure what else I can really tell you that was a whistle stop tour of GitHub. But if there's any questions or any particular things you want to know about. Let us know now in the chat or you can, you can write an issue or send me an email or send me a tweet or whatever. I can see if I can work it out for you. And a lot of the things I don't understand, but I can work it out. Amazing. Thank you so much, Matt. I've learned, I've been trying to follow it was to also managing other coordinating stuff. I learned so much that was really, really useful. Brilliant insights. Thank you. Yeah, as Matt says, keep the questions coming in on YouTube or on Twitter, there's a thread from that workshop. And thanks to the questions that have come in already as well. If you're following on YouTube, the links that Chris really helpfully shared are in the description at the bottom now. You can find those. And all of Matt's stuff that he's been showing is also any GitHub link that is also in the description or will be in the next couple of seconds. Great. Thanks very much everybody thanks for coming along. We hope you've enjoyed as Macon today. And we look forward to seeing more of you tomorrow. Thank you. Yeah, thanks everyone. And thank you. Just reiterating thanks for the great questions we had throughout the talk. It was, it kept us on our toes. Thanks very much Chris for great moderation.