[00:00:07] All right. So welcome to the get her presentation. My name is Ben Nicolas. And today we are going to be going over basically a walk through an understanding of get up and how we create repose. And as the space keys on get up and discussing rebasing upstream Roback and finally I'm going to take questions in the very end. So if you want to post those into the chat that's perfectly fine and then I'll answer them at the end. So like I said this is what we're going to be discussing today. And we're going to go into the next slide. So what is good actually. All right. So get up originally named logical awesome LLC. It has over 20 million users and it has over 57 million repositories which are now considered the largest source growth in the world. On this slide I'm going to show you a basic breakdown of my own good hop. I created this one and this is from scratch so you're going to see what I've created altogether. Let's go on to the next one. So I have selected two taps that we're going to go over today. The overview and the repos are repositories like their label they're on the tab. The overview tab will show all of your pin repositories your contributions commits pushes emerges and all other activity and it's going to show them in a list form with the date. Now your repositories. We're going to be Schutte. We're going to be discussing that in the next slide. So let's go ahead. [00:02:06][118.8]
[00:02:07] This is going to I'm going to basically walk you through on how to create a repository. So first you would go up to little plus sign right here and it's going to drop down you're going to click on new repository. Now when use my Varty fill this blank this box in right here. But when you obviously cruet when you click new you're going to have to type something in there. Now it does not have to match the name of your project. You can name it whatever you would like. Let me give you a little a little rundown of what a repository is really quick a repository is best easiest described as a project folder a repository contains all project files and all the documentation in a sorceries file with a history. All right so we're going to go on to the next one. So after clicking the create repository you'll come up with this string now. I have selected the TTP s now the heg P.S.. This allows you to push all your code to get up without. Have with having to type in your username and your password. Now the S S H if you have that select. This is this is where you'd have to set up a key and we will go over that in the next slide. So there we go. If you decide not to use Baishi method we can use that as a Saich key and it will basically create a better connection for it hub and s and your project. So first what we're going to do is I'm going to go to the next slide and this is how you're going to set up your s Shk. [00:04:15][128.4]
[00:04:16] First you'll click on your profile. And you click on settings. Next you click on the S S H in GP G. Now I have already set up my SS key but yours will be empty so you'll have to click new SS HQ ta when you do that you'll come to this blank screen here. Now you'll need to switch over to your terminal and I've provided all the instructions on how to generate your Shk. First you will run the SS HQ generator you'll put your e-mail address that's affiliated with your GitHub. It will ask you about a past for it. You do not have to include a passphrase if you want better security on your good hub and or your s s h key in your project and you get up if you would like better security. You can provide a passphrase if you do not wish to provide one. Just go and press enter twice because it's going to confirm that you do not want to put anything in there and then simply add the at the next command which is s s h at for the next command after that you're going for nanobots users now users. This is Linux users. You'll run the cat and with the RSA public key which will copy and paste it's the code directly to the terminal. Now for Mac and OS X users you are going to use clip. Now I want to briefly give a run. The difference between you know nano box and OSX. If you're searching anything I just want to give you a quick rundown for Lenox for nano box users. [00:06:12][116.1]
[00:06:13] You can use Linux based searches in Google because narrow box is a linux base for Mac obviously use the searches for OS X so let's go to the next screen and after you set everything up and you push your first code. This is why. This is what you're going to see. Your code will pop up and generate you'll populate into get up. Now I have given you an idea of what you'll see when you run those commands. Someone's Mike is going. But that's okay. After an narrow box I said I ran all those commands and these. This is what your terminal should look like after running this commands. Now OSX operators when you run the previous command at the bottom here clip your terminal will not pop up and populate a code like mine does. Here now I have blurred my now and yours. You'll just have to go into the space that you provide your key and just pasted it. Now that we've created our story some other issues that will probably run into we're going to start with discussing ranche conflicts commits and errors so before we get to that I need you to understand. What upstream and downstream does. OK let's say your downstream. When you copy clone check out etc from the repository the information is flowing downstream to you when you make changes you usually want to send them back upstream. So they make it into the repository so the everyone hauling the same source code is working with all the same changes. Now sometimes. Now one of my friends is a developer gave me this really good analogy behind this. So I wanted to put it in here. [00:08:40][146.7]
[00:08:40] So he said sometimes you read about a package or release managers the people not the tool talking about submitting changes to upstream that usually means they had to adjust the original sources so they could create a package for the system for the system because they don't want to keep making those changes so if they send them upstream the original source to the original source. They shouldn't have to deal with the same issues in the next release so that's similar to what I just explained about the downstream and upstream. Now when you are setting when you are first using an upstream you have to set it up. You have to set up a remote upstream. When a repots cloned it has a difficult it has a default case may remote called origin that points to your fork on get. Not the original repo. It was forked from to keep track of the original repo. You need to add another remote named upstream and by using this command that I've posted here you will create the you will use upstream to fetch from the original repo in order to keep your local copy copy in sync with the project you want to contribute to. You'll run get fetch upstream get fetch alone would fetch from the original by default. So you will use the origin to Paul impish since you can contribute to your own Repa and I posted those comments there again without parameters. Origin is used by default. You will contribute back to the upstream repo by making a pull request that's Gaunt's. The next slide. [00:10:31][110.8]
[00:10:37] This is an important string and I think this is one of the most important screens you always want to make sure you're on the correct branch before pushing up to get up. You do this by typing in the terminal or your console get branch which will tell you what branch it currently working on. Now I've created this list here of the commands that you need to use to push to get up to get status which shows all the files being changed get ad says the files that you'll be pushing up get commit you're committing the files at this point and to your to get whup or local or on get up and get push you'd never want to forget this command and I'm going explain why in the next slide. When you forget to push you get up and you're working on multiple branches. If you try to push on a branch that is behind or ahead you'll get an error that says that your current branch is either ahead or behind the master so to fix these problems. Which is it. It happens a lot and I understand some bus will get through it to fix these problems. If you're ahead a simple way that I've figured out is to run get that Origin which fetches the updates made to the repository then simply run get merge Wirch and branch which merges the updates made on your local work you can do both of those in one command by running get pole origin branch which graphs in updates and merges them with your local work and one command. A lot of people are wondering what it fetch is. I have put it in the KeyBank here but I will read it for you. [00:12:38][120.7]
[00:12:39] Get fetch can fetch from either a single named repository or your l. And when no remote is specified by default the origin remote will be used unless there's an upstream branch configured for the current branch. Now here's another command I want to discuss the command get reset hard head to right here this command will reset your application to commits back. It will also reset the changes from the two commits from the working directory. So if you have some. This is basically a rollback feature if you want to just rollback to the recent commit. You can select either 2 or 1 or 3 however many commits back. You can run this command now if your code is behind the master not ahead but behind. Another way to fix this. Now I notice that this is this is not the best practice when you have multiple users but if you're on your own application this works perfectly fine. So first you want to. This is one might fix it. And this is if you're in multiple branches you want to run get Stasch on the one that is behind on the branch that you're on that's behind the master. You want to rent gets stash which stashes all the changes you've made. Basically you've made basically temporarily hiding the code. Then you want to run get check out of that branch of ours you want to run get check out of the branch you want to go into commit that code on that branch and will end or roll it back like the command I posted here. Then run get check out to the branch that you stash and then you can commit and push the cup. [00:14:37][118.5]
[00:14:39] Again this is not best practice for if you have multiple users it will cause way more common errors and you'll be going through what we're about to talk about rebasing. So when you have many people working on a project all at once poor ques may get lost or stale. And what I mean by Steyl is that one part is no longer up to date with the main line in development. It needs to be updated before it can be merged into the project. This can happen easily if two or more people are working on similar areas in the same file and one gets merged the merge will now have a serious conflict. You also get conflicts when the branch was created when someone had accidentally merged failing test to the master branch. Whatever the reason may be the request went stale. So what you have to do is what we call rebase notice and object 1 It has four commits on the master branch each having their very own ID a b c d and d being the current head of the master branch. An object 2 we have two branches a master branch and a branch labelled my branch. Notice that both branches contain commits of of a and b but they separate but they separate at B. The master containing C D while my branch contains E and F now whereas the base currently you may ask that is where the letter B is right here. The merge base is what we call that with my branch being based on the previous version of the master. [00:16:44][125.2]
[00:16:45] Now let's say my branch goes stale like we discussed and you want to bring it up to date the latest version of the master. Otherwise put my branch nice contained C and D you could do a merge but that would cause bad merge commits ultimately making the request more difficult. So what do we do. We rebase that's right. I know everybody was saying it when rebasing it finds the base of your branch again for us and this example is the finds all the commits between that base and the head in F and replace those commits on the head of the branch. You're rebasing onto in this case the master what it actually is doing is creating all new commits representing what your changes look like on top of the master looking at object 3 right here it is each with a hyphen an effort hyphen. Now don't worry if something were to go horribly wrong you can always go back to the way that they used to be. Because the normal E and F were completely left alone. They're still there when you rebase it simply moves the branch label to the new commits created looking back at object 3. Right here my branches no longer pointing at the normal F but at the but pointing at the F with a hyphen. Right here. [00:18:17][91.7]
[00:18:20] You'll notice that there is not a direct path from F to F with a hyphen from the point of view of everyone else of anyone else watching my branch history has suddenly changed in effect CND have been injected into my Brachet history as if they had already been there the entire time unlike most version control systems get allows you to change the history of your project but it is very cautious about letting you do so will come back to this at a later point. I wanted the commands for rebasing okay are right here okay we're gonna run get fach and you're going to put the name the project then you're going to run get Mirch base my branch which is here once you run that you're going to get a commit. Hash then you'll put the new front gate rebase with the hash located in here you will take out the money sign and hash afterwards. So for example if your merge base was ABC 23 like I said here the code that you would run the command that you run is get rebase ABC 1 2 3. Now there's one more thing I want to discuss on this page. It's called squashing or squash. This step is not always necessary but as required when your commit history is full of small unimportant commits involves taking all the commits you've made on your branch and squashing all of them into one larger commit. Doing this makes it easier for you to resolve conflicts while performing the rebase and easier to review your bold request. So this is what you'll see when your swashing basically this up here will turn to this. This is the commands that you're going to get from doing the rebase and this is what it will look like with the hyphenated hyphenated and ABC or ABC right here. Okay but to run the rebase okay once you run these commands now you'll need to run get rebase your name in the master. It will now start going through your commits. [00:20:56][156.1]
[00:20:57] You may get conflicts along the way so what you'll have to do is resolve them by running get status to see the files that are in conflict. Edit the files to resolve the conflicts then use get add to LDK conflicts that have been resolved. Now instead of running get commit we now want to run. Get rebase continue because you've already started the rebase allowing the process to continue. Note Here's the note if you have a squash your commits before this step you only have to resolve the commits once. If you didn't you may have to fix the commits multiple times. Now pushing after you've done the rebase in the squash is going to be a lot different with rebasing you are changing the history of your whole branch. You will now be able to run get Khush but you'll have to run it differently. You'll have to run gate config global push default with simple. You cannot forget simple to make sure it allows the new command below. Once the command is performed you can now run. You can now run push using get push force and that's what the dash F means. So lets move on. Okay then. Okay. Now lastly I wanted to include on here a final get she and this is a cheat sheet basically of all the commands that are most of the commands I should say that you can use for get her and I put the stashing up at the very top as we were discussing that and reverting over here which was which we talked about. This was the presentation of Get Up. Was there any questions from anyone. [00:20:57][0.0]
[1233.0]