Vlad Budnitski: become a better developer with version control 

Peter Dalmaris: [00:00:00] Hi everyone, and welcome to another Take Explorations podcast episode. Today, I have the pleasure of talking to Vlad Budnitski. Vlad is a passionate software developer and engineer with experience in a broad range of cutting edge technologies.

Peter Dalmaris: [00:00:16] Vlad has been working at various high tech industries and companies such as Mobileye, an Intel company that develops vision technology for advanced driver assistance systems and autonomous driving. He was part of the research and development team at a cyber startup that specializes in cyber threats detection and classification of fake news for social media.

Peter Dalmaris: [00:00:40] In recent years, Vlad decided to help others learn computer science as a lecturer and a teaching assistant in various computer science and electronic engineering courses at HIT, the Holon Institute of Technology, in Israel. In addition, Vlad is the creator of two popular online courses on Git and the C Programing language.

Peter Dalmaris: [00:01:03] In this interview, we’ll be talking about Vlad’s technology adventures, notably Git, source control, and related tools. Hi, Vlad, thank you for joining me. How are you today?

Vlad Budnitski: [00:01:14] Hi, Peter. Thanks for inviting me. I’m really happy to be here. Always great talking to you.

Peter Dalmaris: [00:01:20] Yeah. It’s been a few months, I think, since the last time we chatted. It was just at the beginning of our lockdown here in Sydney. My hair situation has grown dramatic, as you can see it’s probably my worst hair I’ve ever had in a podcast recording. But we’re persevering to have things for you.

Vlad Budnitski: [00:01:46] You’re still looking good.

Peter Dalmaris: [00:01:48] Yeah. Thanks. My wife, actually we got, like, a machine and she did my afro hair. It actually had grown pretty big with a lot of curls, and it reminded me of me in my teenage years because I used to go like like that. So, it does look a little bit better than it could potentially look. It’s one of the problems of lockdown.

Vlad Budnitski: [00:02:14] Yeah. Absolutely.

Peter Dalmaris: [00:02:16] How do things look like at your side? You’re in Israel right now.

Vlad Budnitski: [00:02:21] So, at this moment, we don’t have a lockdown. But the coronavirus is spreading. People get vaccinated. Some do get vaccinated, some do not. So, you know, it’s a mess also here.

Peter Dalmaris: [00:02:36] Well, for me, I see it as an opportunity to do a lot of work. You know, it’s great for people sitting in front of a computer on the bench and just fiddling around with technology. So, I don’t know, I feel like I’m in my element right now and I feel good actually. I’ve never been so productive before.

Vlad Budnitski: [00:02:58] That’s the most important thing. Yeah.

Peter Dalmaris: [00:03:01] Yeah. So, Vlad, we’ve got about, say, 30 minutes to talk about this topics of mutual interest. I want to focus on Git. And I know that you’ve done a lot of things already in your career as an engineer software developer. But before we get into that, I’d like to ask you to take a few minutes to tell us a little bit about yourself, a bit about your background. And how did you get, technologically speaking, to where you are now?

Vlad Budnitski: [00:03:32] All right. So, I think I will start by telling what did I learn in college and then I will jump right to the practical experience as an engineer, all right?

Peter Dalmaris: [00:03:43] Sure.

Vlad Budnitski: [00:03:45] So, first of all, I started my first years as an electronic and electrical engineering student. And then, after some time, I really have been wondering whether I should be taking this path or maybe it was better for me to choose and to become a computer science student.

Vlad Budnitski: [00:04:04] And it was quite a dilemma, you know, because on one hand, I have already completed quite a few courses in the electronic faculty, and the courses were also pretty interesting to me. But on the other hand, I could see how fascinating and popular the computer science field has become these days. So, it was not an easy decision to make. And I went to talk about it with many people – some of them graduated from one faculty, some of them from the other, and some of them have already been working for a couple of years in the industry – you know, to get the best advice.

Vlad Budnitski: [00:04:49] So, it took me a while to explore everything. And I guess it was the first lesson to start, like, your career right there when you explore things. You do not work, but you ask questions and you get your answers. So, eventually, after all of this research that I’ve done, I’ve decided that I find interest in both of them. And my decision was just let’s take both of them. Let’s roll also into computer science, not leaving behind the electronic engineering.

Peter Dalmaris: [00:05:27] Yeah. So, I find that the cross – sorry to interrupt you, Vlad, but it’s a good opportunity. Because I’ve seen that a lot as well with things that I have seen, choices that I’ve made, but also people that I talked to are usually at the cross between disciplines. In your case, software and then electrical engineering or electronics engineering. Those intersections tend to be very interesting when you combine disciplines. And I think in your case, these disciplines are not that far from each other, obviously, definitely, related to both engineering disciplines.

Peter Dalmaris: [00:06:11] But you can take this further a little bit to the extreme and you can come up with some crazy combinations. Like, what would happen if you put in, say, artificial intelligence and psychology together, what do you get then? I’m just throwing that out because I really like how you decided to do both instead of just specialize in one thing. Sorry.

