Git Project Setup with Husky, Conventional Commits, and branching strategies.

[Music] hey guys and welcome back to my youtube channel and in this video we're going to be discussing how to set up a git project following some of the best practices including um using husky conventional commits and also looking at the different types of get branching strategies so the first thing we got to do is if you don't already have get installed uh just go to this git scm and follow whatever operating system you're currently working on and install git and then once you're done with that the next thing you're going to need is also you need to go ahead and we're going to be using github for this tutorial so let's just go ahead and if you already have a github then that's great but if not you should go ahead and sign up and create an account and that way we can go ahead and start this setup tutorial first thing we're going to do is we're going to go ahead and clone down the starter project that i went ahead and created for this video and we're going to do that by just running this get clone command and then you have to insert this https github.com which just is pointing to the git repository we're then going to go ahead and switch into that repository and we're going to run git branch dash r and what that's going to do is it's going to show the remote branches that i went ahead and created for this project so right now we're at the master we also have a complete which is just a branch for the complete code as well as a starting point so if we go ahead and let's just go and check out uh start oops we go get checkout start meaning that now we're at the starter point and if we run um and open up visual studio code to actually show that project we can see here that we don't have anything currently configured and i'm going to for the purpose of this video go ahead and actually create another branch from the start branch just so that i don't go ahead and mess with it for you guys when you guys clone down the repository so i'm just going to check out a new branch called tutorial but you guys can go ahead and just work on the start branch so for this tutorial the first thing we're going to look at is we're going to actually look into how to set up husky and if you're not familiar with what husky is husky is pretty much just a popular npm package i think there's like a million downloads a week it's extremely popular but it allows you to write custom scripts to be run against the get hooks that come available to you in a git repository and if you're not familiar with what a git hook is what we can do is it's probably easier for me to just show you so first thing let's actually install all of the dependencies um within our project and then once that's done we can actually go into our git folder and it's an invisible folder but once that's done we'll go into there and we can show kind of what these hooks are and i'll also include some documentation that i found that kind of goes into detail about what each of the hooks do so if i do a ls al so i can see all the invisible ones we can see here that there's a git folder folder and then within here there's also a hooks folder right here so if i go and switch into hooks here you can see that there's a list of all of the git hooks that we can run scripts against so husky will allow us to kind of customize these hooks so that we want to say anytime a pre-commit anytime we're going to commit something into git we actually want to run this script to do a specific thing like maybe lint our files or run unit tests so now that we kind of understand what these hooks are we can go ahead and first thing let's go and navigate back to our project or root repository and we're going to actually go ahead now and install and configure husky and the easiest way to do that if you're using yarn like i am all you got to do is just run this command of nps husky in it and yarn like that and so what this will do is it'll actually go ahead and initialize husky for you creating the necessary folders as well as configuring uh package.json with this prepare script so if you're not familiar with that does is first it adds this prepare script for you and this is new in husky 6. so previously as part of the post install husky would go ahead and kind of configure things for you but we're trying to they're trying to kind of go ahead and get away from that as they're trying to follow package manager's best practice so what they do instead is that they'll create this prepare script for you and this will be run once you install the dependencies of the project so like running yarn install will actually go ahead and prepare husky for you and it'll also go ahead and create this husky folder in your root repository which i'll just create a git ignore and here you can see this is the actual husky shell script which it pretty much just goes ahead and kind of just sets up but you need to for to be able to run these different commits and you don't really need to worry about this you can just leave it as it is and then what you'll see here is it also goes ahead and creates a pre-commit uh husky script which all it does is it um kind of goes and gets the script that i just showed as well as runs the npm test commit so now that we have those things set up what we're going to do is actually we're going to then configure a new script and what this script is going to do is we're just going to create a lint script and pretty much all this command is going to do is just run eslint on our root repository and this will just go ahead and lint our entire repository making sure that we're following the correct guidelines that we specify within this eslint rc.js for the purpose of this video you don't really have to worry about what this is doing but if you want to go and look at my set up a backend project in there i kind of go into a little bit more detail as to what these configuration values are we can go ahead and close out of that and since now we have this lint this will pretty much tell us any time we aren't following the guidelines but we could also go a step further and actually run and create a lint fix script and what this will do is actually just run eslint but if we pass in the option of dash dash fix it'll go ahead and follow our prettier configuration and it'll actually just auto format and clean things up and it's really useful for uh if so for some reason you may have missed um following that kind of pretty or maybe you don't have like the auto auto fix on save something like that this will go ahead and actually just fix all those little nuances that you might just not really want to worry about all right and let's test that we have everything working correctly and the best way to kind of go ahead and test these different hooks to make sure you don't actually go ahead and commit or push changes up to github what you can actually do is at the end of each hook just write exit one and what this will do is it'll just go ahead and fail out of that specific hook and then that way you know that you're not actually changing anything and you can kind of go ahead and test things to make sure it's actually working correctly so what we're going to do is yeah let's add exit one and then what we're going to then change is we're going to run uh yarn lint and yarn test so let's go ahead and actually run yarn fix so what this is going to do is it's going to go ahead and run the linter across our entire repository fix any changes throw out any errors if we aren't following necessary best practices or the rules that we have set up as well as run our unit test before actually committing anything and we can test that out by just doing uh adding that change so by using git add and then what we can do is get commit dash m test as the message and what it's going to do here you can see that before it actually goes ahead and does the commit it's going to run eslint dash dash fix on our on our repository and then run our unit test which is just running the tests set up in here as well as here so if those fail the commit will fail so that way you can maintain uh every commit that you have are passing your unit test you can also go ahead and make that a pre-push hook if you want if you don't want your commits to take a long time running your unit test but here you can see pre-commit hook exited with error code one and that's because we have this exit one specified in the pre-commit hook and to show that the lint rule actually is working and that the commit won't actually go ahead if we aren't following the best practices what we can do is we can quickly test by going to our index page and let's just add a function like hello world is equal to this and all it's going to do is return hello and here you can see we are breaking our rule convention by specifying a function name in uh snake case as opposed to camel case so if we go ahead and we're like okay that's awesome go ahead let's add it um oops not yarn ad get add and then we can commit just another test and then what it's going to do is going to run eslint fix and since it sees here that we have a couple problems first we have that hello world is not in camel case and it goes ahead and tells you which file the error is in why the error is happening so we also have no unused variables as well as uh yeah so just a warning saying that hey we have an assigned value that is never used so that's just one of the rules that we set up yeah so that's just really useful especially like when you have a lot of people working on the same code base and you want to just maintain consistent style this way it kind of enforces just as a last kind of effort like hey just make sure that you're following uh whatever the repositories code style is and it makes sure it enforces that and that way you won't have any commits or pushes to the repository that may infringe upon those so now that we kind of removed that linting error and we also removed the exit one now if we go ahead and try to commit our changes husky setup works it will do the same thing as it'll run the linter try to fix anything kind of just takes care of that for us run the unit test they all pass so therefore everything works out perfectly and we were able to actually create the commit then after creating that commit we can do something like git push set up stream origin and i have to do this because i created a a new branch just so that i don't mess with the start branch that you guys are working on but if you should just be able to get push it up to that repository great and so yeah that's all working perfect but now let's say for example we have a repository so this repository is pretty small project but let's say we have a massive repository and one thing we don't want to do is we don't want to always have to run our linter across the entire repository we only want to run the linter across the files that were changed and one way to do that is we can introduce a new library called lint staged and the way that we do that is just by doing a yarn add dash the lint stage like oh not like that because that's the wrong library so yarn ad development dependency of lint stage and that will go ahead and add that library to our project and then what we can do is we can actually switch our uh pre-commit hook to instead of running lint fix here what we can then do is just make it call lint staged and then if we go into our package json as well here you can see that we now have the lint staged uh library configured in our project but we do need to do one more spec specification and we do need to create a lint staged rc where we can then go ahead and did i create that correctly um yeah i just it was taking a little bit so we can create this configuration file and within this configuration file what i'm going to do is go ahead and just add this uh quick little regex which is saying that for every file change that we have in our repository if it ends in a js or a dot ts extension then we actually want to run eslint so this what this will do is that it will only try to lint the files that end in typescript or javascript and it'll only try to run them if they have been added to these changes so these changes right now none of these files will actually get linted which just makes our project and the commit workflow ad workflow everything just a lot quicker and so yeah if i just go ahead and if i add those changes if i go ahead and write a commit commit added lint staged and then now you can see that there's an error oh that's because of this comment if i remove the comment now it should be able to that should work and there we go so now there's no staged files match any configured task and you can see that's because there were no dot js.ts files that were changed but if i just go ahead and let's say add a let's just add one more console log here just to kind of show that it will catch this if it is staged staged me so there we go go ahead add it commit dash lint stage test now you can see when it runs the eslint dash fix here it will run the task for every js and ts file so there you go you can see that it actually picked up the changes within this staged file and last thing to do with husky just so i can show you guys how to do this is if we ever want to create another kind of pre-commit hook or just another custom hook the way to go about doing that is just running this npx husky and then we actually do an ad husky and let's just create a pre-receive hook and then in this hook all we're going to do is just echo out the string pre received and if we run that command what it'll do is it will go ahead and create this pre-receive hook and it'll configure it to be worked with husky awesome and so now that we have husky configured for our project we're going to then configure conventional commits and if you're not familiar with what conventional commits are if i go to their documentation pretty much what they state is that it's just a specification or kind of like a standard for your commit messages and it's kind of adding human as well as kind of a standard to make it so that you can actually write a lot of automation on it if you want to but pretty much how it works is that this is the standard right here you have a type which kind of specifies what type of commit this is so it could either be like a fix for a bug or as well as like a new feature being added you can also have docs which is just documentation changes uh you have an optional scope which is just something like if you want to give a little bit more detail as to like the scope of what this commit is what file you might be working on what project feature it might be working on you can also add a description which is kind of a required subject as to what this commit is doing you then can also add a body which is if you need to add more description as to what this commit is trying to do as well as footers which you can then add even more description as well as maybe like references to different jira tickets or what issues that this commit might be trying to fix and yeah so now that we have an understanding what conventional commits are the best way to use it within our project is to actually use husky to set up a commit message hook where we can run a custom script against it to make sure that it's following the conventional commit standard so the best way to do that is let's go ahead and we can run this npx husky ad dot housekeep and we'll do a commit message and if you have uh the uh pre-receive hook within your repository you can go ahead and actually delete that because we're not gonna be using it for now and so instead of using that we're going to use this commit message hook and i'm going to go ahead and copy this code over that i've pre-configured which pretty much is just checking to make sure that we're following that convention that we just talked about with the conventional commits it's gonna check to make sure that our type is uh one of these types as well as like the optional regex for having a scope and then we're also going to make sure that the subject line is present and it is between 1 and 88 characters and the reason that we chose 188 is that's because that is the committism uh standard which we'll configure here in a little bit so with that set up we can show that it's working by let's go ahead and try to actually do a commit and if we just were to do a commit like we had previously done of just husky the commit message is now actually going to be kind of run against this commit message husky hook and it will tell us that our commit message is invalid as you can see because we're not following the conventional commit standard but then if we were to go ahead and actually commit dash m and just as an example i can do feet and we're not going to have a scope but we could just do feet and added conventional commit hook this actually does follow the conventional commit standard and we should therefore be able to successfully do a commit and you can see here that we actually uh failed to create that commit because we do have a couple of files that we forgot to add their modifications so if you go ahead and just run git add the entire repo and then if we go ahead and run git cz again and then let's just go ahead and create this really quick add commit to send no no no now it should be fine because now we actually added the changes that we wanted to so there we go you can see now that the commit message was correct and um here you can see kind of like what it comes out to it so it's just feature and then add commition and then now we should be able to go ahead and actually uh complete that commit by pushing it up but if you are working on a team that's not familiar with conventional commits and you kind of want to simplify the process of having to kind of really understand what's going on you can actually use this really nifty library that we're going to install called commitizen and what this does is it provides kind of like a drop down menu and anytime you go to do a commit and that will build a conventional commit style commit message for you so all you got to do is go ahead and install that as a dev dependency and the next thing you got to do is actually run this committing init script where we're going to create this cz conventional change log and i believe since i've already done it i'm going to actually need to use force to just kind of overwrite whatever previous one that i have but so it's going to go ahead and initialize this change log for us and what that does then is it allows me to actually use a new command instead of git commit i could then now do git cz and this is kind of an example of what the committees in um builder kind of looks like so then it'll give me the options of like okay what type of do i want so i can just do um let's make it a feature and then if i write committing and then added committing library as the description i don't really have any body there's no breaking changes and it does not affect any issues and then what this will do is it'll go ahead and build a conventional commit style commit for you and unless you guys are doing this within your own type of project uh where because i know you cloned it down to kind of follow along but if you were to go ahead and initiate your own type of github project for this then you would be able to push it up but if you're just following along then you don't necessarily you won't be able to contribute to my repository unfortunately so just a heads up on that another kind of cool thing that we can do with this um uh committing is that we can actually add a readme to our repository and then within this readme there's actually a little shield that you can kind of add which pretty much if you if i just show you because it might take a little while pretty much what it does is you can add this little committeeson friendly badge your repository can then specify like yeah we use commedicine and it's committed friendly just for you can either add that to a contributing markdown file as well as to your readme and yeah that's just kind of a nice little thing to do so we have committed sin set up we have conventional commits set up we have husky set up uh the next thing we're going to talk about is the different get branching strategies and uh to kind of understand that a little better there are three main types of branching strategies and if i just google this really quick you should be able to see the very first one which is the one called git flow so this is the git flow branching strategy this is kind of the model that has been used throughout software engineering since 2010 and it has become a little bit outdated due to the continuous integration continuous deployment as well as a lot of projects being web-based projects and not really using versioning as much anymore but it's still it's important to know because it is kind of like the founder of um what different what a branching strategy should really look like and let's kind of go into it really quick as to try to understand what the git flow branching strategy is and uh there's this website called with get kraken and it kind of talks about uh the three main different types of git branching strategies there's the git flow there's the github flow and then there's the get lab flow and we're going to kind of go over each one of them and why they're used and their pros and cons of each of them and how they differ from each other so if we look at this documentation just kind of at a very high level the git flow workflow consists of five different types of branches you have your main branch which is just your production branch it's what the clients use to access your main application um you have the develop branch which is created to kind of maintain a different branch as you're developing new features and this is kind of like a pre-production branch where you have things slated to go into production that you've been working on and they're just waiting to be tested then you have your supporting branches which are the feature branch which are branches branched off of the develop branch that you use to add new features you have the release branch which is just a branch preparing a new production release kind of similar to the develop branch but maybe um it can be your release branch is your pre-production and then develop is kind of like a higher level that you then kind of go through this merging flow of develop changes goes into the release and then they're tested in the release environment and once that's all done then they're finally merged into production and then you have the hotfix branch which is just uh you something is broken and you need to make a quick fix which you then quickly branch off of production you do a hotfix fix it merge it into production and then you just have to make sure you remember to later on um merge those changes also to your uh other level branches like develop and that's kind of just what the git flow is at a very high level if we look into this reflection note that the um that the creator of this flow kind of talks about is that software has changed and like i mentioned it's not necessarily too much versioning as opposed to more web-based projects that are always up and are continuously delivered and it's very rare that you roll back or you have to support different virgin versions but not virgins versions of a web application so with that um understanding as to why uh that might not be necessarily used as much we can look at the github flow and so this is my personal recommendation for what type of branching strategy you should use especially if it is a web-based project and you don't need to support multiple versions it's just the simplest and it's super easy to set up and it's really useful especially with continuous integration and deployment to have different support different environments and um it is just the simplest of the three so um to kind of understand what the github flow works and how it does work and we can actually go back to get cracking because they do a pretty good um explanation of it and you uh again here don't require supporting multiple versions and uh you pretty much just have uh six principles that you try to maintain and follow within this flow so the first principle is that any code that is within the main or the master branch should be deployable and ready to be deployed you then use this main branch to branch off and create different types of branches and you the naming convention for that kind of can be whatever your team is using but here for example they're creating a feature branch off the main branch you then uh work on this local branch until you are ready to uh merge it into back into the main branch you then go ahead and create a pull request and if you're not familiar with what a pull request is it pretty much just means like hey i've been working on this local branch i want to merge it into the main production branch and if you're working as part of a team you can set up rules where you're like okay i need one other person to actually approve it you can go ahead and actually set up different workflow and checks using github actions or whatever your ci cd looks like but and we can actually go over in another video as to how to set that up in github actions but yeah so pull request and then once that's approved and it passes all the chat all the tests it will be merged back into the main branch which then can be deployed immediately into your production environment so just to quickly cover um what the benefits of this flow is that out of the three main branching strategies it is the simplest it is very easy to kind of set up ci cd for it as well as it works really well for web applications or applications that aren't necessarily needed to be support multiple versions um some of the challenges is that of course it's not really made to support multiple versions so if you do need to support different versions of an application this might not be the best branching strategy to use and since you are kind of merging directly from a branch into the main branch that is deployed to production if you don't do it the correct way you could you are more susceptible to bugs in production which is bad and the last kind of branching strategy is called the get lab flow branching strategy and this is pretty similar to the github flow but it's trying to be more tailored to if you do actually need to support multiple versions so um the way that it works is that you have version release branches where each release has an associated release branch meaning like version 1.1 1.2 bug fixes should be just be merged back into the main branch first and then cherry picked into the release branch and then you also have continuous release which is production branches are utilized to contain deployment ready code similar to the github flow and once it's merged into there it's ready to be deployed so kind of the benefits of the git lab flow is that when compared to all the the other two branching strategies it's not um necessarily the simplest but it's also not as complicated as the original git flow branching strategy it is more organized and has more structure than the github flow branch and then you can also set it up to use ci cd pretty easily it just takes a little bit more modification and then some of the challenges of the gitlab flow is that of course it's not the simplest you do require a little bit more setup and it's also not the most structured because it can get a little bit messy with all the different branches into the really the release branches that are incorporated with the branching strategy and that's all you really need to do and so if you've been following along with the tutorial you should have a configured git project set up with conventional commits and husky which i believe to be following some of the best practices to kind of maintain code consistency as well as working within teams to maintain understanding of what each commit is doing and being able to kind of automate processes if you need to uh one thing to keep in mind is that there are two different types of repositories that we can support with husky and conventional commits and things like that um in this tutorial i went over just having one project where that project does not it's not a mono repo is what we call it so it is the project it's the source of truth and it is the root project and things like that but i will include in the description if you do plan on either needing to support a mono repo or set up something similar to having where you have one parent repository within and then within this parent repository you have multiple different micro services and things like that where they're each their own project but they're living within a parent repository that's on github um that is what the monorepo is called and the setup is pretty similar but it still does take a little bit of configuration so i will include in um the description below how to or a link to the repository that i actually set all of this up in a monorepo style so um i appreciate you guys watching and i hope that this may have been of some help and if it was uh please leave a like as well as subscribe if you want to keep seeing more content like this and i hope to see you guys in the next video and thank you you

Channel: Leo Roese

Views: 4,214

Keywords: git, github, git branching strategy, git-flow, github-flow, gitlab-flow, husky, conventional commits

Id: jNxDNoYEGVU

Length: 30min 25sec (1825 seconds)

Published: Mon May 10 2021