Hey there, coders! Want to master Git? This fun, beginner-friendly tutorial covers all the basics: what Git is, how to track changes, commit code, create branches, push to remotes, and collaborate with others. Whether you’re coding solo or with a team, Git’s got your back. Avoid losing code, recover old versions, and learn pro tips to dodge merge conflicts. Subscribe for more coding tutorials, and let’s make version control a breeze! #GitBasics #LearnToCode #ProgrammingTutorials

Introduction to Git 00:00:00
What is Git 00:00:07
Git for tracking changes 00:00:18
Git for non-code documents 00:00:24
Why use Git 00:00:45
Code versioning benefits 00:00:50
Recovering deleted code 00:01:15
Collaboration with Git 00:02:35
Git repository basics 00:04:33
Installing Git 00:04:44
Creating a Git repository 00:05:08
Using git status 00:06:36
Adding files to Git 00:07:51
Committing changes 00:08:18
Checking Git log 00:11:21
Viewing changes with git diff 00:12:21
Pushing to remote 00:19:44
Cloning a repository 00:17:01
Branching in Git 00:23:27
Merging branches 00:25:21
Tagging releases 00:16:00
Pulling changes 00:26:55
Branching strategies 00:29:55
Avoiding merge conflicts 00:32:52
Backup and fresh clone tip 00:34:00
Conclusion and call to action 00:35:00

Thanks for watching!

Find us on other social media here:

• https://www.NeuralLantern.com/social

Please help support us!

• Subscribing + Sharing on Social Media
• Leaving a comment or suggestion
• Subscribing to our Blog
• Watching the main “pinned” video of this channel for offers and extras

Hey there, I’d like to talk to you today about the basics of Git and what is Git.

Git is an awesome system that you can use to track changes to all your code as you write

programs and work on things. And in fact, you can use Git for tracking changes to a wide variety of

documents, not just code only. There’s a special tool that I used a while back where I could track

used a while back where I could track changes to just regular office documents.

But if you’re writing text files of some sort or even like, I don’t know, making SVG graphics

files or something like that, you can track changes to all sorts of stuff. Okay, so it’s

mostly for coding. So what is Git and why would you want to use Git? Okay, so we talked about

Git being a code versioning system. It will track your changes. Imagine this.

Imagine you’re writing code and you spend all day, maybe like all month writing a really,

really good algorithm or a really good function or something like that.

And then maybe a year later, you haven’t been using it.

And you kind of think to yourself, you know, whatever happened to that giant function that

I wrote, that was really good.

And then you realize, oh no, I accidentally, I think I deleted it like several months ago

because I thought I didn’t need it anymore.

I didn’t need it anymore.

And now I’ve changed my mind.

I wish I had that back.

But then by then it’s too late because the code is gone and maybe you don’t have a backup

or maybe your backup is just, you know, only a few snapshots deep or whatever.

And so you’re kind of screwed, right?

So one way that Git can help you is Git lets you look back in time to the state of your

code at any other previous point.

Like every time you make significant progress with your code, you log it in Gits database.

You can just look back in time.

You can look back to see what your code was three years ago.

It’s awesome.

You can also, you know, revert changes.

You can sort of like branch your code off in two different directions.

Maybe here you’re just going to be working on bugs and on another branch, you’re adding

one feature that you think might be a good idea.

a really good idea you could merge that branch into the main branch or if you think that feature

is and is going to be trash and it sucks and you wish you never did it you can just delete that

branch and it doesn’t affect your main code branch it’s really cool it’s also a good tool

for collaboration because multiple people can can push to the git database and they can get

each other’s changes it’s kind of a way also to cloudify your code you know like if i’m writing

writing a program, I can commit some changes and I can push some changes to the cloud.

And then my colleague can pull my changes and they get everything that I just worked on.

And then they can commit some more changes and push it back up to the cloud.

Then I can pull it.

And so we’re sort of like collaborating and in a way where every single change is logged,

your boss can look at, or you, you know, you can look at all the logs in your commit,

in your git commit database and see who changed what you can see what lines were changed when

when they were changes you can see who introduced a bug there’s a function in

