 Hey folks, this is Akash Deep, third and welcome to Fedora Classroom. In this session, we would be discussing about Git 101 with Pejo. So these are the topics that we would be talking about. We would start with version control systems and then we would move on to the reason behind using Git. From there on, we would go on talking about the version control hosting websites and have a brief introduction to Pejo before we go on to fully explore it. Finally, we would get to the fundamentals of Git. Every step performed here is in real time. I would go on demonstrating the stuff that I would be talking about, so feel free to pause the video anytime to get the tasks done correctly. Also, all the necessary links would be provided in the description for your reference. Let us now take two scenarios into consideration. In the first scenario, Ajay is expected to turn in a code snippet with the features he was assigned and believe me when I say it, it is a big code. There are a lot of changes that needs to be done, but with every modification that Ajay makes, there are features which are getting fixed, but there are features which are getting broken. So he backs up the code with names like project underscore test dot pi and projects underscore backup dot pi and whatnot and keeps on renaming them when it is needed. While in the second scenario, Mahit and Mohit are collaborating on the same code base together but cannot quite do it effectively as they cannot work on the same stuff simultaneously. Also, even if they were working on the separate files, they were left scratching their heads thinking why putting together their code did not work like it's expected. Sending code files and dependencies over the mail can be a headache with many mail providers not actually allowing them at all. If you have been in either of the aforementioned situations, believe me, you might have come across to realize that the way the codes are getting backed up and the way people are collaborating is all over the place. And if a version control is used, that can be a solution. Now talking about version control systems to beat a solution for problems like these, it helps you to seamlessly manage changes made to your code base, be it by anyone or at any file. You can handle concurrent additions made by multiple people on a single file quite easily. Go into tracking edits and checking up on the progressives made by the request features. You can also roll back in on internet changes made by the file with the ease when it is needed. If you want to experiment new features, you can do so with the helper branches. All in all, version control systems help you alleviate the issues you might come across when you try to collaborate while developing, making it your companion in building complex projects. Now that we have understood how version control systems can be of great help, let us move on to see the tools we can use for it. On your screen, you have a total of three most widely used version control tools displayed. Starting with Git, created by Linus Torvalds for handling the development of Linux kernel, it has now grown to be the most widely used version control system in development. Being distributive in nature, you can track changes made to your code pace and all of the metadata of changes made are stored in a single directory. This makes it an excellent option since network dependency is not an issue at all. Moving on to the Apache Subversion, or SVN as some people might like to call it. It is a software versioning and revision controlling system capable of keeping history of code, documentation, and web pages alike. It was created by CollabNet, incorporated to be a capable successor of the widely used CVS and is used in projects like ASF, Free Pascal, and Free BST. And finally, we have Mercurial. It is a distributed division control system just like Git, capable of robust handling of port plain text and binary files. It was written by Matt McCall, mostly in Python with some parts in C to be high performing, scalable, and decentralized. So why is it that we prefer Git the most and why not use something else? To answer that, let us look what Git is capable of. Git uses SHA compression for changes which make it pretty fast and robust. It can conveniently handle conflicts when the same file is worked upon by multiple people. If there is an experimental code, they can be easily tested out with the help of branches, which more or less creates a sandbox to protect an important code. As the commits are immutable in nature, you have the choice to roll back river changes at any point of time you want. And if there is any changes that you made in the code base that you want to fall back to. Keeping in mind just how popular Git is, you're highly likely to come across documentation on it like everywhere. There would always be fellow contributors around you willing to help you out with your questions and doubts. VCS hosting websites take your ability of code and collaboratively to a whole new level with the amount of ease and convenience it facilitates you. Forges like these allow you to track changes made by all of your fellow collaborators in the project from a web interface. You track issues, discuss about it, assign it to the people to manage features. If a project is open source, you can fork it to have your own copy of the repository where you can add your changes to your liking. And once you're done with those changes, even your part of the code is just one pull request away from being included in the main repository. VCS hosting websites do make it a lot easier to collaborate with people in the same code base, even if they're like thousands of miles apart by sharing a common remote repository. Talking about VCS hosting websites, you can see that there are three most popular VCS forges that are used by the developers across the globe. Let's start with GitHub. It is the most widely used Git forged by developers which was recently acquired by Microsoft in late 2018. Written completely in Ruby on Rails and LLang, it has size limitation on files and repository storage gap. Developers often frown on how limited they are when it comes to private repository, and many of its features in the private repository can only be availed on payment. Next up, we have GitLab. Now when it comes to the GitHub, it comes to a second in terms of popularity. Advertised as a DevOps lifecycle tool by GitLab Incorporated, it was written in Ruby on Rails, LLang, ViewJS, with many parts of it being ported to Go for speed. As compared to GitHub, it has loser limitations on files with much more advanced features like continuous integrations built right into it. Users can have unlimited number of private repositories. And lastly, we have BitBucket, which stands out from the list as it is the only VCS hosting website which has support for both Git and Mercurial. Acquired by Atlassian, in late 2011, the Git support was further flourished. BitBucket is entirely written in Python, with some parts of it built on the Django web framework, but has stringent limitation on a free account with OpenID. Like GitHub, private repositories in BitBucket also have limited features if you do not pay. Fedora Peture is Fedora's own VCS hosting website, or Git Forge as some might like to call it, with over 2,000 projects as of July 2020. This is a pie-git-to-paste, lightweight web interface built with and for open-source tools. But how exactly is it better than the other three VCS hosting websites that we just discussed about, and why should you use it? Let us find out. Peture is a fully free and open-source Git Forge for all the projects related to Fedora. Being lightweight, focused, and easy on resources, it comes as a package so you can also deploy it as your own instance on your own PC. Keeping in mind that there are over 2,000 projects related to Fedora, having it on some other VCS hosting website is truly a no-go, for it gives us the independence from the down times as they might face. Better yet, Peture also supports mirroring repositories which makes migrating from other VCS hosting websites like GitHub, GitLab, or BitPocket an easy task. Now that you're introduced to Peture, let's not wait up anymore and jump right into exploring it. But in order to fully able to do so, you need an FAS account, or Fedora Account Systems Account. Head over to the site, create an account to log in to begin. Take your time right now, pause the video if you're creating an account, and if you're done making it, you might wanna log in so we can proceed with the further steps. So these are the steps that we would follow in order to explore Peture. These are the things that we would primarily explore over here. Peture is a clean slate for you to explore, so keep in mind that this is just a starting point for there is turns to explore, and more to head to once you're done with this. Firstly, we'll start with logging into your newly created account of the Fedora Account System. Once we are in, we will generate an SSH key pair from our PC and then add it a public key to your account so you can clone your repository and push changes to it using SSH. Feel free to look about SSH if you're unaware about it. Then we will finally create our first repository in Peture. So if you have any browser, Firefox, or any other browser of your choice, feel free to open it up and hetero link which is listed over here. The link of it is also provided in the description. So over here, I have already created my account so I just need to log in. So once you've created your account and once you've clicked on the login button, just enter your credentials over here. So my credentials have already been entered and I'm just one login button click away from logging into my account. So it's listed over here that you have not submitted an SSH key. There are some resources up on Fedora which require an SSH key to be shared. So in order to do that, we first need to head to my account. Here is the place where all information regarding your account is listed. And in order to add an SSH key over here, we first need to generate it. And in order to do that, we'll open a prompt and type in SSH key gen dash t space RSA. So when we do it, it generates an RSA key pair for us. Now what exactly is RSA? RSA is an acronym for Rivas Shamir Erelemann. It's an asymmetric key cryptography scheme based on huge prime numbers created by Ron Rivas, Adi Shamir and Leonard Erelemann where there are two keys, one for encryption and the other for decryption. Feel free to look it up on any search engine if you want to know more about it. You can generate keys for SSH in not just RSA but also in any other encryption scheme. But due to the fact that RSA is one of the first and most widely used public cryptography schemes, we would want to stick to it for the scope of this class transition. For this command, as you must have seen, we have accepted the defaults for the scope of this classroom and this then generates an SSH key pair in the RSA scheme. Also, you get to see this fancy little random mark which is based on this key. Just keep track of where this id underscore RSA.pub is stored for where would be needing it to add SSH key to our account. Now just because this folder where it is stored starts with a dot, we can be pretty much sure that it's a hidden file. So let's open it up. In most of the popular file managers, you are just one control H key combination away from revealing or from hiding the hidden files. So press control H and you will see that all the hidden files which start mostly from dot are listed over here and this is where the dot SSH is. So we'll double click over here and then we finally see that a public key is over here. So we'll copy it and we'll paste it in some area where there is, where the directory is visible. So let's paste it over here. So for your convenience, you might want to bring things back to where they were. So if the files were hidden, you should hide them back by pressing control H back again. So now that the files are hidden, let's head back to the browser and in this account details, the public SSH key is the section where we need to add this and in order to add this, we need to click on the edit button near the account details. So click on it. In this section, you see that the public SSH key is asked for. So you just need to browse and locate your public key. So once it is located, click on the save button to save all your changes. So as you can see, the public key of SSH has been provided. We'll move on to the home. So now the to-do queue is empty, which means that SSH key has been successfully added. Let's move on to the next step that is to create our own first repository up on patcher. So in order to do that, we first need to log in. Insert your credentials over here and click on the login button. Now once you have logged in, you would see a dashboard consisting of all the projects that you have contributed to. But we are here to create our own repository, right? So click on the create link at the top right corner and then click on a new project from a dropdown like this. Add a project name to your liking while avoiding any kind of special characters and spaces while naming. Give it a description with some more details as per your preference, but do not forget to click on the create read me check box before clicking on the create as this is where we would practice our Git fundamentals. So let us name this project as Git 101 with patcher. We'll try to replace all the spaces with hyphens. And in the description, we'll name the same thing. We'll click on create read me and then we'll finally create a repository. Now this would take some time and create a repository for you, but when it's done, like it is done right now, it would get you to the dashboard of your repository. So now that the repository is created, we also need to add to SSH public key here. So head over to the settings menu now here, find the deploy keys and project settings. This is the section and you need to add a deploy key situated at the top right corner. You just need to click on it. So this is where we add SSH key. So head back to our terminal, go to the home where the SSH key is stored and type cat space id underscore rsa.pub. So this would display the contents of this SSH public key file and you can simply highlight this all, copy this, go back to the browser tab, paste it and also click on the push access just because you would be pushing a lot of commits using this SSH access. So click on it and click on add. So now that we have finished adding the deploy key over here, go back to the source section and we are done with the part of basics, exploring the basics of Pejo. So let's move on into some get fundamentals. As this is one of the most important things in this session, I have further divided this section into four parts for the convenience of the viewers. So if you are done with one part, feel free to take some break and then come back when you're ready for the next part. So in the first part, we would begin with installing get and all of its dependencies on Fedora. Then we would move on to initializing our own repository in the local drive where you can turn any project folder of your choice into a git repository. And then finally, for this part, we would clone an existing repository to create a local copy for it. So let's get started with the first part. So step one for installing git is to open up your terminal and then type in the command which is given here. I would not do so because I have already a version of git installed on my device, but once you're done installing it, just turn git version and press enter to check the version of the git which is currently installed on your device and also to confirm that git has successfully been installed. Let me type in git version and you can see that the version that I have installed is 2.27.0. Moving on, let us initialize a repository of our own. And in order to do that, you can simply navigate to the project folder, a directory of your choice and then open a terminal in that location. So let's just do that. So let us go into the projects directory. Let us make a directory of our own. Let's call it git basics. And once the folder has been created, what you can do is you just need to go inside that folder. So we'll CD into it and then we would initialize the repository. So this folder has now become a git repository. So what exactly has the change happened? Because when I'm listing the directories, nothing exactly is different. It was empty and it is empty right now. But if we show all the files, including those which are hidden, you would come to see that a hidden file called .git has been created. Let's move into it. You see that there are many files, many folders over here. These files are just efficient, just enough for tracking, storing and rolling back changes in this repository. And in most conditions, you would be accessing and making changes in this directory with the help of a git client. So I would really suggest not to make any changes in this directory from the outside until and unless it is really needed to. So we have fallen back to the projects directory. Let's move on to the next step and we would clone an existing repository of our own from Pejo. So we would be needed to head back to the browser and go to the dashboard of the newly created project. So let's do that. Once you're there, click on the clone button at the top right corner and copy the SSS clone URL. So this URL is the URL that we're looking for. So when you click on it, it is conveniently highlighted as a whole, so you just need to make a right click and copy it and then come back to the terminal and clone it. So what exactly do we need to do in order to clone it? So once you have copied the clone URL, you just need to type in git clone followed by the clone URL. So let's just do that. So if you're cloning a repository for the first time, it would ask you for the authenticity check of the given host. So you can simply answer that with a yes and all the contents from that repository would be cloned to your local store. So the repository has been completely cloned. We have a copy of git-101-width-pature in the local storage. So in order to make changes to it, we need to change our directory and get into it. So we'll do just that. And we see that the readme.md is listed over here. So now that we're done with the first part of Git fundamentals, we are moving on to the second part. And in this part, we would be talking about how you can stage files before committing them by adding the file. We would also learn about how you can commit to staged files and then we would get down into experimenting with our code with the help of branches by diverging our branches and converging them when the changes are complete. So let us begin with the second part. So in order to commit changes, you need to add them first. So they become staged. So right now we need to follow the step one. We have already been inside the project directory and the terminal is already open over there. So the only thing that you need to do is make changes and add your file name. So what you can do is you can go to the terminal, make some changes in the file. So right now I have this marked on document. So let me add, hello, I am learning Git basics. So once I made the changes in the file, I'll save it. And in order to stage the changes that I made so far, I will be typing Git space at space, read me dot empty. So this stages all the changes that you made so far and this change is ready for getting committed. If you want to stage changes in files like a lot of files and you don't want to list them all just because they are in recurring directories, then you can also do something like this. So what it would do is it would intuitively check through all the files and see in which files the changes have been reduced, which files are different than they were previously. And then it would stage them. So Git would intuitively skim through the files, list them all and then they would be ready for getting committed. And then finally that the files that we have staged, we need to commit them. So now that we have staged a change in read me dot MD, we are just one command away from committing that change. And that command is get space, commit space hyphen M space, any commit message that you would want to write. So let's just do that. So we have added a line. We'll just describe that commit message over here. So this change has been successfully committed to the branch that you're currently working on. Now this would commit the messages that you have staged with the message that you have provided, but it is quintessential to have concise commit messages as you know these messages kind of represent what work has taken place with that commit. Feel free to read more about how you can write good commit messages if it helps. Now we are at the part where we can experiment with our code. Now what if we wish to make an experimental change which has like a 50-50% of possibility of either making the code better than it was before or breaking the kind functionality. Should you really risk adding that code to your primary branch without checking? Get branches are an answer to that question. You can diverge a branch from a current primary and add your experimental code in it. In this way, you can get a totally safe sandbox to work on while keeping the existing primary branch totally safe. It sounds cool, right? So let's jump into discovering how exactly you can do that. So the step one would be listing all the branches that exist right now in your repository by typing in get branch hyphen hyphen all. So when we do that, we get to see that there is this local master which is the branch that we're currently making changes in. And then there are a couple of more branches like the head and the master from the remotes. You can figure out which branch you're currently working by seeing which branch has been highlighted in a green color followed by, you know, an asterisk in the prefix. As a rule of thumb, when you clone a Git repository, Git would automatically select the master branch to be the current working branch. You can, of course, create a new branch by doing the following operation by typing in get branch followed by the branch name. So let's just do that. So let's come up with a name. Let's call it a testing branch. So this has created a branch called testing branch. Now, whenever you're naming a branch, you might want to try to avoid branches, name of branches which have already been taken and any other special characters or spaces when thinking of a branch name. So now that the branch is created, we will again go into typing to list all the branches. We do that by typing in get branch all. And then we see that the testing branch is created. But even then, the master branch is still the branch that we are currently working on. Let us change that. Type in get space checkout space, the branch name that you have just created. So this switches your current working branch to the testing branch that we have just created. Here again, you would really want to avoid the branch names which do not exist at all. So if we are to list the branches again, we would see that now it is the testing branch which is highlighted in green color and has an asterisk as a prefix, which makes out that this is the branch that we're currently working on. Now in this new branch, let us make changes pertaining exclusively to this branch. So whenever the changes are made, we would go ahead and stage them to commit them. For this purpose of the session, I would create a new file and make changes to it. So let's do like that. Let's make a new file called test.md and write this as a test file. So you see that I've created a file called test.md and I have added a content to it. So let's, you know, stage the changes by typing in git add test.md. So this stages your changes and let's commit it as well. Added a test file. So this has committed the change to your branch. So let's go back into the master branch by checking it out. So do that, we'll type in git checkout master. And then you see that your branch is ahead of the origin master by one commit. Let's list in files present in a master. And then we see that the test.md is missing. Why is it so? Remember when I said that when the branches are like sandboxes, so any changes that you make inside a branch will stay there until you merge them, you review them and you bring it and converge with the master branch. This also keeps the primary branch safe. So should any branch have some kind of code which breaks features, you can always have a testing branch to test it rigorously to pan out all the bugs before merging it to master. The file that we added right now for this presentation is a harmless markdown document, which is not likely to make or break features. We can simply merge it after review. And how do we merge? So step six, it claims that you can merge by typing in git merge and the branch name. So right now we're in the master branch. So if we list the branches, we see that the master is highlighted in green. So if we are to merge the branch that we just created and made changes to, called the testing branch, we do so by typing in git merge testing branch. And then this would simply merge all the changes made in the testing branch to your currently working branch, which in our case is the master. So we're already halfway there. In this third part of the git fundamentals, we would be exploring some of the advanced features of git. We will start with uploading all the committed changes made in a local repository to the remote repository. Then we would learn about fetching changes and pulling changes and which one of, like, these are the things that are the most useful if you're collaboratively developing something with multiple contributors and those all contributors are kind of making changes in the same branch. We would also go on exploring about how fetching and pulling are different from each other. So let us begin with the third part. So we will continue with the clone repository here. So move into the terminal and type in git push, git space push. So let's see what it does. So as you can see, this has uploaded all the changes that you've made so far in your remote repository. So any changes that you made in your local repository is now replicated in the remote repository as well. So once it is done, we would now head to the project dashboard. So let's just do that and see the commits. So as you can see that the commits that we made using the terminal, the git CLI has been reflected over here. So we added a line, then we added a test file. Pushing all the changes to a remote repository also helps in backing up your code. I mean, if you look closely to the commits that you have made, let's look into the second commit that we made that is adding a line. So you see that the changes that you have made so far are having the original timestamp. So when they were made, so it is really not important when you push the changes. You can have all the changes in your local repository while making like hundreds of changes. You can push it after that. So the original timestamp will be retained for all the contributions. So moving on, let us discuss about how you can fetch changes from a remote. Now this is an extremely important feature when you and your fellow contributors are sharing the same branch. So any progress made in all the sites should stay synchronized. Fetching allows you to do just that but you can still decide if you want to create those changes to be a part of your local copy or not. One of the reasons why you would not want to do that is because you are not very sure if your changes can play well with those made by someone else. So in such cases if you merge the changes made by someone else to your branch, it might break your code as well. So that is something that is not all recommended if you are unsure about your code. So a pull request can be helpful in the other site where you are sure but at this time when you are not sure that the code is going to play well or not a fetch can be helpful. So I would not be demonstrating the fetch operation as the repository used for demonstration has only one contributor but as you may have come to realize fetching changes is as easy as doing the three steps listed here. It's just as going inside a git repository and typing in git space fetch and this would then fetch all the changes made in the remote to your local repository without actually affecting the branches that you are currently working on. The pull changes the pull operation part is slightly different from that of the fetch it kind of follows the steps of the fetch by getting all the changes from the remote repository but then it is followed by merging all the changes from the remote repository by the current branches the subsequent merge after fetching all the changes updates your local repository with the changes stored in the remote repository. Now this can be helpful in circumstances where you are sure that updating your local repository would not break any feature and any active collaboration is needed or there were a part of code of some other contributor access and input to your code in such situation pull operation is much more preferred. Now just like fetch operation this can be performed but as this is a documentation file we would be editing it using the editor that here provides you with. So suppose I go inside readme.md file let's say we just go inside a testmd file and using the editor provided here we will just end up editing it saying this is an edit would make changes in the master and we will just say that the commit is update test.md and we would be done with that. So now you can see that the commits made over here is most recent and in the remote repository but the same would not be reflected in the local repository as long as you don't merge it. So let's do that would type in get space pull and press enter. So let's list the branches So this would list all the branches and as we can see master is the branch that is currently checked out. So we would simply enter get pull This would give you a warning the warning that I already told you about that if you are making a change that cannot play well with those made by someone else you might not want to keep away from having a pull because it would merge and it would overwrite your changes to add this. So as you can see that we have received a file with two insertions the file has been changed so let's list the file and see what exactly has changed. So this is an edit the edit that we made in the remote side has been reflected over here with the help of a pull. So this is how the pull operations can be useful. So lo and behold we are finally at the final part of the get fundamentals. We would kind of cut some slack here and cover some easy topics. We would start from checking the current state of the get directory and explore what common issues you are likely to face when working with get. As we are barely just scratching the surface by discussing just enough to get you quickly started with get and patcher we would be talking about the places where you can get some more information about these. So let's get started with the fourth and final part of get fundamentals. So checking the status of get project directory and that of the staging area can be useful in many ways. You can see that the changes that you have made done so far and which of those changes have not been staged and those changes which have been staged but not committed and finally those changes which have been committed and not been pushed. That you also get to know about the status of the current working branch put to comparison with the branch available in the remote. So in order to check the status all we need to do is type in get state status and press enter. So let's just do that. We would clear the screen type in get status so it prints the status of the repository and more specifically the current working branch which in our case is master. So let's face it get can be an easy thing to start with but keeping in mind how complex situations it can handle you might come across a lot of issues while using it. Here I have listed some of the common issues that people mostly face when starting off with get. One of the most common issues is when people can clone a repository just because it's open but cannot push changes to it. It might happen when the repository does not belong to you. So in order to make changes you first need to make a fork of it and then push changes to your fork. Secondly your repository might be cluttered with time with many dependencies getting committed all together with the code when you could have just added it as a list of requirements. You can avoid such situations by explicitly listing the files you want by saying that git should ignore some files. Now how do you do that? In order to do that you can list all the files in a .git ignore file. Feel free to look up about it if you want to know more about it. Finally people face a lot of issues when they try to make unreviewed changes to the master branch which actually ends up breaking their code. Do not do that. I mean I really mean it. Do not do that. Do not directly commit to the master. Making commits to a branch first and then reviewing it relentlessly and then finally pushing into the master is one of the good practices that you should follow while using it. Merge only those changes to master when you have reviewed them. Making changes to a master without reviewing will break your code. So these are just the basics that we have covered right now. Though the topics we have covered along with the demonstrations can be just enough to get started with but there is plenty of more useful features that we did not talk about and knowing about them would require further reading. To start with there can be no better place than git's own website git SCM it's original documentation to learn more about the cool features the link has been provided here and the same would be provided in the description below to feel free to check it out. Also the search engines are your best friends. If you cannot quite figure out what your problem is but you know that there is indeed a problem, all you can do is you can copy a snippet of your code and look it up on google or duck the code. You will find that there are plenty of people just like you who had been in the problem and have solved it for you. And finally we have a joint special interest group feel free to ask your questions or just drop by to say hello in fedora join. The link is provided here and in the description below. This is a special interest group to enable people to join fedora community. It does that by letting them diverse with the existing members make friends, find mentors and get a feeling of what and how exactly the community does and in doing that we reduce the learning curve for the new members. So feel free to join the special interest group. So with that we have finally reached the end of the classroom session. If you have liked this video hit that like button. Help your friends out by sharing this video with them if they are looking for such information and subscribe to this channel for more such informative content. This is Akash Deep Dhar, signing off.