Git basics: save your work like a pro with commits and branches

本站添加: 2026-06-01

[00:00:30]Hey guys, I'm waiting for more viewers to come in.

[00:01:52]Hey guys, I'm waiting for more viewers to come in. Hang on with me.

[00:02:08]Are you guys excited for today's session? Drop a yes in the chat if you guys are.

[00:02:17]Hello. Hello. Hello, Vicram. Hello, Kria.

[00:02:27]Okay. Uh so do you guys know what the session is about today? It's about git basics and how you can use git to save your work like a pro.

[00:02:39]Okay, more people are dropping in.

[00:02:45]So um let's start the session. Type a quick one in the chat if you think that you are scared of putting in git commands in the terminal. And if you think that uh type a zero in the chat if you think that you are good at terminal and you're quick, you're pretty confident about it.

[00:03:12]Okay, more people are coming in.

[00:03:16]Okay, I see one uh from Prashant.

[00:03:22]I see a zero. Oh, uh someone is scared of merge conflicts. Okay, more ones.

[00:03:30]Okay, don't worry. So, um regardless of all the ones today, you are um by the end of the session, I promise you that you will all be adept at kit basics. And those who are new here, you can learn with me. And those who already know Git, I saw one zero. Um, you can revise along with me. Okay. So, let me share my screen.

[00:04:01]Okay. So, uh, one thing guys that everything that you're going to learn today is also available on the official JSOW contributor guide book. I'm talking about this guide book that was shared earlier with you guys.

[00:04:14]Um and if uh you guys uh haven't been able to access this guide book, we can drop it again in the discord chat today.

[00:04:23]So um if any of you would like to revise the concepts that we're going to discuss today later on you can refer to this contributor guide book especially the sections 2 3 4 and 9. Um okay so let's jump into the step one now. So first you need to uh configure git on your computer and um to do that let me open my terminal.

[00:04:54]Um to check whether git actually exists on your computer, you need to type this command in your terminal.

[00:05:05]And if you see a version number show up like it does in my terminal, then that means that you're good to go and git needs to know uh your identity further.

[00:05:15]So you need to configure it properly and let's see whether it's configured uh using these two commands.

[00:05:44]Give me one second, guys.

[00:07:27]Sorry guys, I had an issue so I had to go. Yeah, let me share my screen again.

[00:07:39]Okay, so you need to check whether uh your git is already there on your computer. you did that through uh git version and now git needs to know your identity. So you're going to check whether git knows your identity through this command. Um so your name should pop up like this. Next you're going to check whether your email id is also configured properly.

[00:08:18]Yeah. So if your email uh uh pops up like this then that means that git knows your identity properly. And uh one thing you should note here is that uh your GitHub account uh should be exactly the same uh sorry the the terminal email should be uh matching with the GitHub account email exactly. This is important because if they are different then uh GitHub will not be able to verify who exactly wrote the code and your commits will look completely anonymous and then the system will not be able to check or track your leaderboard correctly and that's how your points will not sync in.

[00:08:59]Okay. So now that we are um now that we have configured kit properly let's move on.

[00:09:08]So this is the step two. Um let's talk about writing professional comments. So when you save your work online on GitHub uh try not to use generic messages uh for committing like uh fixed code or uh make changes. Let me demonstrate the same to you. So let's say if this is my git terminal and I'm trying in uh try not to put in commit messages like fixed code or um made changes.

[00:09:44]These kind of commit messages they do not look very professional. uh it makes you look amateur and makes the project admin's job very hard because they don't understand the context of what you actually edited in the code. So instead what we uh recommend is using a clean and standard format. Uh a clean and standard format would be uh putting in the type name then a short description of the commit uh that you're making along with the issue number like this. Okay. So when I say types uh what type of uh commit messages can be there? Um, so if you're fixing an error or bug in the code, you lead the type with fixed.

[00:10:32]For example, fix uh maybe you fixed the toggle button. So changed the toggle button.

[00:10:42]That is how you uh explain what kind of what kind of commit it is and you give a description of it and then maybe you also put in the issue number. Since I don't have an issue number right now, I'm not putting one.