git that is called git blame where you can look at a source code file and you

can see who is responsible for every single line you can bookmark states of

your code you can do so much it’s wonderful but anyway I just want to

touch on the basics today I hope I’ve kind of convinced you that git is a

little bit of a good idea I used to just sort of code and then you know do copy

paste as my backup copy and it was okay but when I started using git even by

started using git even by myself without collaborating um it was tremendously valuable

there were many times when i wanted to look back at a previous state of code and git let me do it

many times when i wanted to revert some mistake that i made and git let me do it

okay so you see my terminal here maybe maybe i should reduce the transparency just a little bit

to like maybe like 85 opacity.

That’s a little bit better.

Okay, so I’m gonna go into a documents folder.

I’m gonna go into a temporary folder

and I’m gonna remove everything that is, whoops.

Okay, that was just something I was working on earlier.

Okay, so I’m in a folder.

So what is a Git repository?

Actually a Git repository is just a folder

with some extra information inside of it.

Let me see, I don’t remember if I installed Git on this machine.

I did.

Okay, if you don’t have Git, you can get it pretty easily with sudo apt install git.

Or if you’re on Windows or some other operating system, you can just go to Git’s website.

It’s git-sem.com or something like that.

You can just find the installer and just get it in there.

But, so let’s say, let’s say I want to make a repository.

directory my repository okay so I’ve got like an empty folder I’m going to go inside of it

and this is just a folder it’s not a repo yet I can convert this folder into a repository by

just using the command git init oh gosh here’s like a message oh you got to choose what branch

you want I think it’s actually okay at this point I think they’ll choose one for me when you see

this you can read them and obey them but they’re not necessarily mission critical while we’re just

learning so notice how when i list the directory it’s no longer empty there’s a there’s a git

folder inside of there so if i go inside of the git folder i mean this is really not so much for

humans you can kind of do configuration stuff in here but um this is really gets database of

everything it knows about your code you know when you change stuff what’s the configuration

So if you actually remove this folder, I’m going to remove the Git folder.

That’s all it takes.

Now this folder is just a regular folder.

It’s no longer a Git repository.

So you probably don’t want to do that once you’ve initialized it,

but I’m going to reinitialize this again.

If I had a bunch of history inside that folder,

then it would have been gone already.

But we’re just learning.

This is just an empty repository.

So I have a Git repository here.

here. First thing I want to do is try to figure out what Git thinks about the repository. So I’m

going to use the command git status. Whenever you’re not sure of what’s going on, if you think

you need to commit something or push something or pull something or whatever, it’s probably a good

idea to use git status. I use it all the time. Git status and then git will tell you what to do.

It’s basically telling you that you haven’t done anything at this point. So that’s okay.

a readme file in markdown, my, oops, my project.

You don’t really need to know about markdown to use Git,

although the two kind of go hand in hand on GitHub.

But I’m just going to say, well, here’s my project.

This is my super cool project.

Okay, so pretend this is a program, a complicated program.

So I’m saving it.

We can verify that I actually like put something into that file.

So now I’m going to ask Git, you know,

you know, what do you think about the state of this repository?

So I’m going to say git status.

Git is telling me now that we’re on the master branch

and there are no commits yet.

And I have an untracked file.

This means that the readme file is not considered part of the git repository.

It’s just sitting in the directory tree.

So I want to add that into my repository so I can start tracking changes.

So I’m going to say git add and then the name of the file.

What have I done?

Okay, here we go.

What have I done? Okay, here we go.

That’s not how you spell add.

So now that I’ve done git add, I can say git status one more time to see what

Git thinks about the state of my repository.

Git says, well, you definitely use the add in order to put the changes on a stage.

Git likes to bunch up changes on a stage before you actually commit things to the

database. The reason for that is maybe

maybe you spend an hour doing a bunch of work in a bunch of different areas of your

different areas of your program, but maybe there’s only like a few files over here that

are part of a logical change.

Like this is feature a that I was fixing, but you also changed a bunch of other files

that were related to something else like feature B that I was fixing.

It doesn’t really make sense to take all of those changes and make them one commit because

