Git Mistakes Every Junior Developer should Avoid | clean-code

Key Takeaways

whether you are coding ninja or just starting out with GS so you're probably doing some mistakes or maybe a lot of mistakes and yes I personally made a lot of G mistakes as well so in this video we're going to see what are these G mistakes and what is the right way to avoid those to become better at get so the first mistake is committing large and unrelated changes so for example here we got a simple project here we say oh we've got this nextjs sort of application or sass application and let's say got to assign the task to actually go ahead and add the login and sign up form and actually add the authentication functionality and just allow in general users to sign up and log in so what I started doing is actually creating these two component here like for example login form in here for the user to go ahead and log in and as well as like the sign up form for him to register and everything and I did a bunch of stuff I created an API in here for login and sign up as well like this will take care of you know you know signing up in here creating the database e user and everything the login as well for generating the authentication token and checking if the pass password is right and everything and maybe here for the services it created this service in here where it basically just going to allow us to interact with the API behind the scenes and send the email and password and get a response and just like encapsulating all of these where the user can actually just go to the form add his credentials and name and email log in and the same thing for the sign up I mean everything is pretty good in here I've got this files that I'm a good developer I put all of those but when I actually try to commit these changes when I'm done with these changes and say oh let's go ahead it's actually time I'm done with this functionality I'm done with this feature I'm going to go ahead and actually commit the changes in here into the repository so we can push them and of course deploy these changes so right over here we are actually on a branch that is the bad branch which is like the bad mistake that you do with this when you try to commit your changes for example for a feature like authentication and login and sign up so for instance if we go to get log as SC here we check the log we've got two commit and here we added a bunch of stuff we added like API r rout we added like components like UI components we other services we added DB providers in here and actually connectors so many things actually happening in here and here apparently we just did two commits so the first one is actually just like literally the initial commit for creating the next application here so you can safely ignore that one but the upper one in here is basically you know that commit holds all the changes literally all the changes from the apri route to the reacts components in here to the services and everything in one single commit so this is a very very big mistake they just put in everything inside of one big command and because all of these changes are not directly related with each others you just still putting them everything in one single command which makes it super super bad actually has a lot of downs signs doing it that way and for instance if we switch the bran and go to the good authentication flow in here with the get commits I'm going to go ahead and clear get G log as well and here we see a bunch of commment right so many of them standing from like the initial one in here and going up so each step in here every single time we create a new feature or we like put an related stuff for example here added a signup component in here for you g user registration and added a commit for it user login in here I added another commit for it and actually you know committed those changes and what I made like a sign up route in here working with a database I did that one as well I did like oh add user sign up API integration with the sign up form so I integrated that with the you know signup form in there like the API the same thing for the login in here so every single step I make like related changes that should be grouped together I go ahead and actually commit those together with a nice message that explains exactly what it's doing and these are called Atomic commits and the rule fum in here to know when to commit or not is basically when you have like related changes for example you add like an old service in here and the old server in here has like for example you add a new method for logging in so that method should be actually used with a login form so you go ahead and actually integrate that that with the login form so you do handle login and actually use off service. login I mean this is is good enough because this actually I can having an API integrated through the all service in here and from the all service inside of the login form now you're making this login form more of like integrated with the API making it fully working it's time to actually commit because this could be represented and could be explained with one single commit sentence which is like allow to login authenticate users through the login form and the other reason why would actually follow aom commits in here is basically easier debugging so let's say at some point of time after 4 months or 6 months you discover a bug and you're logging in here and he tries to exactly come over back in here and exactly trace the commits and see exactly what's going on behind the scenes so you could tell exactly which commit you should expect or inspect for the bug for example you've got like a sign up bug inside of the R so you just go ahead read through through the history in here the commit history you go down below in here for example add sign up right working with database you know that oh it's somewhere inside of the signup route and this is the commit where this thing is actually happening so you can easily copy the commit ID in here or commit sha and basically just go ahead and switch that so you can do check out and you just go to that commit now you're back into that commit and you know exactly you are at that point you can go to the sign up rtion here you make sure that there's no other changes and you can easy Trace that one by imagine you end up with something like this where everything is put inside of one single command and you try to go back for debugging and you try to go through the history of the commit you've put before you're literally not going to understand exactly what's happening in here and the third reason is actually going to make your PRS a lot more easier to actually go review and see exactly what's going on when you use Atomic commands versus when you just put everything into one very big commit so for example there's actually bad PR in here it has you know the bad approach with one single commit like everything is put in here when like your teammates or or somebody on the team tries to actually come over here and actually look into into the code for code review it basically goes like for example open the command right over here it's going to see oh oh my God like you've got all the these literally put inside of that commit but for the good one in here when you split it up into Atomic small related sort of commits it makes a lot more sense exactly oh you see oh I want to check oh they had the OD in login route with thebco matching so I'm just going to click on this one it takes me straight into the file that actually change I know exactly that oh this route changed and the DB in here had some changes as well so can easily follow along what's happening and easy code review as well now the second mistake is actually overlooking the importance of writing informative commit messages so for instance in here for example we take this Branch with this bunch of commit messages the same commit and changes we saw before on the previous example for login and sign up but with a little bit of different commit messages for example in here this commit message is supposed to tell you that we added the login functionality but instead the guy who actually put that commit message of the author of this commit decided to be a little funny and actually I don't know put that in context where his teammates going to know exactly what's happening you know he just sharing a joke with your teammates that's pretty fine and pretty good but it's definitely not a good idea to put inside of a commit message that actually describes a change ins out of your code base all of us as developers we depend exactly on the commit message to take a first glance of what that commit is for and what he exactly doing so when you telling here are only VIP Insurance to the digital party nobody's going to know exactly for example this commit has the power of a th000 unicorns I mean what is that supposed to even mean the other one here we're connecting the Doss in the digital Orchestra oh that's pretty cool but I I literally understand nothing from that I don't know exactly what this one is doing uh maybe the database and I it just became but somehow I can tell oh you this command in here you're connecting the database with your apis or something but I don't know exactly what's happening over there uh maybe oh enable top secret use a login function on something something to do with login but I don't know but if you compare the previous ones with these ones of course these ones are a lot more descriptive they tell you exactly what change they doing what implementation that was what that commit message is actually about what changes it did I mean that's a lot more descriptive that's a lot better I mean you don't need to put fun inside of your commit messages just to make them look funny and then just have that jokey side of you it's going to really really hurt the team it's going actually hurt the code base going to hurt the changes that you put inside of that one and it's actually going to make it very very hard to tell what that code exactly is doing the third mistake in here is actually using a global git config all of your repositories so I did this mistaken a couple of months ago where I was just using this Global email address for literally all of my repositories including my work repositories my personal projects my open source projects and I really didn't realize that until like I made this commit where I was working on this the work sort of repository and I used mistakely my Global email address that was personal by the way and I used that personal email to push some commands in my work repository and my manager literally called me like in 20 minutes or so asking who's that person that actually just push code into her private repository and it was like oh oh my God I I I really didn't know exactly what's happening and I was really really confused exactly oh what is exactly happening in here then when I checked I was sending one Global email for oros stories that's pretty dumb now simply to check your Global email or name so just do get conf f-- Global and you do user. email and this will print you your email for example you have lock personal Dil atgmailcom and if I try to see the local what I mean by the local is actually only this repository that I'm right here on is going to have that email which is just local to that repository and it's going to overwrite the global one so you just do-- loal in here and you do user. email and this will give me this so if it gave me the exact email the same one as the globo here then you're basically just using the same thing for the glob in the local and you simply this simple fix in here just make sure to go ahead and override your local email addresses for your all repositories that needs that for example for you know work repository here so you just do local user. email and you simply just go ahead and do like oh work @gmail.com and they simply will go ahead and set your local one to this repository in here to this new email so that way you're not going to do dumb mistakes as I did and the fourth mistake in here is actually not knowing about this awesome git plug in here sooner which is like the git extra actually going to give you superpowers for your git CLI so these are simply an extra git commands actually built to make the most out of it actually just make you productive so these commands are actually missing from the original git CLI of course and they are added by this plugin get extras so you can do a bunch of stuff as C in here if you look through the commands there are bunch of them so for example already started that one so to know if it was installed for you or not just do get extr d d version and you're going to know exactly what version you've got and for example I can use this command so get summary and this will actually go ahead and give me the summary of what I did on this project for example the repo agent here when was created um the current Branch for example the last active active in two days like the number of commit files authors in here are just going to give you a percentage of between authors because it's just me here some 100% And so many cool stuff actually or maybe you're too lazy to open up the get ignore file in here so you can use the cine to add a file so you can do get ignore using this command and you can just add whatever you want to ignore so for example you can do oh ignore Dash me in here and just put it between quotes and you can click add in here you're going to tell oh we add in ignore me in here if I go ahead and open G ignore in here right on the top you're going to find ignore me was added well the magical command that I really really like is actually get magic so you just do get magic you make sure you've got files that are actually staged for commands and simply do get magic in here this will actually go ahead and generate for you the right commit message video just like immediately do that for you autom magically and if you just go back go get log in here just added that just quickly for you so you can go actually check all the rist of command and installation inside of the git repo just type in G extras in here and you will be there and another really awesome git plug in here that actually helped me a lot throughout the last couple of months and it saved me ton and ton of time is the git opening here which actually just simply allows you when you do get open it opens the repository that you're currently working with inside of your code editor I know seems pretty simple right but sometimes we don't know exactly which Reaper we are in maybe we CL in open stores maybe we're just too lazy to go ahead into Google and actually put that repo name and and go to GitHub or somewhere but now with get open you can easily do that so just do get open and this just just typeing like that one it's going to take you exactly to the repository homepage in here get mistakes here just going to land you right over there or maybe you can just do get open D- commit and it will tell you exactly to that commit that you just write into set of your code editor and that just makes it super simple you can go to issues Pro request so many things you can check out the documentation of course actually it's very easy to install that you can just install it using mpm if you want to just go into you know shell configuration hell so anyway guys thank you for watching hope you guys enjoyed catch you hopefully in the next ones