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
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
Category
🤖
TechTranscript
00:00Hey there, I'd like to talk to you today about the basics of Git and what is Git.
00:13Git is an awesome system that you can use to track changes to all your code as you write
00:18programs and work on things.
00:20And in fact, you can use Git for tracking changes to a wide variety of documents, not
00:25just code only.
00:27There's a special tool that I used a while back where I could track changes to just regular
00:31office documents.
00:33But if you're writing text files of some sort or even like, I don't know, making SVG graphics
00:38files or something like that, you can track changes to all sorts of stuff.
00:44Okay, so it's mostly for coding, but so what is Git and why would you want to use Git?
00:48Okay, so we talked about Git being a code versioning system, it will track your changes.
00:55Imagine this, imagine you're writing code and you spend all day, maybe like all month
01:01writing a really, really good algorithm or a really good function or something like that.
01:07And then maybe a year later, you haven't been using it.
01:11And you kind of think to yourself, you know, whatever happened to that giant function that
01:15I wrote?
01:16And then you realize, oh, no, I accidentally, I think I deleted it like several months ago
01:23because I thought I didn't need it anymore.
01:25And now I've changed my mind.
01:26I wish I had that back.
01:27But then by then it's too late because the code is gone and maybe you don't have a backup
01:33or maybe your backup is just, you know, only a few snapshots deep or whatever.
01:38And so you're kind of screwed, right?
01:40So one way that Git can help you is Git lets you look back in time to the state of your
01:47code at any other previous point.
01:49As long as you've been committing your changes, like every time you make significant progress
01:54with your code, you log it in Git's database, you can just look back in time.
01:59You can look back to see what your code was three years ago.
02:03It's awesome.
02:04You can also, you know, revert changes, you can sort of like branch your code off in two
02:10different directions.
02:11Maybe here you're just going to be working on bugs and on another branch, you're adding
02:15one feature that you think might be a good idea.
02:18And later on, if that feature ends up being a really good idea, you could merge that branch
02:22into the main branch.
02:24Or if you think that feature is going to be trash and it sucks and you wish you never did
02:28it, you can just delete that branch and it doesn't affect your main code branch.
02:33It's really cool.
02:34It's also a good tool for collaboration because multiple people can push to the Git database
02:42and they can get each other's changes.
02:43It's kind of a way also to cloudify your code.
02:47You know, like if I'm writing a program, I can commit some changes and I can push some
02:51changes to the cloud.
02:52And then my colleague can pull my changes and they get everything that I just worked on.
02:57And then they can commit some more changes and push it back up to the cloud.
03:00Then I can pull it.
03:01And so we're sort of like collaborating and in a way where every single change is logged.
03:05Your boss can look at or you, you know, you can look at all the logs in your commit in
03:11your git commit database and see who changed what you can see what lines were changed when
03:16they were changes.
03:17You can see who introduced a bug.
03:20There's a function in git that is called git blame where you can look at a source code
03:24file and you can see who is responsible for every single line.
03:28You can bookmark states of your code.
03:30You can do so much.
03:31It's wonderful.
03:32But anyway, I just want to touch on the basics today.
03:34I hope I've kind of convinced you that git is a little bit of a good idea.
03:37I used to just sort of code and then, you know, do copy paste as my backup copy and it was
03:42okay.
03:43But when I started using git even by myself without collaborating, it was tremendously valuable.
03:50There were many times when I wanted to look back at a previous state of code and git let
03:54me do it.
03:55Many times when I wanted to revert some mistake that I made and git let me do it.
04:00Okay, so you see my terminal here, maybe, maybe I should reduce the transparency just
04:06a little bit.
04:09Just to make this a little bit easier to see something to like maybe like 85 opacity.
04:16That's a little bit better.
04:17Okay, so I'm going to go into a documents folder, I'm going to go into a temporary folder.
04:22And I'm going to remove everything that is whoops.
04:26Okay, that was just something I was working on earlier.
04:30Okay, so I'm in a folder.
04:33So what is a git repository?
04:35Actually a git repository is just a folder with some extra information inside of it.
04:40Let me see.
04:41I don't remember if I installed git on this machine.
04:44I did.
04:45Okay, if you don't have git, you can get it pretty easily with sudo apt install git.
04:50Or if you're on Windows or some other operating system, you can just go to git's website.
04:55It's git-scm.com or something like that.
04:58You can just find the installer and just get it in there.
05:02So let's say, let's say I want to make a repository.
05:07We'll say make directory my repository.
05:10Okay, so I've got like an empty folder, I'm going to go inside of it.
05:16And this is just a folder.
05:17It's not a repo yet.
05:18I can convert this folder into a repository by just using the command git init.
05:24Oh gosh, here's like a message, oh, you got to choose what branch you want.
05:29I think it's actually okay at this point.
05:32I think they'll choose one for me.
05:34When you see yellow instructions like this, you can read them and obey them, but they're
05:39not necessarily mission critical while we're just learning.
05:43So notice how when I list the directory, it's no longer empty.
05:47There's a git folder inside of there.
05:50So if I go inside of the git folder, I mean, this is really not so much for humans.
05:54You can kind of do configuration stuff in here, but this is really git's database of
05:59everything it knows about your code.
06:01You know, when you changed stuff, what's the configuration.
06:04So if you actually remove this folder, I'm going to remove the git folder.
06:10That's all it takes.
06:12Now this folder is just a regular folder.
06:14It's no longer a git repository.
06:16So you probably don't want to do that once you've initialized it.
06:18But I'm going to, so I'm going to reinitialize this again.
06:22If I had a bunch of history inside that folder, then it would have been gone already.
06:27But we're just learning.
06:28This is just an empty repository.
06:31So I have a git repository here.
06:33First thing I want to do is try to figure out what git thinks about the repository.
06:36So I'm going to use the command git status.
06:39Whenever you're not sure of what's going on, if you think you need to commit something
06:42or push something or pull something or whatever, it's probably a good idea to use git status.
06:48Like just, I use it all the time, git status, and then git will tell you what to do.
06:52It's basically telling you that you haven't done anything at this point.
06:54So that's okay.
06:57Let's make a readme file.
06:58I'm just going to make a simple readme file in markdown, my, oops, my project.
07:06You don't really need to know about markdown to use git, although the two kind of go hand
07:11in hand on GitHub.
07:12But I'm just going to say, well, here's my project.
07:14This is my super cool project.
07:17Okay.
07:18So pretend this is a program, a complicated program.
07:21So I'm saving it.
07:23We can verify that I actually like put something into that file.
07:27So now I'm going to ask git, you know, what do you think about the state of this repository?
07:30So I'm going to say git status.
07:33Git is telling me now that we're on the master branch and there are no commits yet.
07:38And I have an untracked file.
07:40This means that the readme file is not considered part of the git repository.
07:44It's just sitting in the, in the, in the directory tree.
07:48So I want to add that into my repository so I can start tracking changes.
07:51So I'm going to say git add, and then the name of the file.
07:54What have I done?
07:56Here we go.
07:58That's not how you spell add.
08:00So now that I've done git add, I can say git status one more time to see what git thinks
08:04about the state of my repository.
08:05Okay.
08:07Git says, well, you definitely use the add in order to put the changes on a stage.
08:13Git likes to bunch up changes on a stage before you actually commit things to the database.
08:19The reason for that is maybe, maybe you spend an hour doing a bunch of work in a bunch of
08:24different areas of your program, but maybe there's only like a few files over here that
08:29are part of a logical change.
08:31Like this is feature a that I was fixing, but you also changed a bunch of other files
08:35that were related to something else.
08:37Like feature B that I was fixing.
08:38It doesn't really make sense to take all of those changes and make them one commit because
08:43you want a nice clean commit log that shows exactly what you were working on.
08:47And it makes sense.
08:49So in the case where you just worked on a bunch of different files, you can add all the feature
08:55a files to the stage first and then commit that as one change and then go over to the
09:00feature B files and add those to the stage and then commit that as a second change.
09:05So it's kind of a way to get you out of the mess you've, you've put yourself in.
09:12If you've just been working too long without committing, you should really do a git commit
09:17every time you make significant progress.
09:19Like, I mean, it depends on where you're working or who you're talking to.
09:23You definitely don't want to commit every line that you change.
09:26You definitely don't want to work for like a month and then do one commit at the end of
09:28the month.
09:29Um, the sweet spot is somewhere in between.
09:32Your boss will probably tell you what to do for me personally.
09:35Every time I fix something, I'll make a commit one thing, you know, I made significant progress
09:40in my, in my program by adding a new feature, one little feature, I'm going to commit it.
09:46Some people like to, to do commits at least once a day so that if they're working on a
09:50huge new feature, then they'll do like one commit a day.
09:53And then they'll sort of like call those several commits a part of like the new feature.
09:58It's up to you.
09:59But, um, at this point we just have the one file that we made up on the stage.
10:03It's ready to be committed.
10:05We used git status.
10:06So git is just telling us how to commit it.
10:08It's like, oh no, it's not telling us.
10:10It's just saying we need to commit it.
10:11It's not saying how.
10:13If you want to unstage it, then here's the command, but, uh, you know, the commit command
10:16is just git commit.
10:18Now it's going to ask me for a commit message.
10:21This is what you will see in the log.
10:22So don't just put work.
10:25Don't put change.
10:26Don't put something that doesn't describe what you did.
10:28You should describe exactly what you did.
10:30So, so what I'm going to do is for the commit message, I'm going to just sort of say what
10:36I did.
10:37You can imagine writing something like I created the README file.
10:40It should always definitely describe exactly what you did.
10:44But it seems like a lot of people use, I guess, grammar and terseness to make the commit message
10:52sound like they told somebody to do something.
10:54So create the README file instead of I created the README file.
10:58Create the README file.
10:59So I'm just going to make that my commit message, save the buffer.
11:03And then, uh, now that I've committed the changes, I have to ask, you know, get status.
11:08What did I do?
11:09You know, what's the state of the repository?
11:11It is now saying that the repo is clean.
11:14Everything looks pretty good.
11:16So that means my changes are recorded in the get database.
11:21I can now actually use a command called get log to see what changes have been recorded.
11:27Notice how there's only one change.
11:29It's just, you know, my name here when it was changed and then what I did.
11:34There's a hash here.
11:35This little hexadecimal string is called a hash.
11:39I can ask it to show me what happened in any specific commit by saying get show.
11:45And then I give it a hash and it'll tell me exactly what files were created or changed
11:49or deleted or whatever.
11:51And there it is right there.
11:53This will get more interesting in a second.
11:54Let's make a change.
11:55I'm going to say edit the readme file and we say, this is my super cool project.
12:01This is my first change to the readme.
12:05Again, imagine that you've written a big program.
12:08So I'm going to say get status to find out what's going on.
12:12Get says, oh, you made a change there.
12:14It's not saying that this file is not part of the database.
12:17It's just saying that we made changes.
12:19I want to see the changes that it's talking about.
12:21I could say get diff.
12:23And it's telling me that I added this line.
12:27My dog is growling at me.
12:32He likes to go pee and then later lie about peeing.
12:40So I'll let him back in.
12:45He'll try to lie to me and he'll try to get free treats.
12:51Okay.
12:52So we can use the command get diff to see what our changes are.
12:54We can also say get diff, whoops, get diff and then name a file.
12:59And it'll tell us what's changed in that one file.
13:01Notice how it's saying here that we've added a second line.
13:05So great.
13:07Back to get status, it's saying we need to stage that change.
13:09So I'm just going to say get add and then the name of the file, get status again so that
13:14we know what's up.
13:15It's saying, all right, well, you just need to commit the changes on your stage if you'd
13:18like to.
13:19So, yeah, sure.
13:20I'm going to say get commit and I'm going to say, you know, changed the read me or something.
13:28Okay.
13:29Get status again.
13:30It wants me to put my author name in there.
13:33So now if we do get log, there's two entries.
13:37Imagine that this happens every single time somebody makes a significant change.
13:42You know, it's just like it goes in the log.
13:44You can figure out who changed what.
13:47Watch this.
13:48Let's do get, sorry, let's do cat read me so we can see the read me.
13:53Notice how it's got the second line at the end.
13:55I could also go back in time and see what the state of my project was after that first commit.
14:02So I could, I'm going to copy paste that first commit and I'm going to say get checkout and
14:08the commit hash.
14:11It's now telling me something.
14:12Hey, by the way, now you're looking back in time, you should not change anything.
14:15You're on a detached head.
14:17If you're ever unsure of where you're actually at in get, you should do get branch all and
14:23it'll just sort of show you where you're at.
14:24I was on the master branch.
14:26Now I'm on a detached head.
14:28But notice if I spill the contents of the read me file, hang on, what did I do wrong?
14:38Change the read me.
14:39Oh, it's sorry.
14:40It's in reverse order.
14:41I always forget that.
14:43I copied the wrong hash.
14:44So let me, let me check out the first commit that I made someone say get checkout the first
14:49commit hash.
14:50Okay.
14:51Now I'm going to concatenate the, or I'm going to spill the contents of the read me.
14:56Notice how the read me looks like it did when we first made it.
15:00So we've gone back in time.
15:02Think of how useful this could be if this was a huge, big project with a bunch of files and
15:07a lot of lines per file.
15:10So once again, we'll do get a, actually let's do get status status is reminding me that we're
15:16on a detached head.
15:37We can also use a get branch to see that we're still on the detached head.
15:41You want to get back onto the master branch or whatever branch you're working with before
15:45you continue working.
15:46So we'll say get checkout master.
15:50And then just to double check, we'll do get status.
15:53And you can see that we're on the master branch, then we can say get branch all.
15:58And there we go.
15:59Maybe we want to bookmark this.
16:00Maybe we want to remember, oh, this is a perfect state of our, of our code.
16:04Maybe this is version 1.0.
16:06We can do get tag version 1.0.0.
16:11And now we have a bookmark forever.
16:13How can we find the bookmarks?
16:14Well, we can say get tag just by itself and it'll give us a list of our bookmarks.
16:19When we push this to a remote server, their server will be able to show it like GitHub
16:22or GitLab or whatever.
16:25And then later we can do something like, you know, get checkout and then just check out
16:28the name of a tag.
16:31So it's kind of the same thing as checking out a commit hash, but it's like a bookmark.
16:35It's a little bit easier to remember.
16:39So let's look at remotes for a second, because right now we're not pushing code anymore.
16:44We're just remembering what we changed in our code.
16:48Okay.
16:49So I'm inside my repository.
16:52And now I'm going to go up a level on this right pane and I'm going to make a new directory.
16:58But I'd like to clone the original repository.
17:02Imagine that this repository, it's a folder to us, but it could be for all we know, sitting
17:07on a remote server and accessed with a special URL.
17:11So you can go to like GitHub or somebody server and you can copy their get URL for their repository.
17:19Over here in our local file system, we could clone the original repository.
17:23Usually you would have to, you know, copy paste like a big get URL, SSH URL or HTTPS URL or whatever.
17:31But you can even do this locally.
17:33So I can tell get, I would like to clone this local repository denoted by this folder name.
17:40And I would like to, you know, call it my clone or something.
17:43So I'm going to say get clone repository my clone.
17:46It says cloning and done.
17:49Now we have two folders.
17:51And if we go inside of the my clone repository, we should have the same state of code that
18:00we just cloned.
18:01So that makes sense.
18:04Now think about collaboration.
18:06We can change our code from the clone.
18:10And as long as the clone has permission to push back up to the remote, then it actually would
18:16work.
18:17So let's, let's, let's edit the readme file real fast.
18:20So I'm going to go nano readme and I'm going to say this change was made by the clone.
18:29Okay.
18:30So I did that.
18:31And actually just to make things interesting, I'm going to change my get identity only inside
18:36of this clone, you can do that in, in get, when you say get config and you say something
18:41like user.name, you know, you can put your name here, your email, whatever for like user.email.
18:48There's this thing that you usually do where you say get config global.
18:53And that means you're changing configuration that is a account wide.
18:58So like your entire account on this machine is going to be changed when you use that global
19:02flag.
19:03But if I don't use the global flag flag, it's just changing my configuration for only this
19:08one repository.
19:10So I'm going to make my name clone dude.
19:14And I'll make my email clone dude at a laptop or whatever at server.
19:22So now if I say get status over here, it's telling me, Hey, I have like a change.
19:27I say, get diff.
19:28And it tells me, Oh, look, I, you know, you changed that last line.
19:31So I'm going to add that change to the stage and then I'm going to commit it.
19:34And I'm going to say I added something to, to the read me.
19:42Okay.
19:44Get status.
19:46Notice how get status is saying something a little bit extra this time before we were
19:49just in a local file system only.
19:51And now we're working inside of a clone.
19:53So this is like, you know, you clone some code from GitHub or from your friend's server or
19:58whatever.
19:59And when you do a clone, it actually automatically links your local repository to the remote repository.
20:06By the way, in Git, everything is considered a local copy.
20:10So it's not like you're working with something different than the server has.
20:17You actually have the entire Git history and all the code and everything that Git has on
20:22the remote except for maybe some like configurations or something, but, um, when you pull, you're
20:29just making a copy, sorry, when you clone, you're making a copy later, we can push our changes
20:34to the server.
20:35And that just makes the two repositories talk to each other, sort of, and reconcile changes
20:40and make sure that both sides have, uh, the differences, I guess.
20:45So it's telling us we need one more step.
20:47It's saying, get status.
20:48It says you're on the master branch, your branches ahead of origin master by one commit.
20:54What's origin master.
20:55You can find out all of your remote connections and get by saying, get remote V.
21:01So when you clone, it automatically makes an origin remote.
21:04It calls it origin.
21:06And then it has the URL or in this case, just the file path of where the remote is.
21:11So it's telling you that our remote where we're connected to is the my repository folder
21:16that we were at in the left pane.
21:19So it's telling us also, if we go back to just status, it's telling us that we should
21:25use git push to publish my local commits to the remote.
21:29Cause at this point we're out of sync.
21:31If, uh, if somebody else cloned the remote repository and then made a bunch of changes
21:35and then pushed, then I would now be totally out of sync with that new person who cloned and
21:42also the remote server and it would create something called a merge conflict, which is
21:46like a little bit more advanced than this video.
21:49And we'd have to take steps to resolve it.
21:50So the smartest thing to do is, um, well, if you're coordinating with a team, make sure
21:56that everybody is, is designated a certain file or set of files to work on.
22:01And you all talk to each other.
22:03Hey, I just pushed some code.
22:04You need to pull, you know, Hey, I'm about to push hold off a second.
22:08You know, Hey, I just pushed, um, if you're working on something, you got to pull my changes
22:12before you do a push.
22:14Always push after you, uh, you know, commit so that everybody has the latest copy on the
22:18remote.
22:19So you don't cause conflicts with your, with your teammates or, you know, whatever.
22:25And always try to do polls regularly anyway.
22:28So I need to push my code.
22:30I'm going to say, get push and it's saying, Oh gosh, what is it saying?
22:38Oh, okay, okay, okay, okay.
22:43This is going to be a special setup that I have to do.
22:46Let me, uh, let me just very quickly revert what I'm doing here.
22:50I think I have to, uh, Oh, I know what to do.
22:54I can just make it a little trick.
22:56Usually the thing is they don't want you to push onto a branch that the remote has currently
22:59checked out into the file tree, but usually remote servers, they don't have a branch checked
23:05out.
23:06The file system on the remote, it'll actually all look like just, uh, this, uh, there's
23:12a flag called bear that you can use to make that happen, but I don't really want to go
23:16through all the steps right now.
23:17So what I'm going to do is I'm just going to make another dummy branch and then just
23:20kind of sit on it for a while.
23:22That way I'm allowed to push to the master, the master branch.
23:25So I'm going to say, get branch.
23:26This is how you make a new branch.
23:28I'm going to say dummy or something.
23:31Whoops.
23:31Got to spell branch, right?
23:34Then get checkout, uh, dummy and then get branch all and then get status just to make sure I'm
23:42now sitting on the dummy branch.
23:43And then this will cure the problem that we had a moment ago where we're not allowed to
23:47push to a branch that the remote has checked out.
23:49So I'm going to say, get, oh, wait, hang on.
23:52Got to go back in there.
23:53My clone get push.
23:56Okay.
23:56So now it works.
23:59Uh, so keep in mind if you're pushing to, you know, a remote that has a branch that's
24:02checked out, like it's another file system, like it's a friend's computer, you're going
24:06to have to worry about this sort of thing, but if it's a server like GitHub or just someone
24:10who has set some, set the repository up properly, uh, you won't have to worry about it.
24:15So, uh, forget about that for now.
24:17So I pushed to the remote, if I do get log over here, there's a mix.
24:23It shows, uh, you know, Mike created it and then changed it.
24:27And then the clone dude added something too.
24:29Okay.
24:30So if I say get log, we should now see the history for only the dummy branch.
24:35So that's just two things.
24:37And if I say get checkout master and then I check out and then I look at the log for the
24:43master, I can see all the changes that the other person made.
24:47Pretty cool.
24:49Um, I could also go back into the dummy branch if I wanted to actually used to do this a
24:55long time ago before I realized you should do a, a bear repos.
24:59Um, let's see how I check out dummy and then I'll say get log just to confirm that the changes
25:07aren't in there.
25:08So now we have two branches that are kind of diverging a little bit.
25:11The, the master branch has one more commit than the dummy branch.
25:14And if we let this go on for far too long, it might be more of a hassle to make the branches
25:19merge again, but I'm just going to merge them right now.
25:22So I'm going to say get merge, verify that you're sitting on the correct branch that you
25:26want to be the destination branch.
25:28So I'm sitting on the destination, the dummy branch.
25:32So I'm going to say get merge and I'm going to give it the name of the branch that I want
25:36to merge changes from.
25:37So get merge master.
25:40It's telling me that something happened.
25:41So if I do get branch again, one more time, I'm still on the dummy branch, but if I do
25:45get log, notice how I have that latest log entry.
25:50Pretty cool.
25:51So now I'm going to go back onto the master branch because I want to do some work here.
25:57This is a little clumsy.
25:58If we're talking about a server client paradigm, just bear with me.
26:02Now I'm going to make another change.
26:06Hi, Mr. Clone.
26:08Can you read this?
26:13So I'm going to make a change that I want the clone person to see.
26:18Git status, git add, the readme.
26:21You could also do git commit dash a, but I kind of don't like to because I'd like to remind
26:25myself that the stage is a good idea.
26:28Git commit new readme for cloney.
26:33Oops.
26:35Git status.
26:35Okay, so I'm not, I don't have a remote.
26:39I am the master.
26:39So there's nowhere to push.
26:41But now in the clone, I can say git status.
26:48It doesn't yet know that the remote has changes.
26:52I could do git pull to actually pull all the changes or I can do git fetch.
26:56Fetch will sort of talk to the remote and pull the changes into this repository's local copy
27:07of the remote.
27:08So if we do git branch all, you'll notice that we have a master branch here.
27:11So the master branch is my master branch.
27:14And all these other branches here are local copies of the remote's branch.
27:19So we're just making lots and lots of copies.
27:23That's kind of how git works.
27:25But now that we did a fetch, that talked to the remote, it grabbed changes.
27:29If we do git status, now git understands that we're actually behind the remote by one commit.
27:36And it's telling us, well, you need to use git pull to pull all the changes.
27:39Usually, you kind of don't need to do git fetch.
27:43If you have a remote, you just say git pull.
27:46You only do git fetch if you want to kind of see what's going on with the remote first
27:49before you actually try to pull all the changes into your branch.
27:53It's a more complicated situation.
27:54But so if I say git pull, now inside of my git log, I have that last change that the master gave us.
28:04So this is like a very, very basic workflow for git in terms of, you know, making changes
28:12to your program, committing the changes, you know, checking out the log, checking out what
28:17was changed, pushing to a remote, and so forth.
28:21The only difference, by the way, between using a remote that's a file system and using a remote
28:25that's GitHub is just what URL you put in clone.
28:28Like if I said git clone, I put a file path here originally.
28:32But if I just put a clone URL that GitHub gave me or your friend's server gave you right
28:37there, then it would work basically the same way.
28:39It's pretty sweet.
28:43Let's see.
28:43So those are the basics of git.
28:46Always make sure that you push to the remote so that the server has your changes.
28:50And if you're using GitHub or another website, it's usually a really good idea to push and
28:55then go to the website to double check that your changes actually made it.
29:02So we talked about tags and branches.
29:06This video is not going to be for advanced branching strategies, but there are lots of
29:10cool resources you can check out.
29:11Actually, you know what?
29:12I'm going to pull one up.
29:12Let's see.
29:15I'm going to edit this out if it ends up being like a really bad search result.
29:19Git branching strategy.
29:22So if you're working on a big project with a big team, let's see.
29:28There's one that I used to love.
29:29Where the heck is it?
29:33I think this might...
29:35No, that's not the link I remember.
29:37I should have bookmarked it.
29:38But there are lots of different strategies for how and why you would want to use branches.
29:46Let's see.
29:46One of these has a good diagram.
29:48This is it.
29:49This is not the same web page, but I think this website stole the diagram that I remember.
29:55So we've been on the master branch.
29:56That's like the right side here.
29:58You know, this little, these little blue dots.
30:00Imagine that every single time you want to create a new feature, you just create a branch
30:06and you name it after the feature that you're creating.
30:08I think I mentioned that before.
30:10That allows you to sort of keep working on the master branch independently of the feature
30:14that you're working on.
30:15And then later when you're sure you want to merge the feature into the master branch,
30:19then you just use a git command to make the two branches merge.
30:22Or if the feature turns out to be a bad idea, you can just delete the branch.
30:26Usually at minimum, most people will do something like this.
30:29They'll have a development branch.
30:31So here you can see the yellow dots.
30:33That's development.
30:33And what they'll do is they'll make all of their commits to the development branch.
30:39And then only whenever the program is in a really good state, like it's sort of presentable,
30:44you can actually release it.
30:46You know, you can let the public download it or you can let your friend run the code or whatever.
30:50Then you'll merge the dev branch into the master branch without deleting the dev branch.
30:55So you'll merge the dev into master every time the code is in a really good state.
31:00And then you'll come back on to dev to continue developing.
31:04I think most people call it develop.
31:05Actually, I call it dev for mine.
31:09And that way the master branch usually only ever is in a state that is good that people could clone from
31:15and just compile the program or use the program or whatever.
31:17And 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.
31:26So like version 1.0 or 1.2 or whatever.
31:30So branches for development where you're always there most of the time.
31:33Branches for feature when you're kind of experimenting and trying to figure out if you're going to be able to add something.
31:38Branches for there's a branch for the master where it's like this is the state that the public should see.
31:43The state that actually works.
31:45And then, you know, you might do a temporary branch for a hot fix.
31:51And sometimes people will do a new branch for a future release.
31:55Like 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.
32:03And kind of like merge changes from dev in that and just make sure that it's all good and it's great.
32:08And as soon as you think that the feature branch is perfect for your release, sorry, not feature branch, release branch is great for your release.
32:15Then all at once you'll merge that whole thing into master.
32:19You don't have to do it that way.
32:20It doesn't have to be that complicated.
32:21But, you know, sometimes it can be that complicated.
32:24For me personally, I usually just do a development branch and a master branch.
32:28And then sometimes when I'm taking a risk, I'll make a branch for, you know, I'll make a feature branch for like the new thing that I'm trying.
32:35Um, so I just kind of wanted to show you that for branching.
32:42And, um, we talked about pulling and pushing and cloning.
32:49Yeah.
32:49So 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.
32:56Or even actually this happens to people who work by themselves and they just switch computers a lot.
33:02Make sure that when you first sit down and you're about to start coding, you always pull.
33:07And if you're working with a team of people, communicate with them and tell them you're about to pull.
33:12Tell them you're about to start working on something.
33:13Tell them, tell them what you're about to start working on.
33:16Unless you have like a manager who's telling you exactly what to work on.
33:20Then it's their problem.
33:21Um, and then do your get pull and then work.
33:25And then every time you make significant progress, do a commit and then tell everybody I'm about to push and then push and then, uh, make sure that you just keep doing that.
33:35So if you go on your lunch break, make sure you push before you go on your lunch break.
33:40And when you come back from your lunch break, make sure you pull right away.
33:42Because 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.
33:49And sometimes it takes a lot of time to resolve the merge conflicts.
33:52So you, you, you really don't want to deal with that.
33:55And then, uh, a beginner's tip, uh, or I guess like maybe like an easy tip.
34:00I do this actually sometimes if you end 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,
34:12uh, merge conflict resolution type of situation, sometimes it's easier to just copy paste your folder somewhere else, rename it.
34:22Remember a Git repository locally, it's just a folder.
34:24So you can copy paste it or rename it or whatever you want to do.
34:27You just kind of copy paste it somewhere and then perform a fresh clone from the remote.
34:32Then 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, uh, on its own.
34:39So then you'll have your fresh clone and then you'll have your little backup copy of what you just screwed up.
34:45Then you can manually inspect the difference between the fresh clone.
34:49And 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.
34:56And then it should be okay after that.
34:58All right.
34:58So that concludes, uh, our Git basics tutorial.
35:01I hope you learned a little bit of stuff and had a little bit of fun.
35:04I will see you in the next video.
35:06Hey, everybody.
35:10Thanks for watching this video again from the bottom of my heart.
35:13I really appreciate it.
35:14I do hope you did learn something and have some fun.
35:16Uh, 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?
35:28Um, it would really mean the world to me and it'll help make more videos and grow this community.
35:33So we'll be able to do more videos, longer videos, better videos, or just, I'll be able to keep making videos in general.
35:39So please do, do me a kindness and, uh, and subscribe.
35:43You know, sometimes I'm sleeping in the middle of the night and I just wake up because I know somebody subscribed or followed.
35:48It just wakes me up and I get filled with joy.
35:50That's exactly what happens every single time.
35:52So you could do it as a nice favor to me or you could, you could troll me if you want to just wake me up in the middle of the night, just subscribe and then I'll, I'll just wake up.
36:00Uh, I promise that's what will happen.
36:02Also, 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.
36:11And 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 offer and all that good stuff.
36:20And, uh, if you have a suggestion for, uh, uh, clarifications or errata or just future videos that you want to see, please leave a comment.
36:31Or if you just want to say, Hey, what's up, what's going on?
36:34You know, just send me a comment, whatever.
36:36I also wake up for those in the middle of the night.
36:37I get, I wake up in a cold sweat and I'm like, it would really, it really mean the world to me.
36:43I would really appreciate it.
36:44So again, thank you so much for watching this video and, um, enjoy the cool music as, as I fade into the darkness, which is coming for us all.