you want a nice clean commit log that shows exactly what you were working on.

And it makes sense.

you just worked on a bunch of different files,

you can add all the feature A files to the stage first

and then commit that as one change

and then go over to the feature B files

and add those to the stage

and then commit that as a second change.

So it’s kind of a way to get you out of the mess

you’ve put yourself in

if you’ve just been working too long without committing.

You should really do a git commit

every time you make significant progress.

Like, I mean, it depends on where you’re working

where you’re working or who you’re talking to. You definitely don’t want to commit every line

that you change. You definitely don’t want to work for like a month and then do one commit at the end

of the month. The sweet spot is somewhere in between. Your boss will probably tell you what

to do. For me personally, every time I fix something, I’ll make a commit. One thing,

you know, I made significant progress in my program by adding a new feature. One little

feature, I’m going to commit it. Some people like to do commits at least once a day so that if

to do commits at least once a day so that if they’re working on a huge new feature, then

they’ll do like one commit a day. And then they’ll sort of like call those several commits

part of like a new feature. It’s up to you. But at this point, we just have the one file

that we made up on the stage. It’s ready to be committed. We used git status. So git

is just telling us how to commit it. It’s like, oh no, it’s not telling us. It’s just

saying we need to commit it. It’s not saying how. If you want to unstage it, then here’s

commit command is just git commit now it’s going to ask me for a commit message this is what you

will see in the log so don’t just put work don’t put change don’t put something that doesn’t

describe what you did you should describe exactly what you did so so what i’m going to do is for

the commit message i’m going to just sort of say what i did you can imagine writing something like

i created the readme file it should always definitely describe exactly what you did

um but it seems like a lot of people use uh i guess grammar and and and terseness

just to make the commit message sound like they told somebody to do something so create the readme

file instead of i created the readme file create the readme file so i’m just going to make that my

commit message save the buffer and then uh now that i’ve committed the changes i have to ask

you know git status what did i do you know what’s the state of the repository it is now saying that

that the repo is clean, everything looks pretty good.

So that means my changes are recorded in the Git database.

I can now actually use a command called Git log to see what changes have been recorded.

Notice how there’s only one change.

It’s just, you know, my name here, when it was changed and then what I did.

There’s a hash here.

This little hexadecimal string is called a hash.

to show me what happened in any specific commit by saying git show and then I give it a hash

and it’ll tell me exactly what files were created or changed or deleted or whatever

and there it is right there this will get more interesting in a second let’s make a change

I’m going to say edit the readme file and we say this is my super cool project this is my first

So I’m going to say git status to find out what’s going on.

Git says, oh, you made a change there.

It’s not saying that this file is not part of the database.

It’s just saying that we made changes.

I want to see the changes that it’s talking about.

I could say git diff.

And it’s telling me that I added this line.

My dog is growling at me.

about peeing oh my gosh hang on

so i’ll let him back in he’ll try to lie to me and he’ll try to get free treats

okay so uh we can use the command git diff to see what our changes are we can also say

git diff whoops git diff and then name a file and it’ll tell us what’s changed in that one file

second line so great back to get status it’s saying we need to stage that change

so I’m just gonna say get add and then the name of the file get status again

so that we know what’s up it’s saying all right well you just need to commit

the changes on your stage if you’d like to so yeah sure I’m gonna say get commit

and I’m gonna say you know changed the readme or something okay get status

So now if we do git log, there’s two entries.

Imagine that this happens every single time

somebody makes a significant change.

You know, it’s just like it goes in the log.

You can figure out who changed what.

Watch this.

Let’s do cat readme so we can see the readme.

Notice how it’s got the second line at the end.

I could also go back in time

and see what the state of my project was

was after that first commit so i could i’m going to copy paste that first commit and i’m going to

say git checkout and the commit hash it’s now telling me something hey by the way now you’re

looking back in time you should not change anything you’re on a detached head if you’re

ever unsure of where you’re actually at in git you should do git branch all and it’ll just sort

of show you where you’re at i was on the master branch now i’m on a detached head but notice if i

But notice if I spill the contents of the README file.

Hang on, what did I do wrong?

Change the README.