Vlad Budnitski: [00:06:29] Absolutely. So, definitely it gives you to see the whole picture. You know, like when you take a product and you have some members working just on the hardware, some members working just on the software, but then you can see the whole picture, how it integrates, how everything is connected.

Vlad Budnitski: [00:06:49] Of course, also the number of courses and exams during the study was almost doubled. But I was aware of that and I knew it would be not an easy one. But at the end, I hope it was worth it.

Peter Dalmaris: [00:07:06] So far, so good.

Vlad Budnitski: [00:07:07] Yeah. And during the studies, while I was a student, I was getting these courses from different worlds and I was curious about everything. And one of the projects that I’ve been working on was with this high tech company specializing in the IoT field. And they had this vision, you know, to whom and how the system should be sold. And our goal – as we were yet just a student – was to realize this vision.

Vlad Budnitski: [00:07:47] So, pretty much I think a lot of students here and listeners in this podcast will relate to. It included the development of sensors modules for an existing IoT platform. And we had a lot of technical things that we had to take care of, like how we are going to address the usability, the manufacturability, testability of things, and how we basically should take everything into consideration, including the prices, the pricing, and how we should prepare it for mass production if you like to take this system.

Vlad Budnitski: [00:08:26] And so, we’ve been developing and planning the design of these IoT system, including the development of electronic schemes for different sensors modules. And then, we created the PCB design for each one of them based on some given plastic cover cases that were already given to us that we should fit into them.

Vlad Budnitski: [00:08:50] So, it was, like, my first hardware project and it was really interesting, because at the end, you see a physical product that you can touch, you can work with it, you can see. So, it was amazing.

Peter Dalmaris: [00:09:02] That’s, I guess, the ideal situation for a student to be in, right? I remember especially in my early years in electrical engineering, there was a lot of theory. And even though, like, I was a geek from a young age and I was living my dream, I couldn’t connect my dream to reality. It was just books.

Peter Dalmaris: [00:09:25] What you are talking about is like learning by doing. In your engineering degree, you are producing something real – not just real, but also so connected to the market. So, there are some real life pressures in there to build something that works. And I think it’s an excellent learning experience. I wish I had something like that, especially in the early years of my university career. It would probably accelerate my learning to a high degree.

Vlad Budnitski: [00:09:53] Yeah. Absolutely. Just by learning the theory – yeah. Sorry. Just by learning the theory is not always the best practice. Just like you said, whenever you get your hands on, you learn much faster and for much longer time you remember these things.

Peter Dalmaris: [00:10:11] Yeah. And you said you were part of a team, right? All this work was done in a team environment, correct?

Vlad Budnitski: [00:10:17] Yeah. We had a team, like, two students of the electronic engineering faculty and two students from the computer science faculty. And we were, basically, developing everything related to the hardware and also the embedded software. And they were part of developing the graphical user interface and connecting everything in the Cloud, all the information that has been gathering.

Peter Dalmaris: [00:10:17] So, you had some specialists there as well that would connect those different aspects of building a system, integrates a lot of different technologies together, and you’ve got the market aspect of it, so you need to have some way to build what customers want to buy. So, you had some business people there as well.

Peter Dalmaris: [00:11:03] I’m not sure if there’s more that you want to cover. Was there more time between that, because you were still in university back then, right? And, of course, you have graduated a few years ago. So, what’s happening now? How did your path evolve since university finished?

Vlad Budnitski: [00:11:19] So, it was, like, my last year at the academy, I’ve started working at Mobileye, which was purchased by Intel. And as part of my job, I had the opportunity to work on different automation software development, designing different software automation tests, and taking part in the development of the automation framework, including working with communication protocols such as SPI, IIC, UART, CAN-bus. I’m pretty sure you’re familiar with all of them. And we had a lot of things that we’ve done there, like to make sure that we detect everything so we made a lot of tests in the system set up, in the cars.

Vlad Budnitski: [00:12:12] And right after that, I started working at a cyber defense system startup called Intelici. And it was also one of my greatest challenge I’ve taken upon myself during this time. Because it was a small startup, and, you know, in startup, you have to work on almost everything, all the aspects, all the elements.

Vlad Budnitski: [00:12:44] So, it’s not like working in a big corporation when you have your task and that’s exactly what you’re going to do. So, you have specific tasks that you come the morning and working on this one and this one. In startup, like, “Let’s do this. You have to do this. You have to do this.”

Peter Dalmaris: [00:13:03] I have no idea how to do anything.

Vlad Budnitski: [00:13:06] Absolutely. Absolutely. But you have to say, “Okay. So, let’s go. How do I do it?” And you start working on it and you start searching for how you can do it. But to be honest, I think this approach is really difficult. It’s really difficult. But at the end, once you do that for at least a year, you feel like you’ve got yourself to a whole new level, like you can do it for five years in a different position. But in a startup, you don’t have any other choice. So, you are required to learn more, and to learn faster, and to make things work right away.

