 Yes, now it is. Yes, Sly. Sly, I'll do the introduction, I guess. So, welcome to Esmeralda 2023 and this introduction to GitHub workshop. It's being live streamed to YouTube, so automatic subtitles will be available shortly after the event, and we'll work hard to get these manually verified as soon as possible. If you have any questions, trial presenters, you can ask them via the ES Hackathon Twitter account by commenting on the tweet about the session. And if you registered for the conference, you can comment and chat with other participants on our dedicated Slack channel, and we will endeavour to answer all questions as soon as possible. This workshop's being live streamed to YouTube, and it actually has a group of participants taking part live, so a very warm welcome to you all. And those participants can ask questions directly in the Zoom Q&A, but we'll endeavour to read them out for those following along on YouTube. Our workshop presenters are me. I'm Chris Pritchard. I work at Lestercomb Trent University. We've got Matt Granger, who works for, and I've instantly forgotten. So I'll let him introduce himself and Matt Jones from X-Tourist Fielding Questions. Sorry, Matt. That's OK. Yeah, so I'm Matt Granger. I'm based at the Norwegian Institute for Nature Research, which is in Trondheim in Norway. Excellent. So should we get started? Yeah. So I'm going to talk about GitHub today. This is the basic introduction to GitHub. I'm leading this one because I am the basic person in the team here. And later on, Chris will give you the fancy pants advanced version. So I'm going to try and take it slowly. I'm going to assume that the people don't know too much about GitHub and integration with R and RStudio. But yeah, it's fairly low-key stuff today, so I won't hammer you with lots of different things. And the main thing I'd like to get done really is to give you guys a chance of having a play around and trying it yourselves if you can. So that's the main thing. But so what I'll do, I've got like six or seven slides, just an introduction. And then after that, I can go through how in practice, you might be able to use RStudio to connect to Git to make a project and do some of the things that are useful within there. We won't be using the shell, which is the coding part of using Git language to GitHub. We'll be using all the inbuilt RStudio tools. So later on, if you're interested in the shell, then that's the advanced stuff. So you can have a look at. So I've got some slides, which I'll share now, if I can work out how to do it. So you should be seeing an introduction to GitHub slide. Yes. Thank you. Just one warning, I'm at home now. So my internet sometimes cuts off. So if I freeze in a funny position, just please just tell me once I come back again. I've done that. Let me put this to full screen. So this is workshop seven. As we come to 23 and introduction to GitHub. Before we can even start to use GitHub. There's certain things we have to do. So one of the things is the need a GitHub account. So they're free to get very easy to start up with. There's a link there, which I'll put into the chat in a second. Which has the way you can get your, your get began. You need to download Git as well. So you search online and find Git and download it to your computer. And I've explained the difference between Git and GitHub isn't in a second. You need our studio obviously because you can't use RStudio without having RStudio. And then there's a really good. Blog type of thing from use this package that tells you how to set up your account, between your GitHub account and your RStudio. So it's really useful to have a look at that. And let me just put those in the chat. I'll do that. If you want, you can carry on. So what we want to do through the workshop is to understand the concept of version control. Understand the basics of linking RStudio to GitHub through your work. Understand committing changes to RStudio and pushing those to GitHub. And then pulling changes back down again and explain all these, all these terms soon. Understand pull requests and understand other tools. In GitHub itself, there's these extra tools like issues and discussions. And we will use, which helped with the collaboration with other people. So what is Git and what is GitHub? So Git is the open source version control system. It was created by this guy Linus Torvalds in 2005. And what it allows you to do is to track changes basically of files over time. So the idea was to for it to be used for coding. So software development, so open source, open software development. And it allows people to track the changes that happened over time. It's useful in that format still for code. But people increasingly use other things as well for other document types. Although people often use data, it's not actually designed to such to save data. It's not a long-term safe repository for data. And also when you put like an Excel file onto Git, it actually struggles a bit to maintain version control in Excel file or a CSV file. So I would recommend putting your data somewhere else. But like a small amount of data is probably okay. But these sort of big database probably wouldn't work. So Git is this version control system. GitHub, as the name suggests, is a hub for Git. So it's a website that contains different repositories. So places where the collection of files are that are tracked by Git. So GitHub itself is owned by Microsoft, just recently taken over by Microsoft. They seem to want to keep it open, which is really good news. But there are other options that have a very similar approach. So I talk about GitHub today because we know when we work with GitHub. But there's GitLab, which has a very similar approach. And there's a few other types of products that are very similar. Bitbucket is another one that is very similar. So you don't have to just use GitHub if you don't feel verbally against Microsoft, then you can maybe choose something else than an approach. They basically do all of the same thing. They allow you to store versions of your code in a repository, a place where all the code and your changes are maintained, which is stored on your computer, but also in the cloud on GitHub's website. So why use Git and GitHub? Well, GitHub makes it easier for users to interact with Git. So Git is the language, the system that was developed. But unless you're a computer scientist, like Chris used to be in his past life, then you don't really understand a lot of the way that Git works. With GitHub and GitLab, it's just a little bit easier for people who don't have a full coding background. There are some coding to evolve with, but it makes it a lot easier. But as I said, the most important thing, the most important reason for using Git and GitHub is this version control system. The version control, all that is, is you're going to use, is that sort of track changes, as I said before, for code and the files. So I like this diagram from the Turingway project, which is open science, but they're one of these issues about having several final drafts of your document. So if you have a right to get thesis, for example, you might have thesis final one, thesis final two, thesis final 37. And you end up with lots and lots of documents that are saved, that are exactly the same, but with minor changes over time. And then you maybe get a bit lost, like, am I on thesis 37 final? Am I on thesis final 37? Oh, I don't know. So maybe you need to try and work out which is the latest one. With version control, it just tracks the project history. And basically it's a lot cleaner. So you have one document and the versions are saved. But actually you don't actually see that unless you want to go and find the different versions. And if I make a mistake, and I think to myself, actually the version 17 versions back in time was much better. Then I can easily go back and find that version with version control. It's key also to show you could show people how your, your thoughts and your code and your project has developed over time. It's a tracking of the history. So it's very good for open science and sharing all that information that someone might want to look at with your project. So it's a very, very useful system to have. So when should you start using GitHub now? So start using it now. You can use GitHub as an individual. You don't have to have a team of people around you. You don't have to be collaborating with people. And I say this because often you sort of collaborate with yourself. So the past me may have written some code and I put onto GitHub and I can come back to that code and I can see what I did. I look at the different versions previous times, what I changed, what I didn't do, what I tried and what failed. So as an individual, you can actually use GitHub. And I think 90% of my projects are probably individual projects. So I'm not working with the team. You can use GitHub as a team or a lab group. So you can use it to collaborate with others. So we use it in ES hackathon. So ESMACON hackathons a lot because it's a way of collaborating with people at both time and space. So I've seen the Trevers here online with us today and Trevers in the United States. So I'm in Norway and other people in the UK and we're having a hackathon. It's very difficult to actually be at the same time at the same place. But with GitHub, you can make your changes. You can push them up and someone can look at those changes and review them in their own time. So it's a very nice way of collaboration. If you're a coder, GitHub is a great place. It's a natural place for you to go with your code, to save your code, to share your code, to show everyone how good you are at coding or that sort of thing if you want to. So you can make your shop window, sell yourself on your CV with your GitHub thing. But importantly as well, if you're not a coder, GitHub is also useful for you. And I say that because if you think about how a lot of the times maybe it's not just code going up there, it might be a figure from your thesis. It might be part of your thesis or a paper that you've written. And using GitHub allows you to track the changes in that paper but also allows you to communicate with your co-authors and they can provide information and evidence, extra evidence bits that they want to put in. They can also review yourself through GitHub. So there's actually a really strong argument to say that as a non-coder, you also might want to use GitHub. I'm probably pushing it a little bit there with that, but yeah, people who are not always coding is going to start to use GitHub. So in GitHub there's lots and lots of different sort of terms that get a bit confusing. So I just happened to have written this paper, not just me, a big group of us. And in there on, I think in the interaction in blocks one, we have a plus three of terms. So the sort of terms I'm talking about is things like repository, we often shorten that to repo. I'm not seeing the, I don't see that. Hang on. Yeah, the old fashioned not being able to share the right screen. Can you see it now? Yeah, I can see it. Oh, sorry, it's gone. Yeah. Yeah. Okay. So yeah, you've got the repository, which is a, we shorten that to repo. So that's your files. There's everything's tracked by Git. As the owner of the repo, you have rights to how you can use it. You can set it up to being public. So everyone can see what you're doing. We can set it to being private. So any people you want to see are there. Okay. So on your local system, your repository is also stored, but then you can actually push it up or pull down from the cloud. I'll show you how to do that in a minute. People talk about forks and forking. And all the fork is, and here's a copy of someone else's repo. So on my get up account, if I fork one of Matt Jones's repos, I'll have a copy of his, his code and everything there. And it will still remain maintaining link to his get up account, his project, but I'll have my own version of it. So I can make changes on my version. And then I could say to Matt, Oh, I've made these changes. All requests. And he'd have a look at that and say, no, it's rubbish. And you have a fork, which is our local thing. Clone. So cloning repository is making a local copy of it. So you can clone it. And I'll show you how in it. And have your own version. You might not be able to do then. Depending on the settings of the owner of the repository, you won't necessarily be able to push up to that repository. So you have to do a fork first. And then you can actually interact with that person. Branching is really important. So branching is basically how we, how we make developments in our code. And I'll explain this a bit better in a little while, but it allows us to have a version of our branch. Sorry, our main code that we can change. Let's say we want to, we find a problem. We want to fix it. But we don't want to make a mistake and ruin the main branch that we'll be working on. We'll keep that safe. We can actually separate out our code and work on a particular problem and then bring it back together again. That's a really, that's a really good part of working with code in this, in this way is that you can actually develop tools or functions that you're not sure they're going to work, but you can develop them and then you can see whether you can pull them back in. It's useful when you're working with lots of different people as well to each have their own branch to work from. And then you can try and bring them together, merge them together back into the main. Another term you might see is commits and that's probably the most important term. When you make a change on your local version, you commit those changes. And typically you make some changes and you add a message saying, I've made these changes, generated and included results and figure. Typically I just say, made a change which doesn't help. Don't do what I do. But yeah, you should have a good message. And that basically gives you a time stamp and tells you when, at which point you were, so you can go back in time and look back through the commits and see what's changed at which point. There's not really any sort of great sort of advice I can give you about when to commit, but as often as possible, I think it's the thing. And then pushing and pulling. So when you make commits locally, you want to synchronize that up to the repository on the cloud and you can push them up. And you can also pull any changes that be made on the cloud back down to your local repository. And the pull request is, it shouldn't really, really call the pull request. It's more like a merge request, but a pull request is where someone else or a different branch wants to merge their changes into the main branch, for example. So it describes what the changes are and has all the code and the testing that someone's done and tells you whether or not it can be joined together into your main branch if you want it. So finally, I've mentioned merge already. A release is something that you do by having a, it's a point in time where you think the product you're making or the code you have is at a point where it's shareable publicly, for example, and you can make that a release and have a snapshot of that repository at a certain time. So if you're doing like a paper or a manuscript that you want to share code with, it's useful to have a release. So that's the first version of the code. There's the second version of the code and so on. So you can actually have a stable release of code. And finally, the community is a forum for users to ask for advice. So somewhere to share ideas and ask for advice. So they're the main terms and I'll probably say some of them. And if I, if you forget what they are, that table's there, I've linked in the chat to where it is. And I've also posted the link on Twitter and chat and Slack for those of you following along on YouTube. Thank you very much. Yes, on YouTube as well. Okay. So let me just stop sharing for a second. So what we're going to do now is going to clone a repository and bring to our local version. I'm sending you a funny message. Bring to our local version. And then we're going to make some changes and commit those changes and then see what happens on the system. Okay. So in our studio, I just have to share the screen again. Sorry. We did have a question on YouTube. You probably get to it now. In our studio, how can we launch a remote repo from a local folder? It might be what you're doing now. Yeah. So I'll come to it in a bit, but yeah, there's, there's, this is what I'll talk about now a little bit. And there's, there's two ways of doing it, but I'll go with the way that I go. But it might not be the best way to do it. So that's the thing. So in our studio, I think you can see my studio now. So here I have, so I may have set mine up a bit different to the way you have, but I've got script file here, my console here, all the files and plots and packages on that side. And then the environment tabs here. So in our studio, I can go for a new project. And products projects are a way of in our studio to actually give some structure already to your work. So it's quite a useful thing. Anyway, you don't use git, you can use a project. And here you've got three options, a new directory, assistant directory or version control. So I'm going to do version control because that's, that's what we're trying to do here. And I'm going to choose git. What you can see here, you've got this, it asks for repository URL. So if we look on GitHub, I'll stop sharing and then we share again. You know how it's pretty an easy way for me doing this, but I'll look it up. Yep. Let me just find my GitHub. Matthew, is there anything you want me to help with? I don't think so. Great. Thanks. I'm just trying to find my GitHub. If anyone has any questions, just pop them in the YouTube chat. Okay. So here we have GitHub. So this is the AIS hackathon GitHub account here. GitHub.com AIS hackathon. And the AIS hackathon has several different repositories. And this is one repository I made the other day. So you can see that I've added a readme file, readme, which says test repository for Esmer. So if I want to go to this Esmer.com repository, I want to clone it. So remember, cloning was about bringing it down locally to my own system. So you can see this big green button here that says code. You can actually copy this URL there. Copy that. It says copied. And then we go back to our studio. I'm going to stop sharing again and move across because I don't know how to do that. Back to our studio. And then in the repository URL thing, we can paste in our URL. So we have Esmer.com. It gives you a suggested name. I'm going to change that because I already have a version of this on there. So I'm going to change that slightly. And then it asks you where to put it. And then you can create the project. The course access is denied because I don't know why. I've been having trouble with my computer the last few days. It's bound to go wrong today. So what it should do is to give you a project and you download everything. I'm just going to test it with another one. I think it might get this causing me the problems. So I'm just going to choose a random one. Well, while Matt's trying to solve that, I think we've just had a question on the Zoom chat that I might know the answer to. So I can field that one if you want, Matt, while you're trying to solve that. So Trevor's asked, when starting a new project package, is there a template that covers the basic structure? Would you potentially clone a repo for a package? You know, well, would you recommend starting from scratch as a learning opportunity? So RStudio, when you actually create a new package, does have a basic package structure for R. So it includes the R folder and a basic description file. So that can be a really good starting point. And then you can use things like the use this package to add extras into that package for other coding projects. So say you decide to branch out and use something like Node or similar, there's often very similar steps you can take with whatever language you want to have a basic template that initializes a project. It's probably not worth just starting with a completely blank repository and trying to create a package from complete scratch unless it's quite a simple one. Often these templates are quite useful and generally exist for most languages including R. OK, I know what the problem is. It's going to take me a few minutes to fix it. Just give me a minute. OK, so this is typical of these things that really breaks when you don't need to. So the problem I'm having is that because of my security system for my IT department, my Git sometimes disappears. So they're trying to fix it. So hopefully it won't happen again. But so here we have the same thing. We're using the RStudio server now. So it might look a bit different. The cloning repository from Git. Just give that number from it. And then we want to have EOS hackathon. And it was intro to Git. We have another question. I want to do that now. I've seen some recommendations for expanded file structure and content for a project. We've got a new project. Do you have any recommendations? So yeah, it's if you're making an R package that's going to go on to GitHub, then there are, as Chris said earlier, there are some recommended or some tools that help you just build that quite easily. Otherwise, it's really up to you. But I tend to have any R functions in an R folder. And then data folder and then yeah, some scripts or as a quarter or markdown files within it. But it's really up to you. But just the main thing is to try and not have too many big files. There are limits on how big your files can get before GitHub gets upset with you. You have to get quite big, but it's still it's doable. So you just need to be a bit mindful of that and have a logical structure. It's useful when they read me. If you want to share your repo with other people, it's useful to have a read me that says where the important things are and what those things are. So it could be like you have all the R functions found in the R folder. You can rerun this code using, yeah, this quarter or markdown file. Yeah, so that's all we can use. So I'm just going to get this to get this. OK, so I'm creating a project. OK, so now what we have is the project created. So this is now my local version. It's actually on the RStudio server. It's my local version of that GitHub. Repo. So you can see that I've got the same read me. Test repository for Esmeralda. I've got a thing called the here, which is this is the project file. So this is what R uses. And then you have a file called git gnaw. The git gnaw is a file as it suggests is all the things that Git should ignore. So the things that use gnaws there is the R project. So the R project user. So that's this file here, the R project file because it's not very useful for it to track changes in that thing. The R history can get very big. So that's probably something you don't really want to include there and any user data. So the things about that are particular to myself. I might not want to share. It's all protected. So it doesn't go through and you can change that to put anything on there that list. You don't want to make changes. So that could be, for example, if you've got lots of camera trap images and you go through camera trapping images, you don't want to share those images because they're quite big. I often have this problem. You can actually just put jpeg.jpeg on there and any files that have got jpeg ending won't be pushed up to git gnaw. So that's quite useful. Yeah, you can also put folders in there, right? Yeah. That's about it. It's all the things you don't want to upload in that folder. Yeah, it's a very useful thing. So what you'll notice now is that we've got now we've got this other tab here, the git tab. So that git tab is your tools for working with git. So we mentioned before about committing, pull, push. There's the branch you're on. So we're on the branch called main at the moment. We only have one branch. So we've managed to clone our database, our repo. So what we can do now is to start making some changes and commit them. So if I write something in here. I've written that this is testing workshop. I've made a change. Now, if I save that change, it doesn't change. No problem. Typically. OK. So this is going to be. So now we have our, I don't know if you can see the commit window. No. How do I just share what I'm looking at? You might need to click the little up. I might need to click share screen and just choose the whole screen rather than just the window. Share that screen. Yes. There we go. Thank you. So this is the commit window. So I clicked on that commit button in the studio window. And it shows me the changes I've made. So let's have a look here. So here I've got the read me and I've added. This is a test during the workshop. OK. So and it's added a new line. So they're my changes I've made. Now, if I click on that, give it a green tick. It's stage, which means it's ready to be committed. And I can write a message here. Change. I never write detailed messages, but you should do. And then you can just press commit. And then it's all working. Of course, it's unlike me for because I'm on a system. So we've made our first change. Just to wake up again. Sorry about this. Just going to change it. OK. So we've made those changes to the MD file. You can also see there's an HTML file when I looked at it. So we've made some changes. It says here your branch is ahead of the origin main by one commit. So we've made one change. So we've committed. Now what we want to do is to save those changes. By pushing them up to the cloud. So we can use these buttons here, pull and push. Now by convention, I always pull or push just in case someone is working on the same thing as me and they may change. So normally I would pull and then I would push and push now and see if it works. Of course, it doesn't work just because it's one of those days. Here. So I might just come in here. So GitHub changed the way they did logins. I think it was last year or a year and a bit ago. So it's now a bit more complicated than just using a password. So you might have to create what's called a personal access token on your GitHub account and use that instead of instead of your password. And that will let you log in. And basically it's for security purposes. So within your GitHub account itself, there is a in your settings. There's a on the password and authentication somewhere. There is a way of creating a personal access token to log in to Git. Just carry on for a second because I'm just having to answer this question. Oh, where's the question always running in small small issues. Yes. So Trevor, in terms of is that I'm guessing for an R command check to fail, you can actually run your R command check locally prior to pushing it. And that will allow you to sort out so you can commit your changes or even just have them staged ready to commit. You can run our CMD check locally. Make sure that there's no issues and fix it that way. So that's the way I tend to do it is I'll address the RCMD check issues locally before even push it up to GitHub. So you just run the RCMD check command. And yes, I'm saying this story is on YouTube is saying it's under settings developer settings and then tokens. That helps. Yeah. So I'm solving this problem with Git. I'm just trying to reinstall it. That's all right. Yeah, it's in settings developer settings if you want. And then you just use that instead of a password on the R Studio Cloud. So just wait for that to log in. I do find sometimes our command check on Windows just to address Trevor's point can be a bit funny because our on PowerShell has another meaning and it starts talking about command histories and stuff. So I can never remember how I end up do it. I always end up having to Google how to actually run our command check on Windows. But I think there's an RCMD check package you can install and run it from directly from within our which might resolve your resolve your issue. Trevor. I have something to help me with this question on YouTube. We're talking about adding this to the Gignore. How do you write folder path in front of? Oh, yeah. So it would be more data. Yeah. So get ignore. I mean, I'd say you should tune into the advanced GitHub workshop. Well, yeah. Well, we cover Gignore in a bit more detail. But I will post a reply on the YouTube chat, I think with that. Yeah. Bit less bit more straightforward to reply. But I'll post a link to the. Yeah. Okay. So I'm back. So, yeah, I've made a different change. I've put the change read me in there and I pushed it up. So this is my local version and I've pushed it up here. And then we can see it and close this one. So now you can see that this is on the cloud. So this is the repo that. G has changed one minute ago. And he's added something here on to read me. So I've made that change. A couple of minutes ago. So that's how the workflow of sort of making a change and committing and then pushing up to. To the cloud is done. So the cloning repository. So another thing we need to talk about really is pretty branching. So let's say that we have this repository here. We have the main branch. So that's the most the one we want to keep safe. Maybe that's the most important one for us, but we want to try and test something. So we can do this. We can do in our studio. See this funny symbol here. This is the branching symbol. We do a new branch. We can call it. It's something like that. So we can create this branch. So what it's doing at the moment is copying. The. The main branch and then giving a new branch. And you can see here, we're in this new branch called Mac. So here what I'm going to do, I'm going to add a folder. The R folder. And then inside that folder. All right. Okay. And our function. Okay. So we've got written a function called a city function. That will print. This is a function. Okay. Completely useless function. We're going to save that. Okay. So we've made a couple of changes now. We've added. An R folder. And we've added. An R script within that folder. On this branch. Okay. So I'm going to commit those changes. Okay. You can see here the R folder. The R there in the city function. And then we're going to commit those changes. Okay. And then we're going to create a new branch. And then we're going to create a new branch. Okay. And then we're going to commit those changes. And our folder. I'm going to be good. I'm going to pull first just to check that there's nothing changed. It's already up to date. That's great. I'm going to push. Okay. So that's been added up. And we can double check that by looking at our. Positive tree. So now we have. Another branch. We have the main branch. And we have Matt at our. She's been updated by me now. Okay. So. Now we have two versions. Of the same repo, but one with a different changing. Yeah. So let's go back to our studio and I'll show you how that looks. So. Now on my local files. I've got this extra folder are. With the city function. So if I go to my files. Yeah. Dig through thousands of files. Sorry. Yeah. So this is my local folder. This is my. Local on my computer folder. And you can see here that we've got a folder called. And inside there we've got this city function. This is what really sort of blew my mind when I first started using. I know it's really stupid, but it's not that exciting, but. Okay. Are you ready? It's like a magic trick. Okay. If I switch back to the main branch. So we switch back to the main branch plays that now. And let's first have a look here. Minimize me self. As if my magic, the off folder is disappeared. It's not there anymore. If I go back to our. Folder here, the main folder. You can see that the off folder itself is gone. So what it's doing is switching when you switch branches. You actually switch all the way through your local system as well. So that's, that's something that you, yeah. So sometimes I end up panicking because I can't find something I knew I've done, but it's because my branch is the wrong branch. Okay. So it's, it's something to remember. If you, if you like me and sort of quite easy to panic about things. But yeah, so it's something you can do. So now we can make changes within our, but let's switch back to our. At our branch. Okay. Close that. So let's say that you can see now that ours back again. Okay. So let's switch back to our city function. So let's say that we want to. Merge our city function in with our main. Branch. So from our Matt at our branch to our main branch. We're going to have to do that. We can do it through our, but the easiest way is through. GitHub. So we go to our GitHub site. And you can see that very usefully. It says that Matt at our has some changes recently. You can do a pull request to compare and pull request here. You can click on that. And then what it's going to do is going to check first of all, if this, these changes are compatible with the main branch. So you can see here's got this big green tick. They're able to merge. So it means that we don't have it. Something they call merge conflicts. Merge conflicts are the bane of my life and they're quite annoying. So you can see that. Two people or you have made two changes that conflict each other. So maybe on the same line of code. Or in the same file that means that they can't be done together. You have to try and sort out the mess. But here we're okay. We can merge that. So this is at our folder and city function. Okay. I would like. Okay. So I'm going to then create a pull request. And then we're going to do the automated checks. We'll just check whether there's any conflicts again. You can see what changes have happened here. As I said, there's no conflicts here. So we can actually merge the school request. So when we merge the full request, what's going to happen is that our, from our branch will move across to our main. And they will be synchronized again. Okay. So they can feel that merge. And it's merged. Once it's merged, you can delete that branch if you want to. It only deletes it on the GitHub. It doesn't. So you can delete it here. And then if you realize, oh no, I shouldn't, didn't delete it. Or you can just use your like a branch and push it back up again. Okay. That's not a problem at all. So you can have that. There's different branches. Use them. And you can see here that now, if I go back to the code. We have our folder. We have our city function. In there. And it's all in our main branch. Let's go back to our studio again. Okay. I'm going to switch to the main. Look. Here we don't have our folder. So what we have, this is why I say it's important to remember to pull. Before you push. So it's here. What we need to do is pull those changes from the cloud. Back into our studio. And they're saying this added this our city function. Our holder. And then you'll see that now on our main branch. The main branch. We have an off folder with a city function. Does that make sense? And can you see the. The, the use of it outside of a silly idea. Or do we need to explain a bit more about the, the reason why we do this. Do you think. Pulling is like downloading. Yeah. Branching doesn't have. Branching is like creating. A different version of your. But you don't, you know, actually having to copy it. You just sort of create a. A dose of it. Which I think it has emerged. Yeah. I mean, there's a lot of these sort of. So. Terms that are sort of a bit confusing. But just, it's, yeah, really just remembering that there's. Get sort of has these. Terms. Things like. Pull push. Merge. They're quite straightforward to know what they. They need. All those. The hidden change. The change. The change. The change. The change. The change. The change. The change. The change. The all those. The hidden change. The changes. The history of change. Is that stored in the. Get folder. Yeah. Yeah. Yeah. And that's like an invisible file on some computers. Yeah. Yeah. Sometimes hard to find that, but it is there. Yeah. Not just. So. If you're feeling brave and you fancy having to go. You can. For. The. Repository. So if you. As long as you have your own. Yeah. Get a blog in. You can go and you can fork. So on the. I'm not sharing the screen. Sorry. This. That's great. So on this repository here. We can press. Fork. So ask me where I want to fork it to. I'm going to fork it to myself. I'm going to. I'm going to. Create. For. So this fork is now my own version. Of. That repo that belongs to. Yes. You can see here says fork from. Yes. Now there's a few things that are really useful and they're. Quite new. So because. This is my own version. Any changes I hit make here. I'm going to. Fork. Fork. So this fork is now my own version. Of. My own version. Any changes I hit make here. Won't necessarily be able to. To. Automatically link up to the other. Sight because. Basically you're. Taking a copy of someone's code and you want to. Make changes to it for yourself or for them. And you want to contribute to the project. So what you can do is you can. Sink your fork. So this won't happen now because everything's the same, but you can simply fork to get the changes that they've made. Into your fork. And all you can contribute. So that allows you to a poor request. From that fork. Now the process would be the same. Of. Getting this into your local version with the R studio. Going onto the code and cloning it down into the R studio project. Exactly the same way. But this time it will be in your name. And not. On the as we come. Sight. So if you have. If you have a name that you want to try that, please do. You can try and clone. Sorry, trying fork. The, I'm going to get myself confused here. For the repo. And then get into your local site. Then use the code button to clone it down into your. Project in our studio projects. And then you can make changes and then see how that happens. Any poor requests. That would probably be ignored, but we can have a go. So yeah. Feel free to have a play around. And the same with any of my repos. You can, you can fork them. That's not a problem. That's people expect that. So there isn't really a. Yeah, any. Problem that the etiquette usually is just that you. If you're forking someone's work and you want to make changes. And it's good to actually suggest those changes to them to make. So if you think that something needs to be changed, but it's fine to just copy someone's work. I often do it for papers and things. If someone's got a repeat repo. And they have all the code on the. We'll get up. I'll fork their repo and have a look at how they've worked it. And maybe get some ideas myself. I think work. Okay. So that's forking. And just to prove to you introduced merging. Yeah. That's a good question on merging. It was, what do you do in the case of our merge conflict? Okay. So merge conflicts are. Sometimes fun. Sometimes horrible. So yeah, with the most conflict, what happens is that when you go through that process of a pull request, they'll say that it cannot merge. But it doesn't mean that you can't do the pull request, but it means that you have to make some changes. So what it'll do is actually show you. The versions. Side by side, or mix each other. And it'll show you where the differences are. And then you need to decide at which difference you want to take forward. Do you take the latest version or further on. So these, these processes allow you to sort of. Yeah, check what is the right code to do. And that's why I would say commit quite regularly. So you avoid having these massive conflicts because that could be very, very painful to play with. But having a few lines of code to have a look at and then double check. That's okay. And once you've cleared those conflicts. If you have them quite small, you can do it within GitHub. If they're larger, you have to do them within desktop desktop. Or in RStudio sometimes, but it usually only for small ones. You can actually just do them in, in, in this area here. And it allows you to, to see the different code. So it's a very useful way of sort of. Yeah, having an overview of what the changes are and then making and confirming which changes you want to keep. It's actually quite a simple process. But yeah, keep it, keep your changes. Quite small start with, don't do anything big. But we'll take days and days of work. Commit every day at least many more times during the day. I don't know if you guys have rules of thumb for committing how often you do it. I think it, for me, it depends on what I'm doing and the kind of project I'm working on. I tend to commit to a fork probably quite regularly. But I try and make sure that each commit works. So I don't like committing half finished functions. Because I, I find that bit annoying. But that's just me. Someone's asked about going back to old branches that have been deleted. That's on YouTube. I think about, and I'm guessing it means deleted remotely and, and locally. If it's deleted on one or the other, it's, it's relatively straightforward. And I guess if you do, are you able to just demonstrate how you can get back to a different branch of it's gone. If you've removed it from GitHub. Yeah. So again, press the wrong one. So on. Ends that have happened. Long list. And then we don't have that branch anymore. All those are gone. We need to go back in time. Yeah, looking the wrong place. That's why we've used me. So we can see all the commits we've made over time. So we've made four commits here. And we can actually click on any of these and restore them. So that's probably the change we've made in the past. So we can always go back in time to her. She finds the things and I can't find where it is now. Just to be annoying. To go back to the branch. Yeah. I think you, if you've deleted the branch, you might have to, it might be under the main. If you click on the main, it's probably gone now. Hasn't it from there? But what it will be is it will be on your local. Yes. And then you can push it back up. Yeah. Because you've got the local branch there. You should be able to push that back up. Yeah. So now the branch is back. And if you've deleted it locally and remotely, it's a lot more complicated. And you have to delve into the command line. Yes. That's the advanced part of the world. Yeah. So, so that, look. I think with GitHub, there's nothing you can do wrong and you can't sort of, well, there's a lot of things you can do wrong. There's, there's, you can't really destroy everything unless you're very unlucky by mistake. So, but there are some commands that you might need to, to find out how to do. There's a great site and it's called something like, I'll have to find it for you. Something like, oh, shit. And it's where you make the common mistakes that happen. And how to solve those with the command line. So that's quite useful site to find. If you, if you get into trouble, but the, basically you can't really make too many mistakes on this. In our studio, you can see all the history. So these are all the things that have changed. As read me, I've changed the name and read me. Added the R, the R folder in the city function. They're all in there. So you can, you can actually get back to the, all the commits you had before. And it gives you a little code here. And this is what, one of the codes where you need to have in the command line. We'll need that code to go back in time to that, to that point. So that's the unique ID for each of the changes you make. And that's where that information is in our studio. So if you see something asking you about the FHA, it's H A code, that's the code you'll need, which is a, in the history part. We have another question. You don't know that one. Yeah. Yeah. I'm not sure I fully understand. Is there a way to commit and test the change without pushing? How does that work? And what is the best practice steps? Yeah, definitely. So it's branching. So you don't have to, you can, you can make a branch. You don't have to push it up to get hub. So if I want to have a branch that I keep locally, that I don't make changes to, that I make changes to, that I'm just working on locally, that's fine. But it's good practice, I think, to actually push it up to the cloud, just in case you're a computer dies, or you have a problem with your get like I did a minute ago. Those things happen when they happen quite regularly, or your computer gets run over by an elephant or whatever it might be. Those things can happen. So I would always have, I often call it Mac development or Mac dev branch. So that's anywhere I'm messing around with stuff that may not work, might be stupid, but I have this branch. There's no cost to having lots of branches. There's no real problem with having a lot of branches on there. So you have 15 different branches looking at different aspects of your code. That's fine. It gets a bit complicated when you're trying to merge everything back together and which parts to merge, but that's up to you really. But I would be, I would make a new branch, have it as a development branch, and then make the changes that are of interest to me in there. Yeah, I think that's quite a common approach in software development, is that you have a development branch, and then usually there'd be multiple people involved, and they would then explore that development branch functions as intended, and then, you know, we get merged into the main branch, which is like the working version of the software. That's another analogy. Yeah. Okay, so I'm going to talk a bit more about the sort of some of the features that you can use within GitHub that are useful when collaborating on projects. So this is a project that's about the ecological condition of Norway. So it's a large project we have in Norway. And this is a documentation of our code and how we did make the calculation for ecosystem condition in Norway. And what we're doing in this project is we have three code reviewers, and then we have maybe 15 or 16 experts who work on different aspects. So it could be an expert in threatened plants, they're an expert in forests, they're an expert in mountains, mountain habitats. And none of those guys are really coders, but they do have some understanding of code, but they're not necessarily coders. And what we have is three people who are code reviewers, myself and two others, Anders and Hanno, who are coders. And then we ask people to upload their code to this site. So when they've done that, we get this pull request. Okay. I show it on all one. So in the pull request here, this is from a doctor, which is like non-native species. And there's Anders has made the changes here. And what you can see is that you have this review tab. So he asked for some reviewers, myself and Hanno to have a look over the code. We can actually look at all the stuff that he's changed. So just go down to, these are the different files he's added in and how it's changed. Large. These are the files he's added, he's added in that process. And what we can do is we can actually do. We can discuss different changes. Information back and forth. So it's really useful communication tool to actually talk about the code and how it changes over time. And this is all documented and kept so we know what's been changed. Back here. So there's a process here reviewing process that it shows you the changes that happen within. Well, so the green one is the changes and the red ones have been deleted and changed. The ones that did the additions. So what we can do, we can go through and review these changes. Yeah, you can leave comments. We can add comments to a particular line, for example. So that would add to that line. Any changes have made all documented. So this is really useful if you're working on, for example, a manuscript. In quarter or markdown. And you can go through each line. You can see, well, there's a mistake there. Add a comment and then the person will get notification. There's been a comment added on and then they can make the changes they see fit. That's a really useful tool. Really helpful tool for assessing things. And when you do a poor request, you can ask for certain reviewers. So you can tag a reviewer. So if I make a change to Matt's code, I'll ask him to be a reviewer on that. And I might ask Chris as well, because he's really good at code. So add those two reviews on and they'll get a notification and they can come and look at the code. And they can agree or disagree or they can argue about it. They can say maybe you should use this approach, but not that approach. It's a very, very useful tool, very helpful tool in there to make changes. The other tools are really useful within GitHub are things like the issues. The issues are things where something needs to change or there's a bug, there's a problem. Okay, there's something not working. So for example, here we've got a bug. We have a description of what the bug is. The problem with the template that the indicated chapters. And then we have someone who's assigned to do that work and make a change. In this case, it's me. So there's description of the problem. And then some extra bits and how it's linked to other things. And then you assign it to me to work on. So that's my job to fix this problem. If I can fix it, I can close this issue. I haven't fixed it yet, so I can't close the issue. But that's how to use issues. So that's their very sort of issues I see normally as sort of something directly about the code. Something that's really focused on the code. This discussions tab is quite new. Discussions that I see more broadly, maybe about the project in general, or there's lots you can add in there and discuss. So it's a longer form, broader approach. And it's not necessarily just directly about the code, but you can turn discussions into issues. And you can link issues and discussions points together. It's quite a useful tool, I think to have. Any of you can download this code, have a look at it. You can work through and see what's there. So the code on this site. And anyone, we welcome anyone to do pull requests. So if you see a mistake in our code that you think is an issue, you can highlight that. You can write an issue, see where the problem is. And you can also make a change on your local version and then do a pull request over to us to see if we agree with you or not. And that's basically how this collaboration often works with other people, is that you have, you write an issue, you find a problem, you then write a pull request, you fix that problem, and then you send that pull request to the owner of the repo and they either decide to make the changes themselves or to use your changes and make you a contributor to the project. It's quite a collaborative way of working. So do we have any more questions, Matt? Nothing at the moment. There was one, that one from earlier, bring up again. Can we generate a remote repo from a local folder in our studio? So can we make a, sorry. Remote repo from a local folder in our studio. Yes. So you can. In the use this package. There's a way to create. Your screen isn't shown as well. Okay. I need to find the actual one anyway. So that's fine. The use this package is really cool. It's got loads of really helpful functions in there. And fairly recently they've started to put up functions for you to interact with GitHub. So use GitHub takes a local project and then pushes it up to your GitHub, your personal GitHub site and creates a repository. So it's a really good way of taking your local repository and then moving that up. As you say. Typically I don't use this approach because it's fairly new, but I think it's. Yeah, I think it's. It's something that the increasing I will do, but normally I start the process by starting with a GitHub repo. Just a blank one and then starting a new project locally and linking up using the code. The URL for the code linking up together and then doing it that way. But yeah, this use. Use this package allows you to go the other way as well. So if you started with a project a while back, and you just want to add it up to GitHub, you can do it this way. In the command line, which Chris will talk about later, there's even an easy way to do this and GitHub itself tells you what to write in the go on line. So when you initialize a new repository and show you on here. I'm going to go to my own site. I'll do a new repository and create a repository. So here. So this is the code here. So I can either use this code as I showed you before. That's the same green tab. Or I can use the command line. Well, this is the one that we're talking about here is an existing repository from the command line. So if you have an existing repository, you can actually use the command line and use these commands here. To actually push this your repository up to this site. So that's another option is setting up the GitHub. Like I've done now a new repository, get into this page and then using these commands here in the command line, which Chris will talk about later on, the terminal command line. And that allows you to do that process. So that's quite a useful tool. You do have to have an existing, it has to be an existing Git repository to do that. But that's as easy as one command. If you type git in it, as it says there, if you've got any folders in there, you just need to add your files and folders. So get in it, get add minus a and you're good to go. Yes, it's quite straightforward process. But there's nothing in the graphic user interface on our studio. Yeah, if you if you want to do it using the users package, then it's just writing code into our studio. As long as you have a Git, a GitHub name, so get up site. And as long as you have the right token all in there, then that's fine. We just push something up. Yeah, or there's this approach using the command line. So I found that there can be sometimes it's a bit tricky with the users. Sometimes it works really well and sometimes it doesn't work at all. Yeah, so yeah, as I say, my repo and then yeah, so I think the whole process that way. Yeah, it's probably one of the things that's going to be ironed out in the next few days. Yeah, I think so. Yeah. I think mainly the thing with Git and GitHub is just trying. As I said before, you can't really break it. If you do break it, then you'll be very sort of famous because it's very hard to break. But don't be frightened of it. Don't be frightened of using Git and GitHub. It's a great tool for collaboration. So a lot of the work that probably the best fun I've had is collaborating through GitHub. Makes me sound very sad, doesn't it? But some of the best things I've best work I've done is collaboration through GitHub. So the paper I wrote with my colleagues from Sortie on GitHub. We actually did the whole process, the whole manuscript using GitHub. Using something called Manubot, which is the GitHub manuscript repo. So you can just clone that repo and then you write your own personal manuscript in there. It's really good. It's really a great thing of working. So it's not just code. It can be manuscripts. It can be websites. It can be anything. It's quite a versatile thing. The one thing I haven't mentioned really is the GitHub pages, which is a very easy way to make your own website. So there's lots of help out there, particularly now there's Quarto. Our studio, if you're using Quarto, it's very easy to make a website which you can host on GitHub pages. So each repo has its own GitHub pages site. I'll just show you a quick example because we've only got a couple of minutes left. So let's go and delete that later on. Yeah. So you can have for each site you can have your each repo. You can have a GitHub pages site here. So this is the repo for my website. And then this is the website here. So it's very simple. Just as a picture of me picture of a pheasant because I like pheasants. Some information about me and then my publications listed here. It's a very simple thing, but all that is coded with R using Quarto and hosted on GitHub pages. So it's a really useful tool to have. It makes everything a lot easier to have it there. I can make changes locally to my within R and then push them up and the changes are done in a couple of minutes. So it's very useful. I've just found out the newest version of RStudio does let you actually create a GitHub account for a GitHub repository from an R package that you've already created. So I'll just very quickly show you that. I called it in one minute. So yeah. So in your RStudio package, I hope you should be able to see my screen. I'll just share my actual whole screen because I realized it won't show you the. So hopefully you can see my whole screen there. It's as simple as tools, version control, project setup, choose Git, click yes. It will restart RStudio and then hopefully come back with it being a Git repository. So give it a second. There we go. And that's now a Git repository. Wow. And then and then you just it's simple as you'll need to go back into project setup. Or you'll need to try and push it and it'll ask you for the GitHub URL to put in as your what we call origin. But there we go. That was less than a minute and we're back on time for finishing.