Oh, sorry, it’s in reverse order.

I always forget that.

I copied the wrong hash.

So let me check out the first commit that I made.

So I’m going to say git checkout the first commit hash.

Okay, now I’m going to concatenate the,

or I’m going to spill the contents of the README.

Notice how the readme looks like it did when we first made it.

So we’ve gone back in time.

Think of how useful this could be if this was a huge, big project with a bunch of files

and a lot of lines per file.

So once again, we’ll do git, actually let’s do git status.

Status is reminding me that we’re on its attached head.

and we can also use git branch to see that we’re still in the detached head you want to get back

onto the master branch or whatever branch you’re working with before you continue working so we’ll

status and you can see that we’re on the master branch.

Then we can say get branch all.

And there we go. Maybe we want to bookmark this.

Maybe we want to remember, oh, this is a perfect state of our of our code.

Maybe this is version one point.

We can do get tag version one point.

Oh, and now we have a bookmark forever.

How can we find the bookmarks?

Well, we can say get tag just by itself, and it’ll give us a list of our bookmarks.

When we push this to a remote server, the server will be able to show it like

remote server, their server will be able to show it like GitHub or GitLab or whatever.

And then later we can do something like, you know, get checkout and then just check out the

name of a tag. So it’s kind of the same thing as checking out a commit hash, but it’s like

a bookmark that’s a little bit easier to remember. So let’s look at remotes for a second,

because right now we’re not pushing code anymore. We’re just remembering what we changed in our

Okay, so I’m inside my repository.

And now I’m going to go up a level on this right pane,

and I’m going to make a new directory.

But I’d like to clone the original repository.

Imagine that this repository, it’s a folder to us,

but it could be for all we know, sitting on a remote server

and accessed with a special URL.

So you can go to like GitHub or somebody’s server,

and you can copy their get URL for their repository.

repository. Over here in our local file system, we could clone the original repository.

Usually you would have to copy paste like a big get URL, SSH URL or HTTPS URL or whatever.

But you can even do this locally so I can tell get I would like to clone this local repository

denoted by this folder name. And I would like to call it my clone or something. So I’m gonna say

So I’m going to say get clone repository my clone.

It says cloning and done.

Now we have two folders.

And if we go inside of the my clone repository,

we should have the same state of code that we just cloned.

So that makes sense.

Now think about collaboration.

We can change our code from the clone.

And as long as the clone has permission to push back up to the remote,

back up to the remote then it actually would work.

So let’s edit the README file real fast.

So I’m going to go nano README and I’m going to say this change was made by the clone.

Okay, so I did that.

And actually just to make things interesting, I’m going to change my git identity only inside

of this clone.

You can do that in git.

config and you say something like user.name, you know, you can put your name here, your email,

whatever, for like user.email. There’s this thing that you usually do where you say get config

global. And that means you’re changing configuration that is account wide. So like

your entire account on this machine is going to be changed when you use that global flag.

But if I don’t use the global flag, it’s just changing my configuration for only this one

this one repository so i’m going to make my name clone dude and make my email

clone dude at laptop or whatever at server so now if i say git status over here it’s telling me hey

i have like a change i say git diff and it tells me oh look i you know you changed that last line

so i’m going to add that change to the stage and then i’m going to commit it and i’m going to say

I added something to the readme.

Okay.

Git status.

Notice how git status is saying something a little bit extra this time.

Before, we were just in a local file system only.

And now we’re working inside of a clone.

So this is like, you know, you clone some code from GitHub

or from your friend’s server or whatever.

And when you do a clone,

it actually automatically links your local repository

repository to the remote repository. By the way, in Git, everything is considered a local copy. So

it’s not like you’re working with something different than the server has. You actually

have the entire Git history and all the code and everything that Git has on the remote,

except for maybe some like configurations or something. But when you pull, you’re just making

you’re making a copy later we can push our changes to the server and that just makes

the two repositories talk to each other sort of and reconcile changes and make sure that both sides

have the differences i guess so it’s telling us we need one more step it’s saying git status and

it says you’re on the master branch your branch is ahead of origin master by one commit what’s