Peter Dalmaris: [00:13:49] Yeah. Like, working in a startup is an experience that most people don’t understand because it’s totally different to the experience of working for a company for a long time. It’s like working the fast lane, things just change every day. You can go from boom to bust in a few months. And it’s affecting your personal life as well. It is quite significant.

Vlad Budnitski: [00:14:15] Yes. Definitely.

Peter Dalmaris: [00:14:17] But in the knowledge space, the amount of learning that you can do in a startup in a month is just phenomenal.

Vlad Budnitski: [00:14:24] Absolutely. Absolutely.

Peter Dalmaris: [00:14:26] Are you still with that company now?

Vlad Budnitski: [00:14:28] No. Actually, our roads have been separated during the corona time, you know, difficulties come across. And so, basically, let’s talk about what I’ve done there. I’ve been working there a little bit different than I’ve been doing on my previous projects where I had more hardware. Here, I have been working much more on the software. And I’ve been working here as a system and communication engineer. And, basically, mainly developing and embedding real time software for network traffic reconstruction for a huge amount of data.

Peter Dalmaris: [00:15:17] So, you’re talking about network traffic reconstruction.

Vlad Budnitski: [00:15:20] Reconstruction. Absolutely.

Peter Dalmaris: [00:15:21] And you have to translate that.

Vlad Budnitski: [00:15:25] Basically, let’s say that if we have one computer sending message to the other computer. So, the data is being chunked in smaller pieces. We don’t send a whole message at once. And then, it’s going through different routers and so on from source to destination. And like I’m talking to you, there are plenty of people talking with plenty of other people, sending files, sending information.

Vlad Budnitski: [00:15:55] And our task was, basically, to get these pieces of data that may be coming at different times and in different order. And to organize them to then reconstruct the whole message and to see all the traffic that is going under some, let’s say, area. So, this development was mainly done in C and C++ using the DPDK framework.

Peter Dalmaris: [00:16:22] [Inaudible]. Yeah.

Vlad Budnitski: [00:16:22] Absolutely. And it was really huge amounts of data, so there were a lot of concerns during the development of the system reconstruction. And, also, then how do you save all this information. So, we have to take into account the concerns of working with big data and graph databases.

Peter Dalmaris: [00:16:46] One of your courses is on the C programing language. I guess, you’ve got experience with C earlier, but now you actually said that, “Yes. I think I’m good enough in C to be able to teach it.” Is that project the source of your skills in C?

Vlad Budnitski: [00:17:07] Yeah. Absolutely. It contributed a lot because it made me more confident of my knowledge. But I have two courses, one of them is actually for beginners, and the next one is for, let’s say, intermediate level. Of course, they are not covering the level of this project because I don’t think that a lot of people are looking for these high level. Usually, you are looking for beginner, intermediate. But these fields, I think, that the information they can get is quite good.

Peter Dalmaris: [00:17:42] Wow. Just a quick comment on this, as you were talking, I was thinking about, you know, classification of fake news. My thought is that humans are so bad at this, you know, trying to distinguish what is fake and what is real on the internet, in cyberspace, because of the disconnect that we have from the context of where this information is coming from and who is generating and all that. And we need machines to do this for us, who, I believe, must be much, much better than the average person figuring out what’s real and what’s not real.

Peter Dalmaris: [00:18:24] Very quickly, can you tell us a couple of things about how, say, the average person that is getting the news on Facebook or other social platforms will be able to benefit from such technology. Will it be some kind, I guess, of mark on a post produced by the artificial intelligence saying “Beware. This may be fake news”? Is it going to be more subtle? Like, how do you see this coming out into the world?

Vlad Budnitski: [00:19:02] To be honest, I can tell you one thing. We can say for – how to put it? Let’s say, it’s really difficult to put this feature, like, it can be a fake news. Because every argument that anybody makes can be a fake news. So, the question is how can you classify and how can you be more sure that this is more real than it’s fake?

Peter Dalmaris: [00:19:38] So, there are techniques to check the credibility of the publisher itself. So, it’s something that you can learn over time. If the publisher gets his information and also he asks a lot of people to reshare it, so what happens then? You can see the full graph and you can apply different algorithms to see that. But you have also to compare it with different sources – how do you say it? – relying sources that you can rely on them, like trust sources.

Peter Dalmaris: [00:20:14] Reliable sources.

Vlad Budnitski: [00:20:16] Reliable. Sorry. Yeah. And then, you start comparing and building this machine over time that will be able to say if somebody wants to make some fake news, maybe this propagation of the fake news will be a little bit different than somebody else. So, it’s really hard to say 100 percent, yeah, that’s fake. No, that’s not fake.

Peter Dalmaris: [00:20:41] It work with probabilities then. It’s just thinking of something similar to page rank, so Google’s ranking algorithm for fake news. I wonder if sometime in the future there would be some kind of fake news classifier.

Peter Dalmaris: [00:21:04] You go to your website, it’s got a search bar there, you put in some kind of URL that identifies the news that you want to examine and classify, and then your website powered by your artificial intelligence is going to say this news item has got this probability – it could be a number – of being fake and this one of being true.

