 Hi there, and welcome back. Hopefully you've been able to recover from the last tutorial on using Make to automate our workflow. It was a lot of work. I really was serious when I said that Make is a central tool for me to make my analyses automated and more reproducible. By the end of the last tutorial, we had effectively written a program to generate a paper from a pretty minimalist directory that we had pulled down from GitHub. We saw a few things in those exercises. First, even though I'd done my best to make things reproducible, there were still weird things that happened that had a subtle effect on downstream files that weren't perfectly reproducible. The things were pretty close, but they weren't dead on. We saw this in the effects of using the random number generator in our camera checking. Second, the mentality of make clean make is very powerful and is a great check to ensure that our work is reproducible and that we have all of our dependencies accounted for. We saw this when we were able to find a few bugs in our make code that we thought had been addressed before we torched our project. Finally, in looking at the 538 data, we saw a value in reproducing others analysis and then going a step beyond to answer our own questions. I'm still pretty surprised by the recent rise in the number of simons in the United States. I can also see now that the ability to predict one's age from a name is pretty limited. These are all insights that I would not have gotten from the original article. For the rest of the day, my head was swimming with all sorts of ways that I could riff on the analysis in the original 538 article. Today we'll be discussing an approach to file away all those ideas and methodically work through them. The approach is called get flow and it's commonly used by software developers to add features to programs. Like get and make, we'll adapt get flow to work for a data analysis approach. I find it to be tremendously useful for documenting decisions that I've made along the development of my analysis plan and for organizing my approach to developing these workflows. The topic of today's tutorial is how we can use get flow to collaborate with ourselves. We'll find this approach is also useful in the next tutorial when we discuss how to use reproducibility tools to collaborate with others. Join me now in opening the slides for today's tutorial, which you can find within the reproducible research tutorial series at the riffamonus.org website. As we've done with each of these tutorials, I'm going to start with a brief pop quiz to see if you can remember some of the things we've talked about in previous tutorials. So the question I have is, what is the make command that we would enter to compile the entire project that we're working on from the Kozich analysis? The follow-up then is, would we always want to run that command when we're working in that project? So think about it for a minute or two. Press pause and then we'll come back and I'll give you my thoughts. So the command is make write dot paper. That was the final rule that pulls together all the PDFs and all the figures and everything and make sure that all of our manuscript files are generated that we might want to use to share with collaborators or for submission to a journal. But it might be preferred to make on another target if you're only interested in generating one of those intermediary files. So sometimes I'll do this as I'm building my analysis. So like I said at the end of the last tutorial, I generally don't have a write dot paper rule until the very end. I suppose I could have that earlier, but usually I'm building my make file more organically one rule at a time. Alternatively, if we get to the end and there's some special visualization that I want to make for not including a paper but perhaps something different to have on a website or to have on a PowerPoint deck, I'll make that image separate. And that'll be a separate rule that might not be part of write dot paper. And so I'll want to build that target. Also recall that it's useful to use make-n on the target to see what commands are going to be run to generate your target. This helps identify a lot of problems that might come up. As we saw yesterday, it'll help identify circular dependencies. It'll help us to see whether or not we accidentally bumped something in our code that's going to start from the beginning again that we might want to deal with that. So these are really useful tools. And again, make is just a great tool for automating our analyses and really making them reproducible. So the goals for today are to learn how to traverse the repository's history and the history of a specific file. We're going to learn about something I talked about in my introductory remarks of GitFlow and how we can use the GitFlow workflow to manage a project. And we're going to use this by integrating with GitHub's issue tracker to direct the flow of a project. And then we're going to experience how to create, work on, and merge branches, which is again part of GitFlow. And whenever you deal with branches invariably, you're going to run into conflicts where two branches don't play well with each other when you have to merge them. And so you have to then resolve those conflicts. You can think of a conflict as kind of being like when you're working on one manuscript draft and a collaborator is working on another manuscript draft, and you then try to bring them together. You can imagine there might be one sentence that you each modify in a different way. That's a conflict. So you're working on your project, and you give your manuscript to your PI with your figures. They look at it, and they notice a small but pretty important bug that you might recall that this image we generated is an NMDS figure. Yet our access labels say PCOA. And so they would like you to fix that to be NMDS access1 and NMDS access2. So we might ask which file contains this image and what file has the R code to generate that image. So far, we've only generated one image file that NMDSplot.png, I think, and I think we also had a file that was like buildNMDS.R. So I'm going to leave the slide deck here, and we're going to go ahead and log into Amazon. We're into Amazon, and I'm going to CD into Kozic. And I don't remember the specific names of my files, but if I go LSCode, I see that I have in here PlotNMDS.R. I also have Generate Figure 4. I'm not sure what that is. So I'm going to open that up. Nano, Generate, code, Generate, Figure 4, seems to be nothing. So I'm going to remove that. So you get RM, code, Generate, Figure 4. You may or may not have that in yours. This might be something I was just messing around with. And I'll do Get Status, Get Commit, Remove, Mysterious, File. All right, Get Status, LSCode. So I'd like to look at the history of PlotNMDS.R. I can do this in my GitHub repository, but I can also do it from the command line here. So we've already seen a command called GetLog, which tells us the history of all of our commits. So we can say GetLog. We can say GetLog, and we see the history of our entire repository. But this doesn't tell us the history of an individual file. To get the history of the individual file, we can type GetLog, code, PlotNMDS.R. And we see that there was one commit. So this bug has always been there. At least when I was making it, I created it on March 19th. So again, that bug has always been with us. So how would we go about fixing this? I don't want you to fix it, but what would we do? You can imagine that we could edit and save code, PlotNMDS.R. We could rerun, make, write.paper, get add, get commit, get push. And so that's kind of the way that we've already developed. And so this is where we're going to deviate slightly and use this as an example to talk about GetFlow. So this way of going in, editing the file, changing it, saving it, running make, write, paper, and then committing those changes, that works in pretty simple cases. But perhaps we want to try something out, and we're not totally clear whether it will work out. You know, I meet with my trainees, postdocs, and students, and I frequently give them harebrained ideas that I just say, just humor me, give it a shot. So I don't want them necessarily to have that be part of the center or the central thread of their repository. I want them to kind of go off on a branch, go off on a wild goose chase, so to speak, and try something out. And if that works, then we'll merge it back in. And so the approach we've been taking assumes that our analyses are a linear process, right? We start with data, and we end with paper. And that is a line. There is no deviation from there. And so that's what we have in this blue line here, this series of arrows where it's kind of you're marching towards a manuscript. But in reality, what we have is something a little bit more like this, perhaps even a little more convoluted than this, where we try something out. We pursue it. At the same time, we try something else in parallel. But that might end up in a dead end. And many times there are forks, where we go in different directions, different paths, different branches. I've heard science describe not so much as a linear process, but much more bush-like, where there might be branches that we cut off because it just isn't progressing anywhere. And so GitFlow works really nicely with the way that science really is, which is bush-like. For example, there are two sets of FASTQ files that we could have started this analysis with. We could create a branch, so to speak. We haven't talked about how we do that yet, but we could create a branch using one set versus another. And then we could compare the branches. And then we decided which set of files we wanted to use. We could use that branch and merge that into our master branch and then just leave the other one there to sit. Alternatively, we could have chosen to use PCOA rather than an MDS to generate our ordination diagram. That could be another branch. And then comparing the results of PCOA to an MDS, we could compare those. And because we have the branches and we have the commit histories, we would have a record of how that experiment went and why we decided to use one over the other. So the GitFlow workflow is a way, like I've been saying, to incorporate this bush-type of structure that we see in our analyses. And again, like I said in my introductory remarks, GitFlow is developed for software engineering where many members of a team are working to develop different features for a future version of the software and they wanna control how the different features are folded back into the next version. So you can imagine if you've got a team of five people working on a program, they're not all working on the same parts, but they're maybe working on five different parts until they each have a different branch, as I've been saying. And then what GitFlow allows them to do is to merge those branches back in in a more coordinated way. So this isn't exactly what we're doing with our bush-like analysis, but it's pretty close. So by making an analogy between software development and data analysis, can you think of some of the examples where it'd be advantageous to use the GitFlow workflow? So some possible examples that I can think of are, again, as I mentioned, if you've got collaborators that are editing the manuscript with you while you work on further analysis, right? You don't wanna just stop your momentum. You wanna perhaps give a manuscript or give images to a collaborator to look at and give you feedback on. Perhaps somebody else is developing code and you're gonna merge those back together into the main branch, the master branch. Alternatively, like I was saying, you and a colleague might be working in parallel on the same project. You might be working on, say, 16S sequence analysis. They might be working on a culturing component and you wanna have two branches that you're eventually gonna merge together. And as I've been saying, we might wanna experiment with different data analysis paths. Do I use PCOA or NMDS? Do I use a parametric or non-parametric test? Do I try this new method of looking for correlations between different taxa? You know, the list is limitless. So the general GitFlow approach, to get a bit more specific than we've already been, is to create an issue in GitHub to then claim that issue so others know you are working on it. Obviously, if you're the only one working on it, it's yours, to create a branch separate from master to then move to that new branch. To make the modifications needed to resolve the issue, commit changes to the branch and then merge that branch back into the master branch. So there's a lot of jargon here and there's things in this list that you haven't seen before, but that's what we're gonna be doing right now. We're gonna work through these different steps of how we can use GitFlow to make this relatively simple change of modifying our access labels. I'm gonna go to our GitHub repository. So GitHub, mine's at pshloss, cosetree analysis. Let me make this window a bit bigger. And what you'll notice across the top here is that there's a button right next to code for issues. At this point, we don't have any issues, so I'm gonna go ahead and click the green button for new issue. I'm gonna then add a title to my issue, which I'm going to say access labels on ordination are incorrect, and then I can come down and leave a comment. And I can say we noticed that the labels on the NMDS file have PCOA rather than NMDS. We confirmed that the data really are from running NMDS in mother and are not PCOA data. So again, the nice thing about this issue tracker in GitHub is that I can add markdown to represent that as a command, so that way then submit the new issue. It's rendered in markdown, and so we can now see my comment is here. And again, if this was something more significant, there are ways to tag other people to say, hey PI or hey students, come check out this issue tracker and give me some feedback. So the next step when we talk about claiming it, we can then claim it by assigning people so I can click on this gear, and I can add me. And so now it's assigned to me. And we also see that the issue tracker has been updated to say that Pishlaw self-assigned this just now. We can also assign different labels or projects or milestones, again, to add documentation to this issue. If there's perhaps 10 different issues, we might not want to have to worry about all those issues at once. You might create different milestones. We might have different deadlines where I wanna get these figures done before the microbe conference. I wanna get these milestones, these things done for this milestone of my committee meeting and so forth. So this is issue one, as you can see by the one there. And so we're gonna go now back to Amazon, clear that screen, and we're gonna create a branch. We could call the branch many things. One option would be to call it, say the branch is issue one, or we could call the branch fix ordination label. We can see the existing branches by doing get branch. And we see that there's one branch, which is master, and the star indicates that we are currently on that branch. Also, when we do get status, it tells us on branch master. We're going to create a new branch by doing get checkout dash b issue underscore zero zero one. The reason I like to use the issue number is because I can more easily link it back to my issue tracker on GitHub. If I were to call it fix ordination label, I don't know what issue that is. That would be hard to track down. So the downside though is that issue one, it's not very descriptive. It tells us now that we switched to a new branch issue one. If we do get branch, we see now that there are two branches issue one and master and that issue one is in green with a star indicating that we're on that branch. Similarly, if we do get status, we see that we're on branch issue one, nothing to commit working directory clean. So now we want to go in and we want to edit our NMDS R script. So we do nano code plot NMDS dot R. And I'm going to scroll down here. And I see that I have PCOA access one. I'm going to change that to NMDS access one. And I'm going to change this to NMDS access two. Save and quit out. I do get status. And I see that I've got one modified file, but those changes haven't been incorporated. So I'm going to do make write dot paper. And I'm going to do make dash N write dot paper just to make sure I see that it's going to run the code to generate the plot. And then it's also going to generate the manuscript output files. So I'm going to do make write dot paper. Runs the R code. It runs the rendering to generate the manuscript files. And it's done. So I should go into file Zilla and make sure that make sure that the changes took. So I need to get my IP address from over here and I'll connect. And I see the output now has NMDS access two and NMDS access one. So our changes have taken. So now we're ready to commit our changes. If we do get status, we see that our R code has been modified. Our manuscript and our figure file have been modified. And we will now do get add code plot NMDS dot R. Results, figures, NMDS, submission, manuscript dot PDF. Get status, those are the good. And so I'm now going to do something a little bit different from what we've been doing. I'm going to do get commit. And it's going to open up, it's going to open up my text editor because I'm going to give it a more sophisticated commit message. I'm going to give it the subject of correct access labels in ordination diagram. And then I'm going to insert extra space after the subject. And I'm going to say this fix replaces PCOA with NMDS on the access labels. And then I'll say closes number one. So with the really nice integrations with GitHub, putting closes number one or referencing number one in my commit message, when this is finally pushed up to GitHub, we'll integrate across to my issue tracker. So I'm going to save this and block out, get status, life is good, nothing to commit, working directory clean. So let's see where we're at. If I do get log, I see that I've got the commit message we just made as well as the commit I made back on master when I removed that mysterious file as well as the previous things we did from our make file. So the next thing we want to do is we want to merge these changes to our master branch. And so we're going to now want to check out our master branch. So we'll go to get check out master. And it says switch to branch master. Your branch is ahead of origin master by one commit. So that is the origin master is the branch, if you will, that's on GitHub. If we do get branch, we see that there's still two branches, issue one and master and that we are on issue master. And if I want to fold this branch issue one into master, I can now do get merge issue underscore 001, the name of the branch I want to merge into the branch I'm currently on. I hit enter and I see that it's bringing over my changes to plot and mds.r, my PNG file and my PDF. And again, I'm on branch master. And if I do get log, I see that it has brought in that commit that I made. I'm not interested in keeping around that issue one branch because I don't need it. It was pretty small. But again, it was nice to have that branch because if something had gone horribly wrong or if it was something bigger that was gonna take more time, then I'm not committed to having those changes on my master branch. I can decide to move them in whenever, if ever, I decide to. So again, I do get branch. Gonna clear the screen and move that up. I see I have issue one and that I'm on master. I can do get branch-d issued underscores 001. And you might imagine that that minus d means delete. So we're gonna delete that branch. And if we do again get branch, we see that we have our master branch. Finally, we can do get push, enter our credentials. It's pushing those up. And if we then go to our issue tracker, we see that it was automatically updated. Pshloss closed this in this, which is the commit message just now. And so if we click on that, we can see the edits that I just made. Pretty cool. So if we come back, we now look at click on our issues tab. We now see that we have zero open issues and we have one closed issue. So this is pretty cool. We can use these issues not only to solve bugs or to make edits after the fact, but we could also use these issues to lay out kind of the path that we wanna take on our project. Perhaps we need to add code to download the raw files. Perhaps we need to download the code for mother. Each of these little steps we can define as an issue. And that way then we can make branches for individual issues and do those off of the master branch. And then once things are to a point where we like them, we can then fold those back into the master branch. Again, it allows us to work on multiple things at the same time. And it also gives us greater organization for how we're working through our project. So again, this was the general get flow workflow that we just went through. We created an issue in GitHub, issue one. We claimed that issue so others knew we were working on it. Again, I'm the only one working on this, but I can still assign it to myself. Back in Git on AWS, we created a branch so that issue underscore 001. We then checked out that branch. We made modifications on the branch. We committed our changes to the branch and then we merged that branch into the master branch. And then we finally pushed that up to GitHub. Rinse, repeat, kinda keep repeating this as I was saying to work through an analysis. So some people like I was saying develop their entire project this way. So each session of this tutorial over the past 11 or 12 tutorials could have been a different branch that was merged back into master. Of course, I didn't teach you Git until maybe session five or six. So it would have been difficult pedagogically to introduce that back on lesson one or two. Also, the issue tracker serves as a nice to-do list that you can check off as you go through your analysis. Related to this, sometimes your PI or collaborators might not understand what you're doing on Git or with these great reproducible research tools. So they can give you a list of comments or even they could be trained to go into the issue tracker and file a bunch of issues. Something that I've seen others do is you get your reviewer comments back on a manuscript and you make each comment a issue on GitHub. And that way then you can document your response to each reviewer comment as well as the changes you made for each of those reviewer comments. Again, this is a low barrier using these issue trackers to get your PI and collaborators to interact with your repository. Alternatively, like I said, you can do it for them, but we'll talk more about some of those issues in the next tutorial. So more issues. The PI wants us to change the color of the points and the ordination from black and white to orange and blue. We might also want to change the shape of the points to be squares instead of circles. So we're going to use GitHub issues to create two separate issues to address these and we'll create two branches issue two and issue three to address the issues separately. I'm gonna create a new issue and I'm gonna say change color of points on ordination. So change from, so PI wants points to be orange and blue instead of white and black. So we'll submit that new issue and we'll create another new issue to change shape of points in NMDS. We'll say PI wants us to use squares instead of circles in ordination and we'll submit that as an issue. And so again, I can assign myself and if I look at my other issue, I can assign that to myself. Great. So now we have these two issues, issues number two and three. I'm going to return to get. So I want to create issue two. So something to note is that previously we did get checkout dash B issue zero zero whatever, right? So something else we could do would be get branch issue zero zero two. Get status says I'm still in master but if I do get branch, I see I have two branches. So I haven't moved to issue two yet. So when we do that get checkout, it both creates the branch and moves us there. So we can do get checkout dash B or I can do get checkout issue underscore zero zero two. That underscore that dash B would create the branch for us. So now we're on issue two. And so here we want to change from white and black to orange and blue. So I will now do nano code plot NMDS. And down here, I will add, let's see. I need to add here colors as a vector and my colors for plot early. I'm going to make those orange colors for plot late. I'm going to make those blue. And so then in here in my plot, I can do colors equals call and legend. I'm going to do call equals C blue. We quit out of that. We can then do make write dot paper and I introduced some error. I think I forgot a parentheses somewhere. So do note and code plot NMDS.R And let's see, oh yeah. I forgot an extra parentheses here. And I'll do make write dot paper that runs through. Life is good. I'll go to my NMDS figure, open that. I see my legend got updated, but my plot didn't. So let's see, nano code plot NMDS.R and let's see, ah, I should have call equals colors and do make write dot paper. And I return to filezilla, open this up. And now I see I've got my orange and my blue points. Okay, so again, it was important to run make write dot paper to update things and make sure that I got things rendered properly. Great, I'm going to close that. And I will now do get status, get add code, plot NMDS, results, figures, NMDS figure, submission, manuscript dot PDF, get commit, get status, get commit. I will do change colors of plotting symbols. I will say changed from black and white to orange and blue. Closes number two. Save that back out. And then I will do get checkout master, right? So as we did before, we would now merge things in, but I want to show what happens with a conflict. So I'm going to go ahead and create a branch for issue three. So I will now do get checkout dash be issue underscore zero zero three, get status. I'm on issue three. I'll do nano code plot NMDS.R. So here I want to change my plotting symbol from circles to squares. And so I'm going to change these values here from 21 to 15, and I'll make zero this here. And so I also need to change my PCH to be zero and 15. I'll save that and back out. I'll then do make write dot paper. This goes through. I'll check with filezilla to see what the file looks like. And sure enough, I now have my squares. Great, so that worked. I will now do get status, get add code, plot results, figures, NMDS figures, submission, manuscript. I do get status, get commit, and I can now do change plotting symbol to squares, closes number three. So before we did this as a subject and a body, but also know that we can get that integration with the issue tracker, even if it's on the subject line. If it says closes number three, that will work. So we can quit, get status. We're on issue three. We're going to get checkout master to get back onto the master branch. We can then do get merge, issue, underscore zero zero two. This will fold back in issue two. We can then go ahead and do get merge, issue, underscore zero zero three. And it's complaining. So it's saying that there's a conflict in our PDF, our PNG, and our plot NMDS dot r file. So automatic merge failed, fix conflicts, and then commit the result. So we need to open up code plot NMDS dot r and then resolve the conflicts. So do nano, code plot NMDS dot r. And if we scroll down through our text, we see some funky text here. So we see here the series of less than characters followed by head, our text that we've just added, or part of the text that we added, where we had our color from issue two, and then we have equal signs, and then we have greater than signs and saying issue three. So head refers to the text and the code that's on master, whereas the stuff underneath the equal signs is the stuff that's in the issue three branch that we're trying to bring in. And so what we want is we want orange and blue squares. So we could imagine that we want to replace these two lines with these. So what we're going to do is we're going to remove that head. And if you hit control K twice, we'll delete both of those lines and we can scroll up, enter a line, and if you do control U, you'll uncut those. And so then I'm gonna get rid of these two lines and then we can get rid of these equal signs and greater than signs like we did get rid of the head. And if we come down here, we see that we also have a conflict, whereas again, the head is what's on the master branch, issue is what's on the branch that we're trying to merge in, which was the zero and the 15. And so we can resolve this conflict by changing this 21 and 19 into a zero and 15. And we can get rid of all this stuff from the conflict. Get rid of that. We save it, we quit out. We can then do make write.paper. We then look in filezilla at the new version of the file and voila, we have orange and blue squares. So we need to commit these changes and it says we have unmerged paths. So we're in the process of doing a merge. So both branches have a modified version of code plot and MDS results and submission file. So we're going to get add these, get add code plot and MDSR results, figures, MDS, submission, manuscript, get status. We see that all conflicts are fixed, but you are still merging. So get commit to conclude the merge, changes to be committed. These are the modified ones. So we'll then do get commit dash M resolve merge. Close quote, bring that in. If we look at get log, we see that we had our final commit of resolve merge, changing our plotting symbols to squares, changing our plot colors of our plotting symbols. Finally, we can get push. And if I refresh this, and now see I have three closed commits. And so change the point in MDS. This was closed in this commit. As was changing the color of the point on ordination. So I have to say that for the most part, as we saw previously, as we were bringing in issue one with the merge, get is really smart and able to figure out how to resolve those conflicts. But when we have a conflict that say occurs on the same line, that is going to cause problems. And that's when we need to manually go in and edit things. So in these cases, it really helps to think ahead about where there might be conflicts. And so this was again, a very silly example that perhaps we should have changed done issue two, maybe even do issue two and three together. That would be a solution. We could have off of master made a branch for issue two, changed that made a branch for issue three off of issue two, changed that and then merged that all back into master. But sometimes these conflicts are unavoidable. If you've got a fair amount of code and you've got different people working on things. Again, if you think of the use case of two or more people editing a manuscript, you're gonna get conflicts that arise. And sometimes these are just unavoidable. It's nice then that get will help us to resolve these differences. So two exercises, one of them I already did for us was to run make right dot paper on the final merge of the branches. So what I'd like you to do as an exercise is to create and resolve an issue that replaces the NMDS ordination with the PCOA ordination. So you'll make an issue in GitHub to replace NMDS with PCOA. You'll have to modify a few different files. You'll have to run make right dot paper to update all of that. So I'm gonna go into my issues and create a new issue and I'll say replace NMDS with PCOA making a PCOA plot. And they do have emoji built in if you didn't notice. We have more important things. So I will then come over into Kozic. I'll do get checkout dash B issue 004, get status. I will now look at my make file. And I'll make file and I'll scroll down. I'm gonna use a search to find NMDS and I'm gonna change this to PCOA ordination. And this is gonna change from NMDS dot axes to PCOA dot axes. And I'm gonna change this to get PCOA data batch. So I need to update this get PCOA data batch file. So let's do one thing at a time. So we'll go ahead and change that. We'll do get MV code, get NMDS data batch. And we're gonna rename that to get code, get PCOA data dot batch. And then we'll do nano code, get PCOA. And we're gonna change our NMDS to PCOA. We don't need this max dim equals two anymore. I'll save this and back out. So that works. So we'll go back to our make file. And so we've taken care of this rule. We now wanna construct a PCOA PNG file. And we're gonna change this to PCOA. We're gonna change our file name to plot PCOA. And plot PCOA. And this NMDS is gonna change to PCOA. So we need to now update code plot PCOA dot r. So we'll do get MV code plot NMDS dot r to code plot PCOA dot r. And then we're gonna do nano code. Plot PCOA dot r. And I'm gonna change all my NMDS's to PCOA's, all right. And we need to also change the name of our output file to be get MV results figures NMDS figure to results figures PCOA figure dot PNG. Let's go back to our make file. And I had forgotten to change this NMDS to a PCOA. And this to PCOA, and this to a PCOA. And this to a PCOA. So I think that's all the NMDS's. I wanna check into my manuscript or MD file to make sure I change those. So I do nano submission manuscript dot rMD. Let's look for NMDS. And I need to change this to PCOA. And you'll notice that before we had principle coordination of data YC values when we actually had NMDS. So anyway, so we'll save that back out. Just look at what we've all, what all we've changed. We've renamed some things, we've modified some things. We can then do make dash N write dot paper. And you'll see that we are going to run get PCOA data batch. We're gonna plot that. And then it's gonna feed that into rendering our RMD file. So we'll do make write dot paper. So that took a little while, but it eventually got there. So we're going to go into FileZilla. And let's look at, we'll have to do a refresh here, I think, and look at PCOA figure dot PNG. And that looks right. And so we can show this to our PI and see what they think if they like it or a collaborator, whoever. And I'm gonna leave this branch here. And I'm not gonna fold it in because, you know, you might take the image to your PI and you might take some papers that say, hey, NMDS actually does a better job of representing the data than a PCOA. So I'm not gonna use this branch. So if we do get status, I'm gonna go ahead and commit these changes to the branch, but I'm not gonna modify things. So I will then do get add make file code, get PCOA data branch code, plot PCOA results, figures, PCOA figure submission, manuscript, RMD. I'm gonna put a star in there. Good status, those are all there. Get commit dash M. And I will open up something bigger. So I'm gonna say these changes or convert NMDS to PCOA. So these changes replaced the code and text for an NMDS file with code for a PCOA. This addresses issue four. So we save that commit, get status, run issue four. I'm gonna go to, we did this, but the image really isn't as good as the NMDS. It is in branch issue zero to four if you wanna check out the results. And so we can close and comment that issue. All right, so again, we're just gonna let that branch sit. We're not gonna worry about it so much. So one thing though, if we look at our code is that we only have one branch here. To push this branch to GitHub, so to make sure we're on the right branch, issue four, we can do get push origin. So origin is GitHub and we're gonna say issue under square zero zero four. And this is now pushing our branch issue four up to GitHub. You could do this for all of your branches. Again, this is up to you for kind of how you wanna deal with those different issues. And so now it says we have recently pushed branch issue four. If I refresh my screen here, I now see I have issue four saved in here. So if I wanted to see results figures under issue four, I see the orange and blue squares with PCOA, but if I wanna see it under master, didn't like me doing that because, right, because we don't have a PCOA file. We have an NMDS file. So we have an NMDS figure, right? Great. And again, if we look at issues, we can look at the fourth one that we just closed and you'll see that there was a commit that was referenced here and see that commit message in our explanation for why we didn't wanna change it, okay? So again, this is using get flow and this issue of branches to document changes to our project and using the issue tracker to document decisions we made or didn't make in terms of folding things back into the master. So before we finish, we wanna go ahead and go back to our master branch, get checkout master, excellent. And again, we saw it on GitHub, but if we just wanna prove to ourselves that we still have our NMDS files, we can look at LS results figures and we see we've got our NMDS figure PNG file that we no longer have our PCOA file there. Excellent. So we're gonna go ahead and log out, exit, exit. And we're going to go ahead and stop this instance. The idea that I am my most important collaborator is a really profound way of thinking about how to improve the reproducibility of my work. In the recording of these videos, I actually had to take a month break in the midst of them to work on another project that had a hard deadline. Thanks to my documentation, commit messages and use of automation tools, I was able to pick things back up without losing too much rhythm. Under my old approach of, quote, remembering things, it would have taken me a few days to get back up to speed. Days that I just don't have. Lairing GitFlow on top of our tools gives us another layer of documentation to record the results of experiments that worked or didn't work along the way. The examples from this tutorial resulted in us merging our branches back into the master branch. But that wasn't required. We could have said, I don't really like that new color scheme and let the branch sit there. I could have added a comment to the issue for why I didn't like the new colors. Similarly, someone at a conference might ask a question that I could file as an issue. I could work on that question and decide it really doesn't move the project along. But in my issue tracker, commit messages in my branch history, I would have documentation to support an answer the next time the question was asked. I'll admit that the topics of branches is an advanced move and you may not feel completely comfortable with it. Give it a shot and see how it works for you. In the next tutorial, we'll be discussing tools we've been using to foster collaboration with others. We'll talk to you soon.