Git/GitLab’s USAGE : Training Part 1

[Applause] hello everyone good afternoon this is me joshua and besides we have jc right here and i welcome you to pixelate's basic software training program here at pixelate we aim to teach you and to help you guys learn about the latest technologies found in the web as well as to inspire others to learn how to develop their own software as well as to establish their own applications and to build their own services so with that mind and with that vision in mind we came up with this tutorial and this training program in order to help you guys to learn how to make your own applications as well as to teach you guys what we are already using here in our company so for the first topic we have git version control and gitlab you might ask what is git so for those of you who are not aware of what is git gig is a free and open source distributed version control system so a version control system is a way of handling file versioning based on your changes so for example you have a single file and then you modified it and then you want to save asana or rather you want to say that specific instance without losing the previous one so what's going to happen is your first or rather your first instance is going to it's going to be same as well as your second instance so think of it as a way of handling different versions of your files so if you have several versions let's say four versions what's going to happen is it has four versions of those files meaning version one two three and four and then you can swap versions based on the response that you want to use commercial of this instance let's say you want to use conversion so you can use the version anytime you want as well as you can you can also use conversion form anytime you want as well without losing all of those at all so this is useful for those of you and then for people also to never use game in the first place and then lastly for those fields give gui tools because because git is mostly used in a terminal sense but that does not mean that gig does not have a ui itself so there are some real applications that provide ui for git itself so for the installation you simply go to git dash scm.com and then you download the latest version for the application itself based on your operating system so once you do that you simply install git then after installing it you now have an instance of your laptop or internal machine so once that is installed you need to first set up your git installs so later on we're going to demonstrate how to set up your own git instance so first you're going to check the version so you will see here that you have um you have several commands to run in a terminal so first step would be to check the version now why is that because git's behavior is different for each version that's why we recommend that you first check the version of your did in order to move or rather in order to look for the specific documentation for that version next is you're going to set your configuration values so what are these configuration values namely this two these two values are important in order to tell you that you are or rather that your user which is you yourself has a specific name and email because git utilizes the name and the email as a way of identifying from or rather as a way of identifying who created the committee who pushed the committee and then to send those commits or rather he merged and everything else in between to get restarted feature you have two common scenarios so the first scenario would be your project is on your local machine so that is the most common instance and then another instance would be you have an existing project on your remote for or rather in this case in gitlab so if you if for instance your project is on your local machine what you need to first do is to initialize a repository now a git repository is a virtual storage of your project so think of it as a bucket of some sort so any changes you make to your code base will be stored in the buckets and any changes you apply or you update or you delete will be stored permanently in your virtual storage so it allows you to save versions of your code meaning if you initialize your git at the very first or rather the very start of a project or if a or a very beginning of the project could be as as long as you use git and you continue to commit and update and merge your entire code based version is or rather is kept in the safe storage no matter what happens all of your codes evolution as well as the evolution for that matter is saved in your virtual storage so all of the changes are trapped inside a gif repository so no changes are left behind so everything is stored so in case you for example in case you break your code at a later point in time you can always roll back to a previous version so there's no harm with that so that in mind you can safely comb and as well as you will not be rather you are not afraid to commit mistakes that much because you can simply roll back in a safe point in time or rather in a stable point in time so in order to initialize a repository you simply need to type git init so what this does is it initializes your git repository in your current directory wherever they may be next before you make any movements with your repository you need to first check the status of your repository using the status so what does what does bitstatus do git status basically shows you the status of your repository as well as to check for any changes whatsoever and then next we will need to add a git ignore file so you may ask what is a git ignore file a git ignore file is a type of file that tells git itself that whenever you encounter a file type of this extension you ignore the changes from that or rather you do not include them in the git itself so there are instances that you do not want to commit some files inside a git repository for example the also dreaded node modules the heaviest matter in the universe for that matter so aside from those you also do not want to store vendor folders inside your git repository because what happens is if you do that you're going to blow out the entire code base in order to avoid that we need to add specific git ignore files for that in order to ignore the node modules as well as to remove specific files from the codebase because we do not need them to rather we do not need to store them because we can simply reinstate them anytime so for the git states you have three states for that first one is you have a working directory which is your current workplace so for example you have a folder somewhere in your samp directory so that is a working directory or rather i am working directly in any directory wherein you apply or you apply changes to the code itself so before it before it gets transferred to the staging area you need to first stage your fixes now fixes are those types of rather fixes are code changes which needs to be updated to the staging area itself what it does is in a sense you're like uh what do you want to do so you're like moving your changes in a specific area without affecting the entire state what it means is you're preparing this fixed or rather this code bases or these changes to be committed to the repository itself once you have your staging area ready or rather you chose what you staged you commit them to your repository that means you're going to add them as a snapshot to your list of changes in the repository again first you have a working directory wherein it is the area where you apply changes to your code you change the specific text file or in html file or any file for that matter and then after you modify those files or once the once you are done already with your transactions or your updates you stage all of those fixes to a staging area it's like it's like akin to a car so all of those changes you put them inside a car to be checked out into a repository so once all of your changes are in the staging area you commit them then after you commit them the repository gets updated so now that it is updated you need to check out your project to your working directory so this checkout mostly happens for those instances where you have multiple users or multiple developers working on the same code so every time you change the repository itself you need to tell your workmates or your colleagues that a change has been pushed in the repository itself in order for them to pull those changes back to their working directory now why is that it is built that way because git is a decentralized system meaning every user who has a copy of the repository has a complete copy of the repository itself so in a sense if you have let's say five developers or five colleagues if you all check out the same repository all of you have the exact copy of those files across all of those five machines meaning if one of you in case one of you fails or one or one machine fails you have four redundant copies of that same repository as well as the one in the cloud in case you have a cloud instance so whatever happens your git repository will always be intact as long as they have multiple copies of it next before you make any movements with your repository you need to first check the status of your repository using the status so what does what does bit status do git status basically shows you the status of your repository as well as to check for any changes whatsoever and then next we will need to add a git ignore file so you may ask what is a git ignore file a git ignore file is a type of file that tells git itself that whenever you encounter a file type of this extension you ignore the changes from that or rather you do not include them in the git itself so there are instances that you do not want to commit some files inside a git repository for example the also dreaded node modules the heaviest matter in the universe for that matter so aside from those you also do not want to store vendor folders inside your git repository because what happens is if you do that you're going to blow out the entire code base so in order to avoid that we need to add specific git ignore files for that in order to ignore the node modules as well as to remove specific files from the codebase because we do not need them to or we do not need to store them because we can simply reinstate them anytime so for the git states you have three states for that the first one is you have a working directory which is your current work base so for example you have a folder somewhere in your sub directory so that is a working directory or rather i am working directly in any directory wherein you apply or you apply changes to the code itself so before it before it gets transferred to the staging area you need to first stage your fixes now fixes are those types of rather fixes are code changes which needs to be updated to the staging area itself so what it does is in a sense you're like uh what do you want you so you're like moving your changes in a specific area without affecting the entire state so what it means is you're preparing this fixed or rather this code basis or these changes to be committed to the repository itself now once once you have your staging area ready or rather you chose what you staged you commit them to your repository that means you're going to add them as a snapshot to your list of changes in the repository so again to repeat first you have a working directory wherein it is the area where you apply changes to your code you change the specific text file or in html file or any file for that matter and then after you modify those files or once the once you are done already with your transactions or your updates you stage all of those fixes to a staging area it's like it's like akin to a car so all of those changes you put them inside a car to be checked out into a repository so once all of your changes are in the staging area you commit them then after you commit them the repository gets updated so now that it is updated you need to check out your project to your working directory so this checkout mostly happens for those instances where you have multiple users or multiple developers working on the same code so every time you change the repository itself you need to tell your workmates or your colleagues that a change has been pushed in the repository itself in order for them to pull those changes back to their working directory now why is that it is built that way because git is a decentralized system meaning every user who has a copy of the repository has a complete copy of the repository itself so in a sense if you have let's say five developers or five colleagues if you all check out the same repository all of you have the exact copy of those files across all of those five machines meaning if one of you in case one of you fails or one or one machine fails you have four redundant copies of that same repository as well as the one in the cloud in case you have a cloud instance so whatever happens your git repository will always be intact as long as they have multiple copies of it so in order to add files to the staging area you simply need to type git add and then you type the file name itself or in the case of you want to stage all of your items you simply add a parameter in order to commit all of those files inside the staging area and then you check the status of your staging area using its status and then in order to remove files from the staging area you simply need to type git space reset so it resets the staging area and then now you're free to apply new changes to your staging area and then lastly after committing the files to the stage area or rather after staging those files you need to commit those fast to the repository now in order to do that you need to simply get you need to simply type git commit space m in order to create a message and then you append your message so in this case what are your changes to the code so in terms of messaging before i forget the commit message is an important way of communicating between colleagues so as much as possible we suggest that if you are going to type commit messages always use the first word of your commit as an action word for example add update delete modify use action words for your first word in your commit message that is or rather you may ask why is that the purpose of that is in order for the developer to be quickly identified to be quickly notified about what that commit specifically does so at the first glance you will know that ah this commit changes the following files this commit updates the following this commit removes the following so with that with that type of messaging in mind you in a sense your team saves a lot of time instead of typing up cryptic messages or any message you might want to apply also there is also a rule of thumb for the git or rather for commit messages to type a very short descriptive street to the point one sentence commit message in order to make it as concise as possible because there are instances that a specific commit changes a lot to the code or rather creates a lot of changes or makes a lot of breaking changes to the code itself so in order to make the story short you need to create a single descriptive and concise commit message in order to save everyone's time as well as to make your comments more descriptive and understandable lastly after after committing your files you need to check your status and then you need to check the logs so git log basically shows you the current state of your repository so in order to check the repository itself you need to simply type git log so for the git workflow this is a or rather this is one of the most basic workflows indeed or rather one of them one of the common workflows when it comes to development with git so first you need to of course code and then once you're done creating your code you stage them to your repository and then after staging them to the repository you commit them so after committing them now at that point in time the code itself is already inside the repository right so if you have a cloud instance of your git let's say you have a remote repository which is later on we're going to show you by a gitlab what you're going to do after committing is to push those changes to the remote now why is that we need to do that in order to create a redundant copy which is safe or rather which is safe within the cloud itself so we don't have to worry about that anymore now for anyone or rather for any developer who would like to update his version of the code itself he needs to pull from the report back to his local machine so in a sense you can visualize how collaborative workflows happen in a git workflow so first you need to code and then you stage that code and then you commit the code after committing you push them to the remote which gets transferred to the cloud and then after it gets pushed to the cloud you have your colleagues who will pull those changes to their own copies and then the work continues on as well as it gets repeated over and over again so that is a git workflow if you see this video has been useful for you please don't forget to click the like button as well as to hit that subscribe button to get notified of our latest updates as well as when new tutorial videos gets uploaded again this is joshua from pixelate see you in the next video pixelators [Applause] you

Channel: Pixel8 Academy

Views: 288

Keywords: gitlab, git tutorial, version control git, git version control tutorial, tutorial, git, software development training, basic software development, software development tools, install git on windows 10, git states, git repository tutorial for beginners, git workflow, pixel8 academy, academy, part 1, basic software development training, pixel8, git and gitlab 2021, git and gitlab

Id: 4kWCzjHZG5Q

Length: 21min 29sec (1289 seconds)

Published: Wed Sep 01 2021