 If you've seen any number of time travel movies, say like Back to the Future, you're familiar with the phenomenon of the hero, like Marty McFly, going back in history with some article from his present time, the picture of him and his sister and his parents, and he's looking at that picture, and every little decision he makes in the past affects things in the future. Well, we can do something a lot like that in version control with Git. Well, we're going to do just that today, where we're going to take the code that we've been working on, we're going to roll it back, and then we're going to go forward in future episodes. But don't worry, we're not totally going to change the future like Marty was concerned he might do, that will still exist. Does this sound confusing? Does this sound a little bit bizarre? Well, hold on and I'll show you just how we can do this all in our studio and with the help of GitHub. Whenever I talk about reproducible research and teach methods of how to improve the reproducibility of people's research, I always include a discussion of version control. And so sometimes that seems like a bit of overkill and, you know, we talk about version control, but people are kind of left wondering, like, why did we just go through all this, right? Well, one of the big reasons to push version control when thinking about reproducible research is that as we've already seen, it's really easy once you've committed changes to push it up to GitHub to make that repository public so that you or anybody else can get a hold of the code, right? So if you want to follow along in all these episodes, you know, down below there's a link. Well, if you've ever gone down to that link, there is a link to GitHub where you can get the code that I'm working with. Well, it's the same thing with your own research, right? That I could go to your repository up on GitHub, see your code and see how you've done things. That's a great win for reproducibility because it increases the transparency and makes it a lot easier to see what's going on. Another reason to be a fan of version control is that I can easily see the history of my project or your project or any other project, right? I can go into Git or I can go up to GitHub and I can look at the commit history to see all the different changes that were made. Hopefully you're using meaningful commit messages so that it's descriptive of what happened in each of those commits. But anyway, I could go into, you know, five commits ago and see what changes were made to the code. And I could see how a specific script or, you know, source code changed over the history of the project. And that's really cool because that again gives greater transparency and understanding of how the project evolved and perhaps why certain decisions were made. Another great reason to be a fan of version control and posting things to GitHub, and this is not that outlandish, is that it's a big undo button, right? There have been many times where I've been working on a project and I just totally screwed things up. Maybe I accidentally deleted the file or deleted scripts that I needed. I can use Git and especially GitHub to refresh my project and get it back to the state it was the last time I committed a change or the last time I pushed something up to GitHub. So I could perhaps delete my directory and I've done this in workshops to kind of make this demonstration clear. I could delete my directory. I could go to GitHub. I could clone my repository, bring it back down to my computer and get going again. So it's a great comfort knowing that if I screw something up, I've got a backup up there in GitHub. But perhaps I haven't screwed something up. Rather, I'd like to go back in time. So if you've been following along in the recent episodes of Code Club, you know that I've been building out this slope plot of people's attitudes towards receiving the COVID-19 vaccine from 2020, the August and October of 2020 in these 15 different countries. We've drawn this as a slope plot with the country names right next to each of the lines. I've gone ahead and make this dark mode theme and each step of the way I've made decisions that you may not like and, you know, in the future, I might not like. And perhaps you want to roll back to, you know, the original slope plot and go in a different direction. Well, that's exactly what I want to do going forward in the next couple of episodes. I don't want to get rid of my dark mode plot. I actually think that's kind of cool. But I do want to go back in time and then perhaps go off in a different direction. So we're going to see how we can do that using version control, using our studio and GitHub. Now, to be honest, I usually do all of this from the command line. But if I'm being honest with myself, I know that whenever I want to do something like this, I have to do a Google search because I do these things so infrequently that I can't remember them, right? Also, I get really nervous. I break out in sweats because I worry that I'm going to kind of screw up my whole repository because we have everything up in GitHub. We don't need to worry so much. And again, because we're going to use a graphical interface, hopefully it will be more intuitive than pounding out commands on my keyboard. By the end of today's episode, we will be able to easily get access to our dark mode version of the code and our figure, as well as the version of the figure that was the original slope plot as well as the code that in future episodes, we can go off in a new direction. Mainly going to be working in the right side of the screen today. Again, this is all going to work because my code has been under version control for the past few episodes. If you want to get the code and the repository that I'm starting with down below, as I mentioned earlier, there's a link in the description that will take you to a blog post for today's episode where it'll give you instructions for getting the code that you need to follow along. I strongly encourage you to do that. So again, I'm in my Git tab. I see it's clean that nothing has changed. I'm also in my project root directory where I have all my R scripts, my TIFFs, my R project, my other files, right? And so nothing has changed. If I click on this clock face, I will open up a history window that shows me the history of my project and shows me the 10 different commits that I've created, or put in, since I initially put this project under version control. So you can kind of see my messages as you look through the timeline of all the different things that have changed over the course of my project. And I can say look at this, the slope plot episode, and I can see all the different things that changed in that slope plot to create the slope plot, right, that this was all the code I wrote. And actually, this was a whole brand new file that this was the first time that we had created a slope plot under version control. I can then come to the next commit and see all the changes that I made when I added the titles and formatted the figure. And so you can see things in red and green, things that are in red, or things that were removed, things in green, or things that were added, right? So down here along line 23, you can see Geome line. It wasn't removed because we see that in line 24 down here, but I added the plus sign, so Git thinks that that line was changed, of course it was. And so you can see all this other stuff that I added, right? Again, you can kind of keep stepping through the history and see how things have changed over time. So I want to come back to this commit of adding the titles and format, because I want to use this as the basis for my future figures. So on the right side here, you'll see a link for view file at 3755053F0, that is called a SHA, and that's like the first eight characters of up here, right? So you could write out this whole really long mess of hexadecimal, I believe it is, and we all know about hexadecimal, right? But really all you need for working with inversion control is like the first eight characters or so, enough to be unique. So that's what we're going to do. We're going to view the file at this commit message. So again, if I click on view file, I now see the file as it was when I added those titles and did my initial formatting. I could then say, well, I want this, right? So I'm going to start from here, and I can then say save as I'm going to save it as the original file name, August October 2020 slope dot r, save it. And this is going to write over my current version, again, that being the dark mode version, and I can go ahead and close this. And now I come back and I see that I have modified my August October 2020 slope R. If I click on that, and I look at diff, I can see all the things that have changed. Again, red is what's been removed. Green is what's been added. And so we removed the GG repel. Again, that was, you know, important for placing those labels. And you can see, again, all the stuff that was removed and read stuff that was added in green. Again, this is in the context of going from the dark mode back to the original slope chart. So if I wanted to continue on from here and ditch all of the stuff I'd done with those labeled slope plots, I could go ahead and stage and commit these changes. But I don't want to do that, because I want to be able to go back to the original slope plot and go in a different direction while maintaining all the stuff for my labeled slope plot that's in dark. So I want to slowly back out of this. So I'm going to go ahead and close this, unstage it, and I can right click on status, and I can say revert. And so revert means go back to the way it was. So now I revert it. You want to change that? Yes, I'm sure I want to do that. And if I look at my October 2020 slope R, I see that I still have my library GG repel. I have all my colors for that dark mode. So again, I didn't go all the way through with committing that change. But if you had an old version of a file and perhaps somewhere that file got corrupted, that would be a great strategy for bringing that file back up to your current version and continuing on. But basically, I want to be able to maintain two tracks or two branches, as they're called in get version control, where on one branch, I maintain the dark mode theme, and another branch, I maintain what I'm going to call a highlight approach to visualizing the data. How do we do that? Okay, so that's the second approach that I want to talk to you about today. And to do that, we're going to need to go over to GitHub. So I'm at github.com slash Riffamonus. This is the homepage for the Riffamonus project. We're working in this vaccination attitudes repository. And so here you can basically see the GitHub version of my repository. And you know, I can click on the 10 commits. And I can see all of the commits that were made. Again, I could say add titles and format. And I could then click on that link. And again, see very much the same type of output that I saw in our studio to see the types of things that had changed from this and previous versions of the code. So if I come back to my commit history on GitHub, and go back to that add titles and format, and you'll see the greater than a less than sign. And if you hover over it, it's a browser repository at this point in the history. So I'll go ahead and click on that. So now this looks a lot like what I had when I initially opened up the repository on GitHub for the vaccination attitude repository. There's one important difference. And that's right here. What we see is the Shaw for that commit. I can click on that down arrow, and I can create a branch at this particular commit. And so what that branch will allow me to do is basically branch history, right? This is like Marty McFly, making, you know, basically falling in love with his future mom. That was a bit weird, wasn't it? And kind of wiping out his family, creating like a parallel track through history. So that's what we're going to do with a lot less incest. So we'll do highlight. And then we'll create branch highlight from 375 053 f click that. And now we have a branch called highlight. Very cool. And so we have two branches now we have highlight, and we have main. Right. So now if I go to main, I see all this. And if I go to highlight, it looks fairly similar, except that we now see that we don't have the more recent changes to our slope are that the last change to our slope are was 24 days ago on branch highlight, whereas on branch main, our slope are was modified seven days ago. So now we have two branches, we have main, which contains our labeled slope plot in the dark mode. And then we also have our highlight, which has our slope plot as it was way back when when we initially put on the titles and did some formatting of those titles. So back in our studio, I'm going to go ahead and click on pull to pull down the changes from GitHub. So we now see that there's a new branch highlight that points to origin highlight. So origin is my remote repository or the repository that's up on GitHub. So again, go ahead and close that. And again, just to show you that this is our slope are with you know the the anchor point that we can use to know that it's the most recent version on the main branch is this GG repel. So I can click on main now again main was my main branch. And I then see that I've got highlight and main on my remote on origin, right so I can click on highlight now. And now when we look at slope.r, we no longer have that GG repel, and we no longer have all that extra theming for the dark mode. And so we've gone back in time. Now, if I go back and click on the clock, again, it looks much more abbreviated instead of having 10 commits, only have five commits. And that we see that we the head of highlight, that's the position in the repository is at the status of add titles and format. If I click on highlight back up here and go to main, I then see that I still have create dark mode version of the slope plot up on main and origin main. But I can also see add titles and formats down here. Now what we have is a branch at origin highlights that we can then go off in a new direction to make modifications. So I want to do that just to demonstrate how the new branches will be created. To do that, I'm going to change my family Roboto Roboto to Montserrat. That was actually something I changed in a later episode. So we'll do Mont Serrat. And because I can never spell that right. On the first try, I'll go ahead and copy and paste and put in the capital M. And we can then also down here in our theme. I'm going to do text equals element text family equals Mont Serrat. And add a plus to the comma to that. And then one other thing that a commenter pointed out is that I misspelled percent for my y axis. So I'll go ahead and put an R in there. And so now we see that we have that original version of the slope plot with the 15 countries and the 15 different colors. Don't worry, we're going to take it forward in a few episodes. And I've correctly spelled percent this time, and that it's clear we do have that Mont Serrat font. So let's go ahead and commit these changes. And we will then write a commit message, or I'll say, fix spelling of percent and use Mont Serrat instead of Roboto. Okay, so we'll commit that. And it says that our branch is ahead of origin highlight by one commit. And I see that origin highlight. So that's the remote branch is still at add titles and format, but the local is at fix spelling, right? Good. So then we can come back to all branches. Again, origin highlight is back at add titles and format. My local version of highlight is one commit ahead, right? So there's one dot connecting this dark blue to appear at the top. I'm sure there's technical jargon for what these things are called, but I think you know what I mean. And then you can also see there's a second branch for the main, right? And so I can go and click on that. And I can again see what things looked like there. Again, by having multiple branches, I can have each branch effectively represent a different data visualization experiment. I have one branch for the dark mode. I'll have another branch for a highlighting approach. Down the road, I might make another approach for an interactive visual. And so this gets me thinking about, you know, past history, you can of course see that I have a number of our scripts in here. So I have the ipsos, the chart are in the makeover version in addition to the slope are so these three versions if you watch those old episodes are all kind of versions of the same figure, right? And they're all dumbbell charts. The ipsos was the original the chart are was a more stylized version and the makeover was my attempt to improve on both of them. So you can imagine these being three branches or perhaps three stop points along the same branch. But because we didn't have things under version control, we couldn't create that branch like structure. And so what I want you to avoid is having a separate version of a file for different experiments. Again, these branches you can think of as representing experiments along the way of developing your code play with this with your own projects, think about how you can use that timeline to structure and organize these parallel histories. And know that this is really one of the great strengths of version control that really doesn't get enough attention when we talk about the value of using version control. So much of what we do in science, we think of as being a linear process, right? So when you're working at a bench, it was linear linear protocol that you're doing. But when things come to working on a computer and doing data science, we do a lot of different experiments make lots of different figures. Some of them are good. Some of them we just want to ignore, right? And it's not a linear process that it's much more of a tree. It's much more of a bush, if you will. And to create that bush of different data analysis, we can use branches and we can go back in history to different points to then fork off or to, that's a loaded term in version control, but to branch off a new approach to looking at that data. And hopefully, we were able to do that in a fairly succinct way, showing how we can do all of that within our studio and leveraging the great resources at GitHub. Again, you can do the same things from the command line. I always forget the message that, again, you can do the same steps from the command line. I always forget those commands and end up Googling anyway. I found this to be really intuitive and something that I will remember how to do going into the future. Again, we can go into GitHub. We can find the commit we want. We can create a branch at that commit. And then we can then pull that down here in our studio and we're good to go without having to worry about all these funky different command line arguments that you'll never remember because you use them like three times a year. Anyway, practice with this and we'll see you next time for another episode of Code Club when we go off on our new highlight branch.