[00:10:54]Next is uh the feat uh type. The feat refers for adding a new feature. Maybe you added a brand new component or feature in the code. Uh maybe you brought in a new button in the front end. Um or uh you created a new API endpoint. So uh that is how you put in the word uh in that cases uh you put in the commit message of feature. Uh next, sometimes you can make changes in the text files or the comments or the read me. That's when you put the commit message as docs and then you give um a brief description of what exactly did you change or add in the docs. Okay. So now that we are done with understanding uh how to write a professional comets uh let's move on to how u the real JSO workflow uh what kind of JSON workflow are you dealing with here um since you're all going to be contributing to open-source projects there are three steps to contribute safely there's folk clone and branch okay so let me demonstrate these three steps to you by opening a real opensource repository Um let me open. Yep.

[00:12:12]Okay. So this repository is called account safe and it is listed on the DSO website as well. Earlier I had raised an official issue in this repository. Let me show you.

[00:12:27]So I had raised this issue in the repository and you can see that the project admin had assigned this to me.

[00:12:34]So even though it is assigned it to me, I cannot write code directly in the admin's original repository. And this is because public projects are logged to protect them from unauthorized changes.

[00:12:46]Only the project admins are the ones who can push code here in the original repository. So how can you contribute to this repository? You can fork it. So I will again go to the main section and I'll click on the fork button that you can see here.

[00:13:06]I'll click on create fork.

[00:13:14]And now you can see that um that um yeah this created an exact copy of the whole project under my own GitHub account. You can see my name reflect on the URL as well. Um and this uh I can now safely work on this project uh without affecting the original project.

[00:13:37]Okay. So let me do the next step. Now that we've forked this, we can now clone this project.

[00:13:45]So I'm going to run the command get clone.

[00:13:51]Um, by the way, I got this HTTPS link by clicking on this uh code button and then I clicked on this link uh under HTTP.

[00:14:01]Now I'm just going to run this command in the terminal and as you can see uh the download is taking place right now.

[00:14:16]Perfect. So the download is finished now and cloning is complete. Let's enter the project folder now using the change directory command. So I'm just going to write cd and the name of the repository.

[00:14:33]Now we're inside the repository. Um one thing to note here is that you never write code directly on the main branch.

[00:14:40]You always create a new branch for every change. So let's create a professional branch for our issue. Right here I'm going to write get checkout minus the feature async security pipeline because that's the name that I would like to give this branch and um you can name the branch anything uh based on what kind of feature you're introducing or what kind of fixes you're making.

[00:15:13]So we have switched to this new branch.

[00:15:15]Um to clarify why I did this, think of the main branch as the final product and a feature branch as your playground where you can experiment. So by creating a new branch, you keep your experimental code completely isolated and then uh even if your own code breaks, the main project continues to stay perfectly safe and untouched.

[00:15:39]Okay, so let's go back to the slides.

[00:15:45]Now that we're done with the JSON workflow, let's talk about how uh we can fix mistakes and um inspect changes in our repository. So everyone agrees, right, that we can make mistakes while we are working on the terminal using Git, right, Rob? Yes, in the comment section if you've ever made a mistake.

[00:16:12]Yes, Peter, that is uh correct.

[00:16:16]Okay, for all those who are asking doubts, I'll take up doubts later on.

[00:16:28]Um this PDF uh Aani uh we'll be dropping it again to uh today in the discord chat. So you can access this contributor PDF. Don't worry about that.

[00:16:41]Okay, perfect. So again, we've all made um uh mistakes while working with Git, right? So um that's that's all right because Git uh one good thing about Git is that it provides an amazing group of commands that actually I like to call the roll back crew.

[00:17:01]This is the roll back crew that I'm talking about. Okay. So, um let me do one thing now that we're inside uh this project.

[00:17:31]Let me clear this actually.

[00:17:39]Hold on.

[00:17:42]Give Give me one second, guys.

[00:24:34]Guys, absolutely sorry for this mistake, but um my terminal actually crashed and I was not able to type in commands. But um I'm back and let me just open the comm terminal again.

[00:24:50]Yes. Uh so I was mentioning how we can fork clone and branch. So let me do that again.

[00:25:02]Um yeah uh so I had uh taken this uh https link.

[00:25:14]All right. and we were typing in the get clone command.

[00:25:22]All right. Okay. U I had already cloned it. My bad. So, we're just going to move into that directory.

[00:25:33]And now we're in that uh directory. So, now um now what we're going to do is create a new branch.

[00:25:50]Um you can give any name to your branch u uh like like I said earlier based on what work you're going to do. Um and I had also already created a branch. Uh my terminal crashed that's why I was running these uh commands again.

[00:26:08]Uh next let's do one thing. Let's create a mock file for the purpose of this demo.

[00:26:19]So I'm creating a TNV file and um in this file I'd like to paste uh this command I Give me one second, guys.