origin master you can find out all of your remote connections and get by saying git remote v so when

so when you clone it automatically makes an origin remote it calls it origin and

then it has the URL or in this case just the file path of where the remote is so

it’s telling you that our remote where we’re connected to is the my repository

folder that we were at in the left pane so it’s telling us also if we go back to

just status it’s telling us that we should use git push to publish my local

my local commits to the remote because at this point we’re out of sync if uh if somebody else

cloned the remote repository and then made a bunch of changes and then pushed then i would now be

totally out of sync with that new person who cloned and also the remote server and it would

create something called a merge conflict which is like a little bit more advanced than this video

and we’d have to take steps to resolve it so the smartest thing to do is um well if you’re

Make sure that everybody is designated a certain file or set of files to work on and you all talk to each other.

Hey, I just pushed some code.

You need to pull.

Hey, I’m about to push.

Hold off a second.

Hey, I just pushed.

If you’re working on something, you’ve got to pull my changes before you do a push.

Always push after you commit so that everybody has the latest copy on the remote so you don’t cause conflicts with your teammates or whatever.

and always try to do pulls regularly.

Anyway, so I need to push my code.

I’m going to say git push.

And it’s saying, oh gosh, what is it saying?

Oh, okay, okay, okay, okay.

This is going to be a special setup that I have to do.

Let me just very quickly revert what I’m doing here.

I think I have to…

Oh, I know what to do. I can just make it a little trick.

Usually the thing is they don’t want you to push onto a branch that the remote has currently checked out into the file tree.

But usually remote servers, they don’t have a branch checked out.

So you won’t even see the file system on the remote.

It’ll actually all look like just this.

There’s a flag called bear that you can use to make that happen.

But I don’t really want to go through all the steps right now.

So what I’m going to do is I’m just going to make another dummy branch and then just kind of sit on it for a while.

dummy branch and then just kind of sit on it for a while.

That way I’m allowed to push to the master branch.

So I’m going to say get branch.

This is how you make a new branch.

I’m going to say dummy or something.

Whoops, got to spell branch, right?

Then get checkout dummy and then get branch all and then get status just to make sure

I’m now sitting on the dummy branch.

And then this will cure the problem that we had a moment ago where we’re not

allowed to push to a branch that the remote has checked out.

branch that the remote has checked out so i’m gonna say git oh wait hang on gotta go back in there

my clone git push okay so now it works uh so keep in mind if you’re pushing to you know a remote

that has a branch that’s checked out like it’s another file system like it’s a friend’s computer

you’re gonna have to worry about this sort of thing but if it’s a server like github or just

someone who has set them set the repository up properly uh you won’t have to worry about it so

Forget about that for now.

So I pushed to the remote.

If I do git log over here, there’s a mix.

It shows, you know, Mike created it and then changed it.

And then the clone dude added something too.

Okay.

So if I say git log, we should now see the history for only the dummy branch.

So that’s just two things.

And if I say git checkout master, and then I check out and then I look at the log for

I can see all the changes that the other person made.

Pretty cool.

I could also go back into the dummy branch if I wanted to.

I actually used to do this a long time ago before I realized you should do bear repos.

Let’s see.

Check out dummy.

And then I’ll say git log just to confirm that the changes aren’t in there.

So now we have two branches that are kind of diverging a little bit.

the master branch has one more commit than the dummy branch and if we let this go on for far too

long it might be more of a hassle to make the branches merge again but i’m just going to merge

them right now so i’m going to say git merge verify that you’re sitting on the correct branch

that you want to be the destination branch so i’m sitting on the destination the dummy branch so i’m

going to say git merge and i’m going to give it the name of the branch that i want to merge changes

It’s telling me that something happened.

So if I do get branch again one more time, I’m still on the dummy branch.

But if I do get log, notice how I have that latest log entry.

Pretty cool.

So now I’m going to go back onto the master branch because I want to do some work here.

This is a little clumsy.

If we’re talking about a server client paradigm, just bear with me.

Now I’m going to make another change.

Hi, Mr. Clone.

clone. Can you read this? So I’m going to make a change that I want the clone person to see.