Peter Dalmaris: [00:21:33] And it can actually explain the source of this classification. These are the sources that are cited by this article. This is the credibility of the person who wrote it and so on and so forth. But I could see how that would work. It could open up a whole new can of worms. But I think technology can play some role there to get us out of the mess.

Vlad Budnitski: [00:22:00] Absolutely. Especially now, I think if we even take it to the next level, I’m pretty sure all the listeners are also familiar with Deepfake. This is something that it’s also coming in really quick pace. And I think that, also, we should be considering how we can stop that. Because, like, I can make a conversation with you and it’s not even me. So, what then?

Peter Dalmaris: [00:22:32] It’s crazy. Like, 20 years ago, maybe 30 years ago, as I was growing up, that big danger with nuclear weapons and that the bomb will kill us all. And, now, it’s just all this misinformation, fake news, et cetera, which can destroy societies potentially just as bad. I can’t compare, but just as bad as nuclear war. But it’s just how things have changed is just amazing. Technology is the problem. Technology is also the solution to solve the problem, perhaps.

Vlad Budnitski: [00:23:09] Hopefully.

Peter Dalmaris: [00:23:09] Totally that’s a huge discussion, maybe we can do another discussion on this topic another time. I’d like to switch to the Git now. But before that, just a quick one, Vlad. You are now a teacher, of course. But you’re not just an online teacher. You also teach at university. I wanted to ask you why did you decide to become a teacher or an instructor? You seem to be busy enough anyway. You wanted to become more busy for some reason? What happened there?

Vlad Budnitski: [00:23:48] To be honest, during my first year in college, I was not the smartest kid in class. And I had no technical skills whatsoever. And everything was, like, really difficult for me. And I think that because I have been through this process of learning – let’s call it – the hard way, I’ve decided that I want to share my knowledge in a very, very basic approach that almost anyone can understand.

Vlad Budnitski: [00:24:23] Because people that do not come from this sphere of technology, they have a really hard time at the beginning to understand even the basic things. So, I think that I learned how to simplify these things for, basically, everybody. So then, I’ve been thinking with myself and I thought to myself I can go and work for another company and work on some other big project. But on the other hand, I can also try to combine a couple of things and, basically, to teach the next generation and to help them not to have this struggle like I did.

Peter Dalmaris: [00:25:08] Like, make it easier for them. I sympathize with that. That’s how I felt as well during school, we just scrape off passing most of my subjects. I had a couple of subjects I was really good at, so I didn’t really worry. I didn’t have to struggle that much. But, yeah, it was a big struggle. And like you, I felt that I really had to dig deep into anything that I had to learn in order to pass exams.

Peter Dalmaris: [00:25:34] For me growing up, it was like exams was the thing that caused me the most stress, so I had to be very methodical. As you were talking, I was remembering those struggles as well. And, yeah, that do produce a method.

Vlad Budnitski: [00:25:58] Usually a lot of people who work at the teaching industry, they had some hard difficulties when they were learning themselves.

Peter Dalmaris: [00:26:11] Great. All right. Yeah. Thanks for that. Let’s talk about Git now.

Vlad Budnitski: [00:26:16] All right. Let’s do that.

Peter Dalmaris: [00:26:19] I think a couple of weeks ago, I also put a notice in our Makers Club for people to ask Git related questions ahead of your interview. So, I’ve got a couple of questions from them. But let’s get started with the very, very basics. What is Git?

Vlad Budnitski: [00:26:42] I think that before talking about what is Git, I would like to refer to what is a VCS, okay?

Peter Dalmaris: [00:26:49] Yes. Yes.

Vlad Budnitski: [00:26:50] And because Git is a type of a VCS. We have different types of VCSs. But VCS basically stands for Version Control System. And whenever you work on some project, even if you do it on your own or with your team, it’s not the best practice that you have some file and you save it. And then, later day, you save it as file version 1.1, 1.2, 1.3. Like, okay, so what’s going on here after a week? You try to find out what have you been working on this version and what’s going on there.

Vlad Budnitski: [00:27:30] And not to mention the fact that it’s really difficult to keep track of every change that you make, you cannot collaborate with other people. Because even if you put your file, like you put it on Google Drive and I give you access to this file and I also work on these file, so you change one line and I change the next line. So, everything is okay so far. But if we are both working on one and the same line, it will be a total mess.

Vlad Budnitski: [00:28:00] So, a Version Control System basically keeps track of the development process of your project of different files that you are working on by making these – let’s call it – snapshots of the project and writing down an associative message of “I’ve done here one to three. I’ve done here this one and this one. We’ve modified this one and this one.” And it basically documents all the changes of your project.

Vlad Budnitski: [00:28:31] And what’s, basically, great about it is that, by using it the right way, we can work with a lot of people on one and the same project without making things to explode. So, that’s basically Version Control System.