[00:27:39]Okay. So um like I was saying that I would like to type this in the command line um the contents of the amb file. So I'm just going to put in um you can learn all of these commands uh as you explore git further. Right now you don't have to figure out how to um put on uh content within a file uh from here. I'm just doing this because my terminal had crashed.

[00:28:10]So this is um okay I I'll just clear this for the Okay, let's start a new fresh terminal actually.

[00:28:49]So let's say um uh that we these are the local variables that we're putting in our um local hold on again. Absolutely sorry for this. Um actually I kept running into issues but um yeah so let me share both the screens in split sense.

[00:31:46]Yeah. Uh again going into the directory.

[00:31:56]Um now we can perfectly work here. So I had created a new item and uh within this uh env file.

[00:32:14]Yeah. So within this env file uh I'd like to uh paste this command.

[00:32:23]So we've created this new uh env file for the purposes of this demo. And let's say I accidentally run this command.

[00:32:34]So uh this way I've basically just staged all the files in this repository and I didn't mean to push this env file.

[00:32:42]Uh why? because av file uh it contains your private API keys and your database passwords. So if you push it to GitHub, your automated malicious bots uh on the GitHub will scan and steal these keys within seconds. So um you should never push av file but don't panic here because gear often allows us to undo our mistakes and in this particular case we can undo this uh accidental staging uh without losing our edits to the code by typing the following command.

[00:33:16]Yep. Um follow through with this PPT.

[00:33:19]You can type this given command here.

[00:33:27]Okay. Reset uh minus minus soft head f1.

[00:33:36]So what this command does is that um it makes sure that you don't lose your edits. Uh I haven't lost myv file here but uh it has been unstaged. We can uh check this as well. Uh hold on. So, so you can see that uh the DNB file is no longer there. Uh let's add another file now.

[00:34:29]This is again for the purposes of uh the demo. Um so let's say okay hold on There is.

[00:35:14]Yeah.

[00:35:31]Uh, thank you so much for being so helpful here, guys. But I keep running into issues. Actually, I lost my laptop a few days ago. Uh, let me fix this issue.

[00:42:28]Uh I'm back guys and no more technical issues now. Uh I faced a lot of issues recently but uh here we go as I was telling you guys again. So um yeah so let me uh recount from where we were uh earlier because I think the last few commands have been a blur. So we were trying to add a file called env so that I can uh show you that sometimes we stage the wrong files uh that we don't mean to add on GitHub but uh we do stage them and I was trying to teach you guys how to unstage them and how git can save your work. So, um let me just Yeah. So, now I'll uh run a command to um create a new item.

[00:43:31]Uh okay, let's create a new item uh called env.

[00:43:39]Oh, it already exists. My bad. Sorry.

[00:43:41]Sorry. Yeah. Uh so env, uh let's put in some uh content here uh that files usually have like a port can be 5,000 and some uh Java web authentication uh secret key.

[00:44:16]As you can see guys, I've faced a lot of issues recently and you can just seek uh sometimes get uh works in really big ways as well. But there's always a way to come back from this like I came back right now. And um I've created a TNV file and I'm going to uh add all the files here using this command get add dot.

[00:44:42]But um we not supposed to add the env file, right? You never push files like I said earlier because um it contains your private API keys and database passwords.

[00:44:53]And if you do push that to GitHub then uh there will be certain uh malicious automated bots that can scan it and steal your keys and you don't want that.

[00:45:03]So how do I unstage this now? So if I uh run the function or the command get restore staged env um again let let me run the g status again.

[00:45:37]Okay, there's a safe file.

[00:45:47]Uh let's debug this issue.

[00:45:55]What we can do here is me.

[00:46:29]Okay.

[00:46:31]Ah that is true Peter. Yeah. So sometimes when your app crashes then uh sorry. Yeah. Uh becomes scary. That is true. That is true. Okay.

[00:46:48]Uh how do I So as you can see the file is um the env file is not there anymore uh in the stages and uh I've also added a new file called uh save filet txt and I'm going to add this file.

[00:48:57]Um maybe I want see uh I haven't written any content here and maybe I accidentally added this file. Um going to add this again for the demo and um I'm going to write a commit message uh temporary code. Um this is again just for demonstration purposes. Uh so to fix uh and I'm going to commit this now again this is uh something that I didn't mean to commit. Uh I this was too early. I meant to write more uh content here in this file. So what can I do to unstage this file? I can just run the command get reset soft head.