Git status, git add, the readme. You could also do git commit dash a, but I kind of don’t like

to because I’d like to remind myself that the stage is a good idea. Git commit new readme

okay so I’m not I don’t have a remote I am the master so there’s nowhere to push

but now in the clone I can say git status it doesn’t yet know that the that the

remote has changes I could do git pull to actually pull all the changes or I

can do git fetch fetch will sort of talk to the remote and pull the changes into

this repository’s local copy of the remote.

So if we do git branch all, you’ll notice that we have a master branch here.

So the master branch is my master branch.

And all these other branches here are local copies of the remotes branch.

So we’re just making lots and lots of copies.

That’s kind of how git works.

But now that we did a fetch, that talked to the remote, it grabbed changes.

Now Git understands that we’re actually behind the remote by one commit.

And it’s telling us, well, you need to use Git pull to pull all the changes.

Usually you kind of don’t need to do Git fetch.

If you have a remote, you just say Git pull.

You only do Git fetch if you want to kind of see what’s going on with the remote first before you

actually try to pull all the changes into your branch.

It’s a more complicated situation.

So if I say Git pull, now inside of my Git log, I have that last change.

that last change that the master gave us.

So this is like a very, very basic workflow for Git

in terms of making changes to your program,

committing the changes, checking out the log,

checking out what was changed,

pushing to a remote and so forth.

The only difference, by the way,

between using a remote that’s a file system

and using a remote that’s GitHub

is just what URL you put in clone.

in clone like if i put if i said git clone i put a file path here originally but if i just

put a clone url that github gave me or your friend’s server gave you right there then it

would work basically the same way it’s pretty sweet um let’s see so those are the basics of git

always make sure that you push to the remote so that the server has your changes and if you’re

using github or another website uh it’s it’s usually a really good idea to push and then go

to the website to double check that your changes actually made it.

So we talked about tags and branches.

This video is not going to be for advanced branching strategies,

but there are lots of cool resources you can check out.

Actually, you know what? I’m going to pull one up. Let’s see.

I’m going to edit this out if it ends up being like a really bad search result.

Get branching strategy.

big project with a big team let’s see there’s one that I used to love where the heck is it

I think this month no that’s not the link I remember I should have bookmarked it but there

are lots of different strategies for how and why you would want to use um branches let’s see one

of these has a good diagram this is it this is not the same web page but I think this website

diagram that I remember.

So we’ve been on the master branch.

That’s like the right side here.

You know, this little, these little blue dots.

Imagine that every single time you want to create a new feature,

you just create a branch and you name it after the feature that you’re creating.

I think I mentioned that before that allows you to sort of keep working on the

master branch independently of the feature that you’re working on.

And then later when you’re sure you want to merge the feature into the master

branch, then you just use a get command to make the two branches merge.

command to make the two branches merge.

Or if the feature turns out to be a bad idea, you can just delete the branch.

Usually, at minimum, most people will do something like this.

They’ll have a development branch.

So here you can see the yellow dots.

That’s development.

And what they’ll do is they’ll make all of their commits to the development branch.

And then only whenever the program is in a really good state, like it’s sort of presentable,

you can actually release it.

let your friend run the code or whatever, then you’ll merge the dev branch into the master branch

without deleting the dev branch. So you’ll merge the dev into master every time the code is in a

really good state. And then you’ll come back on to dev to continue developing. I think most people

call it develop. Actually, I call it dev for mine. And that way, the master branch usually only ever

is in a state that is good that people could clone from and just compile the program or use the

or use the program or whatever.

And that is in addition to adding tags

whenever you think the master branch is in a state

that you think is like a significant release.

So like version 1.0 or 1.2 or whatever.

So branches for development

where you’re always there most of the time.

Branches for feature when you’re kind of experimenting

and trying to figure out

if you’re going to be able to add something.

Branches for, there’s a branch for the master

where it’s like this is the state

that the public should see,

the state that actually works.

actually works. And then, you know, you might do a temporary branch for a hot fix.

And sometimes people will do a new branch for a future release. Like if you’re going to release

version 2.0, you might make a new branch and call it version 2.0 and then just work on that and