Vlad Budnitski: [00:28:52] And Git is, I think, the most popular Version Control System. It is a distributed one. And, basically, you can start working on this – and I think it was one of the first questions – we will refer to it. Where is it? Where is it? Where is it? One second?

Vlad Budnitski: [00:29:12] Yeah. So, the first question was asked by Patrick, right? So, he said that he was facing the following problem with Git and GitHub. I will read it out loud. Is it okay with you?

Peter Dalmaris: [00:29:24] Sure. Yeah. Go for it.

Vlad Budnitski: [00:29:26] And he said that, by mistake he uploaded his entire project to a GitHub account. And he wanted to take it down and upload just a portion of it on GitHub and not the whole project. And he asked, how can it be done. So, to answer these question, basically just for our listeners, there is Git which allows us version control of our project.

Vlad Budnitski: [00:29:54] And there is also GitHub. And it’s not an extend version of Git. So, GitHub, basically, stands for a remote Git repository, where you can host your repository. Basically, the repository, think of it as just some place where all the magic of saving the history and documenting all your changes of the project happens. That’s where everything is stored.

Peter Dalmaris: [00:30:31] Yeah. Sorry to interrupt you here, Vlad. So, in my mind, I’ve got my code of my project. It could be one file or ten files, let’s say, with a CPP extension or an RB extension, or it doesn’t really matter. So, my project is composed of a number of files. And when I introduce Git in it, essentially, I introduce a tool that will manage any changes that I introduce to those files.

Peter Dalmaris: [00:31:01] So, a change could be opening up file one.cpp and changing a bit of text in one line of code, saving the file. Now, there’s a change there. Git will detect this change and then it will store this change in its repository, so the file is there. But alongside that file on my project managed by Git is the Git repository, which is a bunch of files. But I can really put them in a text editor to open and read because Git is in charge of reading and writing into that repository.

Peter Dalmaris: [00:31:41] And, now, that repository lives on my computer. And only I can use it because only I use my computer. But if I want to share it with other people, it could be one or it could be a billion people, then GitHub is available, which is like an online repository where I can upload my local Git repository. And then, through permissions that I can control, people have access to it and they can do various things with it, again, depending on my choices in the kind of access privileges that I set on my GitHub project account. Right?

Vlad Budnitski: [00:32:23] Absolutely. Absolutely. You put it exactly like it should be done in the books. Yeah.

Peter Dalmaris: [00:32:29] It’s changed my life, so yeah.

Vlad Budnitski: [00:32:31] So, you have your local repository, just as you mentioned. And when you create this local repository – let’s call it – under some folder, you decide what files Git should keep track of. So, you specify what files Git should keep track of. And in the repository itself, all the magic happens. It keeps track of every file. What has been changed, what you documented.

Vlad Budnitski: [00:32:56] And then, you push this local repository to some remote repository. You do not have to do it. Actually, you can make something work out just by keeping it locally and letting others access it, but it will be just a message.

Vlad Budnitski: [00:33:15] So, usually what you do, you go to GitHub, for example, or GitLab, you put your repository out there. And then, basically, other people are capable of working with this repository. They can download it. They can modify it. They can suggest their changes. And, basically, return it to you or to who is in charge. And then, you can merge different changes from different people and to proceed with the development of your project.

Peter Dalmaris: [00:33:46] So, other people can implement changes to the online repository. And those changes sit on the online repository until I, somehow, pull those changes onto my local repository. Now, I’ve got the changed files that someone else has contributed. But if I don’t want to accept those changes, I don’t have to, right?

Vlad Budnitski: [00:34:14] Yeah. Absolutely. Absolutely.

Peter Dalmaris: [00:34:15] I will also have control of what kind of changes I, both, push to the online repository or pull from the online repository.

Vlad Budnitski: [00:34:26] Yes.

Peter Dalmaris: [00:34:26] So, is this where Patrick’s answer comes in? The fact that when it comes to sharing a project, it’s not all or nothing. You don’t either have to share the whole lot or nothing at all. But you can say, “I’m going to share this commit or this branch.” You could talk about what those things mean. But I can share part of my project, not all of it.

Vlad Budnitski: [00:34:56] Yeah. So, if I got it correctly what Patrick asked, I think that he referred to the fact that he has a project of, let’s say, 20 files. And he does not want to upload or to push to GitHub all of these files. And he wants, like – I don’t know – two or three source files to push them to GitHub.

Vlad Budnitski: [00:35:22] So, the thing that he needs to understand is that, first of all, he can ignore, Git provides a tool called .gitignore. That, in this file you can specify what exact files you don’t want Git to keep track of. Because when you’re working on a project, you don’t have to keep track of all the files.

Peter Dalmaris: [00:35:46] Sorry. Like, an example here of something that you don’t want to track is a file that contains passwords, like Wi-Fi passwords for example. You don’t want that to ever end up online.

Vlad Budnitski: [00:36:02] Absolutely.

Peter Dalmaris: [00:36:03] So, you use that gitignore file to ignore anything that contains a file name, something password something, you can use a wildcard.