[00:49:52]And now uh this has deleted my last checkpoint. Uh but uh even though it deleted my last checkpoint, it is still going to keep all uh the content in that file save. Had I written some content in this file, it would have kept all that content and this file save it wouldn't have deleted the content as well. So this command gives us a chance to fix our mistakes or write the commit message cleanly. Okay. Um now let's move to uh the pro inspecting tools that uh I've mentioned here in the slide. Um so I'm going to run this command called get uh difference Okay, actually for that I will have to write certain code.

[00:51:01]Let's do one thing. Um let's maybe remove this line from the code. Okay, now uh I'm going to uh look uh run this command get difference.

[00:51:16]See now it is showing me in red the com uh the code that I just removed from this file and uh whatever else is there in this file.

[00:51:28]So uh basically gives you a line by line breakdown of what all unstaged modifications are there. Uh the plus sign is for the code that is added and minus is for the code that is removed.

[00:51:40]So um using these commands you can have a perfect sanity check uh that you can do to review your work before saving it.

[00:51:48]Um I'm going to add that code again.

[00:51:52]Yeah. Okay. Um now if you would like to see a history list of all the checkpoints on this branch uh to check how previous commit messages were formatted maybe by the project admin or earlier contributors. You can just type this command get log one line and this will give you an entire notebook of all the uh checkpoints that were made earlier.

[00:52:24]And uh while I haven't made any new commit on my own uh these are all the past committed commits that were inherited from the main project repository. So similarly when you make your own commits in the repo that you choose uh from the open source projects available on the gsoft website. uh then if you run this command you can see all the pass commits in a short row uh like this and uh you can verify uh everything is correct before pushing it to GitHub.

[00:52:55]Okay. So before I take questions uh let's look at the one last rule that is mentioned on the slide. Um never push env files. This we've already discussed.

[00:53:07]The second thing second thing I've discussed is you should never run git push force on shared branches. So why am I saying this? Because force push uh it overrides the cloud history. So if other contributors are also working on the same exact branch then force push will delete all their hard work and it will break the repositories. So for playing safe and uh you always just work on your own folk and protect your team's file and you never use this exact commit.

[00:53:39]Okay, you never uh write this commit get push- dash uh force. I'm not going to put press enter because again like I said it overrides the cloud history. Um so now I'm open to questions and um if you um you can write your questions in the chat or if you would also like to reach out to me for doubts or just connect with me here are my socials. Uh you can find me on GitHub and LinkedIn.

[00:54:08]Um let's move on to questions.

[00:54:46]Uh yes, Peter, I'll put my GitHub ID in the chat and if anyone has any questions, you can uh hit me up or uh uh the PDF, right? uh the PDF will share it on discord soon um by tonight itself so that you can uh revise all the concepts that we taught today and um guys I would like to say this again um apologies for all the problems that we came across today um next time I assure you that you'll have a better experience um and thank you for being an incredible sport. Thank you for understanding uh the problem on my side and um I'm ready to take questions if anyone has Uh Peter, if you'd like to connect with me, uh we can uh connect uh on LinkedIn.

[00:55:59]I can talk more there. Uh right. Uh okay. So why git push force is dangerous is because um so when you do get git push force you actually override on the cloud and uh let's say other contributors are also working on the exact same branch then a force push will delete their hard work and break their repositories. Um, so it is always advised not to use this command and to play safe. You work on your own folk and you protect your team's files.

[00:56:57]Uh so Somi uh in the next session we'll be talking more about forks and uh how to do clones and all of that. uh in that we will also uh discuss the merge issue in detail because I know how uh how problematic merges can be. Um person has voted um Are there any more doubts guys?

[00:58:00]Okay, I see one doubt. Um, so get push uh force. Oh, excellent question, Peter.

[00:58:07]Yeah. Uh, get push force is um, fine when you're working completely solo, but uh, it it is still not advised because it can sometimes clean up your personal history or uh, it can rebase completely. Um, so it is not advisable. Uh, instead sometimes you can use the uh, let me share my screen again.

[00:58:45]If if it's really required to use get push force, you can instead use the command get push force with these.

[00:58:58]So uh this is a safer alternative because it checks if someone else has pushed changes to that remote branch since you have last pulled and if they did it blocks the override so that you don't accidentally wipe out uh the work that someone else did.

[00:59:32]Okay. Uh, seeing that there are no more doubts, um, thank you so much for the incredible energy, guys, tonight and I hope you guys have a wonderful time in JSON. Uh, good night everyone. Bye-bye.