kind of like merge changes from dev in that and just make sure that it’s all good and it’s great.

And as soon as you think that the feature branch is perfect for your release, sorry, not

Sorry, not feature branch.

Release branch is great for your release.

Then all at once, you’ll merge that whole thing into master.

You don’t have to do it that way.

It doesn’t have to be that complicated,

but sometimes it can be that complicated.

For me personally, I usually just do a development branch

and a master branch.

And then sometimes when I’m taking a risk,

I’ll make a feature branch for the new thing that I’m trying.

So I just kind of wanted to show you that for branching.

for branching and

we talked about pulling and pushing and cloning

yeah so just uh i guess one more warning to make sure that you don’t

end up with merge conflicts when you’re collaborating with other people

or even actually this happens to people who work by themselves and they just

switch computers a lot make sure that when you first sit down

and you’re about to start coding you always pull

team of people communicate with them and tell them you’re about to pull tell them you’re about

to start working on something tell them tell them what you’re about to start working on unless you

have like a manager who’s telling you exactly what to work on then it’s their problem um

and then do your get pull and then work and then every time you make significant progress

do a commit and then tell everybody i’m about to push and then push and then make sure that you

So if you go on your lunch break, make sure you push before you go on your lunch break.

And when you come back from your lunch break, make sure you pull right away.

Because if you don’t pull and push enough, you’re either going to get merge conflicts

on your end or you’re going to cause other people to get merge conflicts.

And sometimes it takes a lot of time to resolve the merge conflicts.

So you really don’t want to deal with that.

And then a beginner’s tip, or I guess like maybe like an easy tip.

I do this actually sometimes.

up totally forgetting to push and pull and you do a lot of code and you kind of like wreck everything

and you don’t want to deal with a gigantic merge conflict resolution type of situation sometimes

it’s easier to just copy paste your folder somewhere else rename it remember a git repository

locally it’s just a folder so you can copy paste it or rename it or whatever you want to do

you just kind of copy paste it somewhere and then perform a fresh clone from the remote

then there’s not going to be a merge conflict because the fresh clone is going to be directly

from the remote which is not conflicted on its own then you’ll have your fresh clone and then

you’ll have your little backup copy of what you just screwed up then you can manually inspect the

difference between the fresh clone and then the thing that you just screwed up or you can just

start copy pasting some of your changes and then do like a commit and then do push and then it

Git Basics tutorial. I hope you learned a little bit of stuff and had a little bit of fun.

I will see you in the next video.

Hey everybody. Thanks for watching this video again from the bottom of my heart. I really

appreciate it. I do hope you did learn something and have some fun. If you could do me a please,

a small little favor, could you please subscribe and follow this channel or these videos or

whatever it is you do on the current social media website that you’re looking at right now.

It would really mean the world to me and it’ll help make more videos and grow this community

So we’ll be able to do more videos longer videos better videos or just I’ll be able to keep making videos in general

so please do do me a kindness and

And subscribe you know sometimes

I’m sleeping in the middle of the night and I just wake up because I know somebody subscribed or followed it just wakes me up

And I get filled with joy. That’s exactly what happens every single time

So you could do it as a nice favor to me or you could you control me if you want to just wake me up in the middle

me if you want to just wake me up in the middle of the night just subscribe and then i’ll just

wake up i promise that’s what will happen also uh if you look at the middle of the screen right now

you should see a qr code which you can scan in order to go to the website which i think is also

named somewhere at the bottom of this video and it’ll take you to my main website where you can

just kind of like see all the videos i published and the services and tutorials and things that i

have a suggestion for uh uh clarifications or errata or just future videos that you want to

see please leave a comment or if you just want to say hey what’s up what’s going on you know just

send me a comment whatever i also wake up for those in the middle of the night i get i wake

up in a cold sweat and i’m like it would really it really mean the world to me i would really

appreciate it so again thank you so much for watching this video and um enjoy the cool music

fade into the darkness which is coming for us all.

Thank you.

The post Git Basics Tutorial: Learn Version Control, Commits & Branches for Beginners appeared first on NeuralLantern.com.