DevOps Topeaks

#14 - Git

• Omer & Meir • Season 1 • Episode 14

Share episode

Send us a text

This week we talked about Git! The version control all (most) of us are using daily.
How did it start? What's with the name? 
What should developers know?
Have you ever wondered how to delete stuff form the root of the tree? Maybe how to pin point a commit that introduced a bug?
We had a fun chat around functionality, productivity, do's and don'ts.

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

couple moment ready I am ready and action finally we did it right action action I don't have any props today I'm not at all no props no nothing no okay so hello everyone and hello omelette and welcome to our there with me 14th the 14th episode of DevOps topic 14 yeah we've come we've come this fall and today we are going to talk about git in its relationship with ops so maybe it will be like git ops or only git we'll see during the session like how it goes all right interesting interesting yep okay omelette what's the first thing that comes up to my mind when I say git the first thing that comes to my mind is Linux actually because of its origin story right because okay what's git git is a vcs right is this yes am I messing it up it's a version control system yeah made it okay so yeah it's a version control system it's a way to distributely distributely I'm messing my English to never mind it's a way to manage kind of coordinate the changes on a file system doesn't have to be code although we do use it for code it doesn't have to be you can manage whatever you want more often than it's being used to manage code repositories and large code system right code basis rather so the first thing that comes to my mind is Linux which developed it if I'm not mistaken back in I don't know 15 to 20 years ago so he built it in order to have some kind of a version control system to be able to control the the Linux changes and development so he actually started it off and I think today it kind of it has a life of its own and other people are managing it and are managing the contributions to it but that's the first thing that I'm thinking of so a version control system some kind of way to manage code changes in a large code base that's basically it sounds like you're so a second thing to say about it so that's the first thing that comes up to your mind so what the second thing that comes up to your mind sounds like you get you get a lot of your mind about Git I got plenty I got plenty most of it is actually you know how I'm used to kind of complain about what developers are or how developers are abusing some kind of aspects of systems so I think I have a lot of it when it comes to Git but not really it's that's the basics of it it's it's a convenient way to manage some people I mean it divides the community in in a very weird manner some people are in love with it some other people have a lot to say about it like a mouthful of ideas and and concepts I love it I have to say I'm doing really well with it I it has its it's weird bits but I like it by the way do you know why it's called Git I just found out this morning that global index something so I knew something like that but I knew another story which was basically Linus wanted something very easy to pronounce which has three letters in it and is not used in Linux at all so we just chose Git so I think that's actually the reason but it's a nice trick if you're interested and you're listening to this podcast right now go search why Git is called Git it's as all kinds of references at one point yeah so I think Git in in the UK is like a horrible person or a very annoying person so Linus one said yeah I call things after me so Linux is after Linus Git is a horrible person I'm a horrible person that's why Git is yeah all kinds of weird references so that's maybe you can chat GPT about it maybe you know oh my god no no please don't involve I still want my case so I have a tough question because we always love those tough questions it's tough and also easy okay it depends how you look at it okay okay are you ready I am okay so OML how do you write your comments or maybe not even write your comments so it's like this question is divided to two right how do you divide your comments like how do you decide like okay this is I wrote this bit of code and I think this is the time to commit the code and also I'll add and how do you write your commit message like how do you you know what's your what's your style what guides you through when you do that okay that's a great question because I have a few a few answers to that first of all I wanted to say I want to throw a it's not the best response in the word but I want to throw back a question when you write a feature when you change something and you want to commit it before the message we'll get to that before the message you want to add your code and commit it what do you do do you normally add the file do you normally add star how do you add you might change it in a few files because it's a new feature how do you commit it now what do you do what do you mean like how do you commit it now now you have you have a working copy and you changed two files you change the read me let's say you change you you might changes in one of the files and then you change your read me too much the change that you made and now you want to commit it right so you know you need to get add right what would you get add like you you would add just both five's read me and whatever script or message and then you run a commit usually I do it as a group so if it's related to the same feature I would commit them all together but I like oh wait I also have an answer for that so before throwing it back I don't want to mix with you all on sale because I think like from the from the end so I want to hear yours first so yeah so I I am because I'm going somewhere okay so I think I'm thinking from the end you know I'm thinking about the cherry pick like if someone would want to cherry pick my commit I'm not going what would be the best way like it's a good point you know but I have a more basic point I think you're going into a deeper level of it so by okay what I'm describing now is a mistake I used to do for years for years as developer by the way and at one point someone which was a mentor of both of us I think just came to me and said what are you doing I was just get add files get add file it would make changes and just add the file and then prepare it for commit and he said what are you doing and I'm said well you mean what I'm doing I'm adding files so I can commit them and add them but he said what if you made changes that are not relevant to this specific commit because like you said you now made the change and you want to write a commit message you want it to make some kind of logical sense but what if I made a few changes because more I mean a lot of times you make changes but maybe I'll fix that maybe this needs indentation maybe that's need a little bit of fixing and then you find yourself adding a lot of stuff that doesn't necessarily have to do with the commit so either you write a really long commit message and add I made this end that and this and that or you can just add hunks so I use I'm writing a meovim you probably know I'm using plug-in that helps me do that you can do that on your own but basically what I want to say where I'm getting at is don't get at a file get at a hunk like a specific change add the line the line that makes sense or a few lines that makes sense you don't have to add all the lines that you've made changes to so maybe I can now do two different commits I made a lot of changes but I can do two different commits one of them would be the feature that I've changed and the other is those unexpected changes for indentation and remarks and adding comments clean up yeah linking whatever yeah yes okay so now I'm getting to your second question which is the message itself and that comes that's that builds on what I just said so my message I wanted to describe a certain change one change that's logically easy to come back to and change why because you just talked about cherry picks which comes directly connects to that and on other cases maybe there has some bugs or things that I need to change and if I want to go back and revert the commit or change it or do something with it now I'm reverting too many changes all at once which would probably be bad because I'm reverting everything together I just made maybe some fixes and indentations like we talked about why wouldn't I want to revert all of that so if you divide it if if that's the way you work obviously 90% of the time it wouldn't be a problem but if that would be your new method of work it would be really easy to go back to things and make changes and not hurt yourself not shoot yourself in the food so my message I try to keep it short not too short I don't want to do fix that's okay by the way do you know the site what the commit yeah yeah you sent me that it's crazy yeah incredible so we'll leave that in the description below we will keep it a secret and we'll put in the description we let others find out and have fun with so that's it okay okay so okay so when you write the message usually how do you pronounce it like in past tense present tense or like how do you describe the message you can just give me an example if you want to so you change as you just said you changed maybe the source code a bit and update it with me accordingly you clicked on add add add all the files are now in staged mode right there or stage you're about to write your commit message how do you describe your commit message I don't have a convention or a standard for whether I'm using past tense or present tense I do try to think of a future maintainer that will go back to the list of commits and understand what was changed exactly because if that has something to do with the certain bug I want to have my maintainer find the bugs see what you just said you said what was changed exactly so this is why I'm reading writing everything in past tense like okay this commit in this commit I fixed this and that I modified this and that so also how do you start your commit message do you like to start it with maybe a verb maybe like saying fixed whatever modify this in that or you just shoot at it like in a logical I think naturally naturally I do both I use past tense and I use a verb to begin with I don't think I've ever thought of it in a sense of having a standard or something constant that's interesting giant but do you also know the the cool feature I'm not say cool feature of git but there's the commit message and there's also the commit details message do you know that uh not sure no so okay so when you I'm editing a file on github okay for example or any online git provider you'll notice you can let's say you add the read me okay most of us maybe just edit the read me if you see a glitch you know so you edit the read me and then you see okay this is the commit message and the default one is like updated right read me MD okay yeah and then below you see a large text box and you're like what is that and that's the commits description now this one you do it online but if you want to do it like when you're offline let's say on visual studio code if you just write down the commit message and then hit like shift until until so you drop down two lines you can write down like a bunch of stuff in that same commit and then you have the short commit message and to that same commit you can have like a large description of okay so I consulted with owner of this bug and he blah blah blah yeah do you use that almost never only when it has to do with huge features and then I want to describe a long list of stuff that I may change this to but again I I'm 90% of the times 99% of the times I want my changes to be very small and very precise so it's easy to go back and revert them but I think I've used it like a handful of times not more than that but yeah I know what you're talking about it's like a multi-line long message that you can add a long description to it yeah definitely so I use it to to have fun usually so in case I'm walking on something very very long time so okay and I write down this took me a long time I am said about this commit you know write down a story you know but not something professionally or I mean so it's mostly for jokes that's my stuff with that description thingy okay I want to go back a little bit zoom out and speak a little bit about the structure not the structure of Git of the nature of it because I have something important that I want to say to the world so I didn't say to the world I think we both know but comment on it if you think I'm need to be fixed at some point so if I'm not mistaken Git is basically like Bitcoin actually it's like a distributed system right you get the same copy of the entire repository with everything the metadata the history the entire tree every time someone get clones something he has the entire history like anyone else whether that's GitHub Git lab any platform that it sits on including your computer you have the entire copy so if all the other copies are removed deleted scratched and you have your own copy you can revive everything else right so in that sense it's like a Bitcoin ledger it sits everywhere it's completely distributed there's no one source that if that's gone everything else is gone and beyond that like I said there's a huge history what I mean by huge from the first comment to your present unless you've made changes to the history which usually it's something you don't want to go to unless there's a very good reason which I'll speak to in a minute the entire history of changes is recorded in your tree while you don't see that because obviously you made changes you've made the condensed code additions code removals deletions of lines and strings and whatever you made the entire history of changes is still there what I'm getting at is a lot of times at least in my case I've seen people commit keys and changes and sorry two changes they've committed secrets and keys and sensitive data that shouldn't be part of the system and then you find it whether with a tool or with your own eyes or in a PR review and then you ask them to remove it and then usually the unexperienced ones we just go no worries I'm sorry I'm really sorry for the commit that I made I'd either revert it or just delete the string and commit it and that's all fine there you go it's gone but it's not really gone it's still in the history forever that's something to understand about the nature of giving entire history is there the tree is there wherever it's being cloned and retrieved it's there and it will only update itself in the next time that someone pulls and makes changes to it so that's one thing to understand and I think it's very important and the other is if you do want to remove from the history there are all kinds of methods my favorite one is using a tool sorry that's called the BFG report cleaner do you know that one I'll tell you a little bit about the other sessions I think but I think I mentioned it a lot so I'm just saying if you've committed something sensitive you need to remove it from the entire history one way to do that is use this BFG repo cleaner that tons of other tools that's it that's what I wanted to say okay great it's important also let's say if you made a small mistake let's say okay so if we just just said happen now so you saw one of the developers committing something and they pushed so one thing could be like they can just rebase their you know current commit look so BFG is usually used for changing something that maybe was very older you found out something you know very big or very old in your repository that you want to delete from all the commits yeah and if you guys maybe all girls if you made a small mistake maybe on your latest commit you can just get reset you know head till the one something like that and then your soft commit maybe add some dash dash soft remove the password commit again and get push false to your feature branch we don't push false to production development or whatever okay that's a very important comment and that's just to add the dash dash soft is in order to keep the file that you've changed still in your repository if you do dash dash hard it removes everything including the file so head till the one would mean remove the last commit from my head by the way if you didn't push you don't need to push force if you just committed what you have to do is just reset you don't have to okay so a friend of mine and his name is okay talk me listen listen if you commit too many things that are related to the same commit what you can do and then i'll give you the stage to talk about it because you told me about it so i want to give it to you you can just squash so what is squash what do you mean by git squash what is that uh okay squashing is basically for uh large code basis if you add too many commits i mean i talked about it before how the beneficial it is to use small commits for small changes so it's easy to retrieve what was changed and find it maybe remove it not remove it change it whatever you want to debug your history if you do too many of them it works in the other ways just unproductive in the other way because you have too many of them every small word of every small change if that's a new commit it's hard to go through imagine having a hundred and thousands of these so squash is the ability to literally squash like let's say 10 15 commits which i've made changes do because whatever i want to keep track maybe i wanted to test something so i can squash them together into one commit that makes sense in the future that i've just merged into the whatever master branch or staining branch okay i think the only place that i'm using it at the moment i'm not even doing it manual i think squash is is basically a rebase it's a git rebase feature i'm just using it with github or git lab when i'm merging the pull request so when someone has a set of changes and that's merged into the master branch unless there's a very good reason to i think there's almost never a reason to i just squash everything and just saying this feature was merged into here because the debugging process should have ended at that point you make it that much like you choose that option in the pull request where i like yes yes i'm regardless of how many commits were introduced to this change i want to squash them together into one so that's introduced to the main branch and the reason is that i assume that the entirety debugging process has ended at that point the developer had done some one two three changes he's tested to the best of his ability and now we have a working feature that can be merged and introduced to the entire system and from that point on we can run forward and the debugging process is now takes another level of perspective it's like a higher zoom out where i'm looking at the entire system rather than at a specific feature i hope that makes sense what i'm saying yeah it does so yeah i can give you like a very sad practical example of when i use squash and i think that's like the common use case for DevOps engineers who use git and want to hide their work okay so for example if you want to test the CICD but specifically like not the code but something in the configuration and the runnels and whatever and you actually need to commit and push you need to re-trigel the push event in git you know in your CICD service so just for that example i don't want to pollute the repository and on the other hand i do want to commit and push to you know check the hollow walk flow and how it works so you'll see my commits are like i'm not ashamed of doing like a in the commit message attempt number one checking like they say okay last attempt and then i write like y'all of the you know so i write weird commit messages and after i'm like okay i'm satisfied with just what happened i'm like okay so let's git rebase interactive get back like 10 commits squash them all because my friend almost told me about it and then i can you know git push to my branch git push falls to my branch because i have to push falls right and even if i'm if i'm nice i also delete my my runs you know what i mean so i delete all those attempts if they're like um use this or pointless you know i mean like if i think like this temp was not really something i want to look at it in the you know in the future i'll just also delete the runs so then i get a clean work squash in git and delete my runs can i download place where you think i want to double click on your on your push force um so we talked about how git is a history of your entire changes since the beginning of time which uh often that's how we wanted how we want to keep it because we want this history it it makes sense in a lot of uh in a lot of areas and the best practice is to not ever well not ever but to to be as as strict as you can with making changes to the history rebase like when you rebase stuff you do make changes to the history at some point it doesn't make sense squashing when you merge stuff makes sense but there are all kinds of ways to make changes to the history like delete commits reverting for example is changing the commit but moving forward is removing something by moving forward there are other ways by changing the history like completely removing with rebase for example with interactive you can completely delete the commit from the history just remove the change from the history and that would mean i'm actually taking something that i knew that were uh by the way uh git and bitcoin differentiates right with bitcoin you can't just delete something from the history because it has some kind of change and it's super one it's a chain exactly and if you break some kind of one of the uh one of the persons a chain something's broken and you need to have that well we're not talking about bitcoin that's for another time anyway uh with git you can do that that means you've changed the history and now uh if you push force that changes the history for everyone so that's something to normally avoid and let's make sense but that's all i wanted to say okay so about rebasing the way i do it like for um you know i think history usually well not usually all the time i don't only for my blenches you know only for for side blenches i do find that it makes sense for production staging or you know a main branch that you know a share of the branch i will never rebase also to avoid conflicts because you know sometimes like a common thing that people do is like you walk on your side branch and then you want to you you keep on your work and then you say okay i want to uh be aligned with development so you do you know git pull origin development you pull development and then you continue with your work and then you rebase that's bad so as long as you get out of development for example you do your work you don't sync with it all right if you need to rebase do it now but if you decide to sync with development and then to rebase then that's bad so only if i'm doing like very side stuff you know getting to the side doing my own things not touching anyone else's code i'm fine with it if i sync with development or merge someone else's branches there will be conflicts it will be terrible i don't mind conflicts but not when it's like on a daily basis or like when it's done wrong you know it might happen but like we like to avoid it right we don't like conflicts that's definitely uh by the way in conflicts i have a really cool where to fix them um it's kind of a thing it's not kind of it's a vim plugin i'm sure there's a way to do that with any other idea but if you are a listener that's using vim and you probably i hope you know vim fugitive by tinfok one of the famous plugins to use git anywhere so that's basically letting you run git commands from your id you don't have to actually go back to if you're using some kind of UI or using the CLI that kind of allows you to use your id to git add git commit git push git everything but it also has a tool to manage git conflicts so if you've merged something and there are conflicts now it can add like it opens your code in the middle and then the two different changes to the right and the left and then you can just scroll through and decide which one of them do you want right because the conflict is basically you have your own working copy and then there's the head and then there's the something that needs to be merging to it so you can pick whatever change you want without all those weird lining in and the machine annotations for the changes that's it cool i use visual studio code for that i enjoy the well can say enjoy but it's okay you know i like i like doing the conflicts you know when i do git pull origin development or something it's nice so i guess it's on i gotta see all of them um yeah it's like a native tool you just git pull origin then you see the different stages and you can say uh acceptable and changes except incoming changes keep beautiful that's what i'm talking about yeah great yeah so it's nice and uh i think uh that is that is it for now omele so we need to move to the corner of the week are you ready for the corner of the week definitely let's do an effect okay so we are now in the corner of the week and what was your experience technology or anything cool you want to say that happened so i'm actually linking to the to this episode i'll talk about something uh around git it's a cool sub command in git that lets you debug the bug the history what do you mean by that let's say you've written something and you found out there's a bug in the system not because of the last change because there's there's just a bug and you want to eliminate it and it's hard to find but you're trying to find the commit that introduced it to fix that but you need to go back in history and that's usually hard so git has a command that's called uh bisect i think i'm i hope i pronounce it correctly so git bisect bi sect let's you it kind of opens a binary tree in the in the under the hood and there's a binary tree and then you can just go right or left so the way it works if i remember correctly you run git bisect and it opens a commit and it tells you do we have the bug here was it already introduced if you say yes then it removes that and goes uh to one end if it if you say no it goes to the other end of the tree and try to fix those commits so it either go goes back in history or forward and then you eliminate uh like every time you limit 50 percent like it works with the binary trees until you retrieve the specific commit that had the bug introduced to the system and that's where you can start the debugging process for real either remove the commit or just fix it or uh the way you want to fix it that's a really cool tool that's what i sound school and then you do git a blame find the address of the commit of the author um send the missile and that's it and it's gone yeah exactly and you you fix the bug exactly exactly this forever by the way fix it forever um my experience this week actually not related to git but it's a cool tool maybe for those who use on a little bit with me windows um i found this cool application from 2014 okay it's very very old i think they they just upload a new version in 2017 something like that um which is called NSSM which is none sucking service manager for for windows yeah okay so if you want to let's say okay if you want to install an agent just like you do in Linux or any other logic so whatever you are a new next system so you can do that also for windows if you use NSSM NSSM yeah and you just tell it okay listen i want you to take let's say it's a Python script script okay you use NSSM you tell it i want to create this service which runs this Python script and then the Python script runs all the time even if you restart the machine just like it's a normal service would so that's a very cool tool that i found out about this week and i worked with it a lot and yeah so that's my new love NSSM i think okay so thank you everyone on it can you just i know it's a podcast but i just want people to see the church you know behind you because it's getting so yeah so i'm i'm climbing in Catalunia right now and i'm sitting and there's a church i really wanted the beds to go off during the podcast but we didn't get that so there's the chin you see yeah there's the church right behind me we we can do that if you want right i mean you're great that's it i think with your jayjoo brother yeah okay so thank you everyone thank you we'll see you next week we'll probably also talk about not next week but we'll have another session about get because we must you know it's also get ups and stuff yeah yeah we were just getting started with it for sure it's just the basics okay so bye thank you guys see you next week bye giao