Vlad Budnitski: [00:36:13] Yeah. That’s also what you can use. But, usually, what you also use, for example, if you develop some program and you do the building step, you create the build process for your machine. So, it doesn’t make any sense to keep track of these file because it will be only applied to your sphere and to upload it to GitHub.

Peter Dalmaris: [00:36:35] It’s the files.

Vlad Budnitski: [00:36:35] It’s just the source files. Yeah, you keep just the source files and track it by Git and not the build. So, you provide the tools for somebody to download all the source files and to build it based on their needs. But there is no reason as to why you would do that.

Peter Dalmaris: [00:36:53] So, I guess is your suggestion for Patrick to learn how to use gitignore is one possible solution?

Vlad Budnitski: [00:37:04] That’s one possible solution if he does not want to upload some specific files and to make them part of his repository. And I looked at this question once again, maybe what he meant is that he does not want to make the last commit. So, if that’s the case, you can revert back to the previous one. I’m not sure exactly because this question we need more details about what he asks.

Peter Dalmaris: [00:37:35] Yeah, it’be good.

Vlad Budnitski: [00:37:37] So, I hope it gives the answer that he was looking for.

Peter Dalmaris: [00:37:41] Patrick, if you need more details, I guess you can go back to the discussion in the Makers Club and just contribute more information about your specific situation so that you can get a more qualified answer from Vlad. But start with gitignore.

Peter Dalmaris: [00:37:58] From my experience, because I had to do this recently for one of my courses, I had an IoT project which, of course, contains passwords, info, and keys for online services. And I had a separate branch that I was working on that contained those more private bits of information. But I would only push to GitHub a separate branch, which I have labeled as “Okay to publish”. It does not contain any passwords.

Peter Dalmaris: [00:38:34] And, therefore, my Git repository may contain, say, five branches. But one of them is private and doesn’t go out on an online host. Everything else can. So, I thought that was a good way to also manage private information and still manage the private information with Git. It’s just you only push what you want to push and not everything else.

Vlad Budnitski: [00:39:01] Yeah. I think that’s finished. Yeah.

Peter Dalmaris: [00:39:05] Okay. Maybe you look at Holger’s question as well, Vlad.

Vlad Budnitski: [00:39:10] Let me open it up.

Peter Dalmaris: [00:39:18] So, Holger is asking about patents – interesting – work patents. For example, I would ask you this, Vlad. Is Git an overkill for a one person project?

Vlad Budnitski: [00:39:40] I think that what he asks is, is there any suggested rules to follow when using Git? And, actually, that’s a really good question, because there are so many things you can do with Git. It’s not just, like, something that is either you do it, it’s true or it’s false. Most of them you can do it one way or the other. So, we can achieve the same outcome, me and you, by doing totally two different things in two different ways.

Vlad Budnitski: [00:40:14] So, the question which one of them is better? Well, it depends on a couple of factors. So, first of all, whenever you’re working on your own, you can decide for yourself what is the process of development you’re going to stick with. I mean, you can invent yourself just the steps you want to follow during your development process. Different – I don’t know – naming conventions.

Peter Dalmaris: [00:40:41] I later find that in the beginning, when people are new to technology, they do depend on our suggested methodology as to learning the ropes. And then, once they get comfortable with it, they start to develop their own methodologies. You know, they may still relate to what they learned. But, eventually, the taught methodologies tend to be modified in a way that they fit better with whatever the person is doing.

Peter Dalmaris: [00:41:15] So, with Git, for example, for me, when I was learning, I did have a book and it gave me the pattern of work where you start with Git init. You create your repository, you put in your ad, your tracked files in their, git at dot.

Vlad Budnitski: [00:41:35] I never used that.

Peter Dalmaris: [00:41:35] And then, your first commit – yeah. No. So, in the beginning, even if you do it the wrong way, at least you’re doing something that helps you get to the next step. But all that eventually changes, like you start putting more. I guess, if I use a chef analogy or a cooking analogy, you learn about more ingredients and more techniques to make soup or salad. And you don’t keep repeating what you learned in the early days.

Peter Dalmaris: [00:42:12] So, I think maybe this is what Holger is asking. You always learn Git as a one person in the beginning. So, I’ve got a little project myself. I don’t collaborate with anyone. And then, over time, you start expanding and your projects get bigger, still using Git to manage them. And then, you have collaborators and then you’ve got online repositories. And I think he’s asking how does that change over time? Is the practice and the process that I followed when I was working on my own similar situation?

Vlad Budnitski: [00:42:43] Absolutely. Absolutely. Absolutely. If you’re working with the team on a project and everybody does what he wants, this whole thing will soon become a complete mess that will probably start your project. The good thing, it will stack it for a while, otherwise nothing will work at all.

Vlad Budnitski: [00:43:02] So, you can’t manage versions and collaborate on your project with a team where there are no rules and no guidelines that you should follow, that all the team should follow. That’s why when you start the project, you talk with your team and you decide what should be the strict rules and what exact flow you are going to follow and work with. And once all of your team is on the same page and they know what are the strict rules, then this way you will be able to prevent many future optional problems.

Vlad Budnitski: [00:43:41] So, if I want to summarize it, if you’re working on your own, probably nobody going to find out if you’re doing something right or wrong. So, as long as it works for you, maybe that’s good enough for the start. But, still, I highly recommend you taking a look at more familiar flows and common conventions, and then decide which one of them suits you the most. Do not reinvent everything from scratch.

Vlad Budnitski: [00:44:13] And if you’re working with a team, then there are a couple of common pretty much simple flows that I do recommend you to check, at least at the beginning, and also later on. It’s called the Git Flow, the GitHub Flow, and the GitLab Flow. So, decide what’s best for you and your team and then proceed. Just make sure that everybody is on the same page. That not everyone is developing how he or she wants.

Peter Dalmaris: [00:44:47] So, I guess both for personal projects, it’s good to think about those things and put some thought into your process. So, for example, some questions that I have to deal with – and my answers to those questions change over time as well. I’m going to say that, like, it’s not a fixed choice. It changes.

Peter Dalmaris: [00:45:11] For example, how often should I commit the changes? Should I wait for the whole new piece of code to be done and tested before I commit it? Should commit intermediate segments of new code? Should I commit every five minutes, like time constraints there? What should my comments look like? So, when I do a Git log, for example, the comments for each commit come out, should there be some kind of standard for the comments or should I just put no comments at all. And depending on the Git diff, I used to do that.

Peter Dalmaris: [00:45:55] Now, if I put some description there, what else? Oh yeah, branches and experimental branches. And then, tags as well. How should I use tags is another choice to make. What should be in the main branch? Should I have an experimental branch? Should I have a public branch? These are just questions that I ask myself always depending on the projects as well.

Peter Dalmaris: [00:46:25] But over time, I find answers that work for a while and then I adopt again and make small changes to my process. But then, it becomes second nature to use Git as a tool part of my normal workflow. But I guess the workflow that you are talking about, Vlad, those documented, say, in your course, you explained how to use them and they could be a starting point for people that haven’t developed their own process. What do you think?

Vlad Budnitski: [00:47:00] Absolutely. Absolutely. I think that the basics are covered in this course. And, also, people should see that, for example, you said you’ve made different commits with nothing. So, you created a new version of the file and then you just used Git diff to compare between the two versions. And it shouldn’t be this way. You should put at least five, ten minutes, in my opinion, at least, to specify descriptive message of why have you done the changes you’ve made to the project.

Vlad Budnitski: [00:47:38] So then, later on, because the next day you may come, you may work on another thing, and you may forget why you’ve done it. And to use Git diff and to understand to compare these lines of code, it’s really difficult, it’s time consuming, and it’s not effective for you. It can make you a lot of problems on the road.

Vlad Budnitski: [00:47:57] So, whenever you change something to the project and you want to commit it, don’t use it, also, like, every five minutes. It’s also not worth it. Otherwise, you will get like. Every word, to commit it and say, “I added a word new.” So, that’s not how it works.

Vlad Budnitski: [00:48:16] I suggest every change that you can describe of why you’ve done it, then do the commit, complete it. Do the commit and write a descriptive message that even if your colleague is going to look at the project, and even if you’re going to look at this project in a month from now, you will understand exactly why you’ve done it.

Peter Dalmaris: [00:48:37] So, treat Git comments and log comments as you would treat in the comments that you put in the source code of your program. They’ve got to be meaningful because they will help you at some point in the future. And most of us need that help in the future when we revisit old code.

Peter Dalmaris: [00:49:04] All right. Vlad, maybe go towards wrapping up our discussion, there’s one question that I have, again, of course, related to Git, and that is Git tools. Of course, you’ve already mentioned a couple, you mentioned GitHub and GitLab, they both are repositories and quite popular repositories.

Peter Dalmaris: [00:49:32] Are there any other tools that people should be aware of? It could be, like, tools that are running on your desktop, a visual way, for example, to examine a repository and look at differences between files. It could be some kind of local network Git server. If you don’t want to send your stuff to the GitHub, maybe you can do it locally, I don’t know. Is there anything that you’d like to recommend here?

Vlad Budnitski: [00:49:58] Yeah. Absolutely. You can start by working locally. You don’t have to go remotely and to share your project if you’re not working with additional people on it. And if you’re still maybe a student working on your assignment. So, you can start locally, just download and install Git, and then you will be able to use either the Git Bash, which is a nice little command line interface that you can use. Or you can use the Git Gui, some find it more convenient, so it’s like a graphical user interface for adding files and removing files, reverting back, committing, and so on.

Vlad Budnitski: [00:50:39] But, basically, in both of them you have to understand at least the basics of what is a repository, how you keep track of files, what are the different areas that the file can be in this process of keeping versions. And it’s really not complicated. I think about a couple of hours are pretty much enough to get yourself started.

Vlad Budnitski: [00:51:02] Basically, it will improve your whole process and experience of development and working on your projects like from here to here. Really, you will enjoy it because you will be able to move back to previous versions. You will be able to work and suggest your new changes to yourself.

Vlad Budnitski: [00:51:20] And, basically, after you’re done with your project, you will be able to see, like, you’ve specified the Git log, all the process of what I’ve done here, here, here, and here. You will see it over time and you will be able to say, “Wow, that was good.” Or maybe you will say, “Here and here, I can improve. I could have done it differently.”

Peter Dalmaris: [00:51:42] Yeah. So, it is really a step up in your development skills you’re working from anything to do with software and firmware. It’s a step up in your toolset.

Peter Dalmaris: [00:51:57] Just last one on tools again, GitLab and GitHub, the two most popular online hosts. Are there any real differences between those two tools in your experience? Does it matter which one you choose?

Vlad Budnitski: [00:52:18] Basically, it really depends on your needs, what you’re looking for. If you’re looking to start something very basic and just to use some remote hosting repository, so you can go with GitHub. It’s more common. It’s used by more people. And you can start working with it. And, also, it was acquired, I guess, three years ago by Microsoft for a couple of billion dollars.

Vlad Budnitski: [00:52:48] So, there are more projects as far as I remember or much more projects on GitHub that you can collaborate, so you can basically go to GitHub and search for different projects based on different topics, and you can start downloading it, working on it, and suggesting your changes. And, basically, to let other people also work on your projects. So, something like that, I would recommend GitHub.

Vlad Budnitski: [00:53:17] And if you’re working on some, let’s say, more sophisticated project when you need to get all the DevOps things and you need continuous integration and continuous delivery, although, you can do it also with GitHub, but you need to add different things that can make it a little bit more complex because GitLab provides you kind of built-in these continuous integration and continuous delivery support using all these DevOps things.

Peter Dalmaris: [00:53:51] So, GitLab is Git hosting plus a bunch of other things as well that make developer’s lives easier. GitHub can do it, but you need to tie it up with other services as well.

Vlad Budnitski: [00:54:04] Yes. Yes. Yes. Some services you need to tie up to make these connections. That’s also fine, people do that and we do it. So, it really depends on your needs. I really recommend, if you want to compare between these two, just use GitLab for a couple of hours, and see what fits you the most, what you’re looking for. Write down the notes what GitLab gives you, what GitHub gives you, and how, basically, you should be taking this into account.

Peter Dalmaris: [00:54:37] Yeah. I find a lot of people are familiar with GitHub plainly because of how many open source projects are hosted on it. In the Arduino world, for example, pretty much all of the libraries I will ever need are going to be there. KiCad is similar, although KiCad is actually on GitLab, I believe. But a lot of its libraries are on GitHub too.

Peter Dalmaris: [00:55:01] So, just as an end user, people become familiar with GitHub first. And then, as the needs change or increase, they may look at other options as well.

Peter Dalmaris: [00:55:12] All right. Cool. Vlad, any last advice that you want to give to people that are listening to this, again, relating to Git? Actually, not. I’ll open it up, whatever you want.

Vlad Budnitski: [00:55:26] Yeah. So, basically, I just want to clear some misconception that some of the listeners may have, is that, the Version Control System tools are not solely used for software development. They can also be used for hardware development. So, I know that Altium has a built-in Version Control System connected directly to Git and all that. Also, the KiCad, we can also use it with Git.

Vlad Budnitski: [00:56:02] So, it does not necessarily have to be software projects because the whole idea of version control is to control the versions of your development. And some files are more easy to keep track of. Some files are less easier to keep track of. But, basically, at the end, we can aim and track all the files both in these spheres or the other.

Peter Dalmaris: [00:56:29] So, think of Git as a Version Control System for pretty much anything that can be on a computer. I use Git for some of my books just to keep track of changes in some of my books. And so, a whole service online called Git Books, it’s going to Git Host backend with a user interface on the front for people to write books. And there’s a lot of examples in different industries.

Peter Dalmaris: [00:56:56] All right. Thank you, Vlad. How do people get in touch with you if you’re open to that sort of thing?

Vlad Budnitski: [00:57:05] Yeah. I think that LinkedIn is the best way. LinkedIn and maybe an email, I will send it to you over.

Peter Dalmaris: [00:57:14] Yeah. You are also on our Makers Club, so people can talk to you there.

Vlad Budnitski: [00:57:18] Yeah. Absolutely. Always. Always.

Peter Dalmaris: [00:57:21] Okay. Great. Well, I feel like we left a lot of things on the table to discuss another time relating to technology and some very interesting things that I’m personally curious about. Your classifier systems for fake news, I would like to know more about that. Maybe we can catch up again another time.

Vlad Budnitski: [00:57:43] Absolutely. Sure. I would love that.

Peter Dalmaris: [00:57:45] Perfect. Well, thank you, Vlad. It was a pleasure to talk to you today.

Vlad Budnitski: [00:57:48] Thank you so much. You, too. Thank you. Thank you. We’ll be in touch.