Essential Git - All You Need to Know to Use Git Effectively | Jorge Escobar | Skillshare

Essential Git - All You Need to Know to Use Git Effectively

Jorge Escobar, Technologist, entrepreneur and open source fanatic

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
37 Lessons (1h 21m)
    • 1. Introduction

      1:27
    • 2. What is Git

      0:23
    • 3. Installing Git

      0:18
    • 4. Installing GIt on Windows

      3:28
    • 5. Installing Git on Mac

      1:48
    • 6. Checking if Git is Installed Correctly

      0:22
    • 7. Git Fundamentals

      0:15
    • 8. The File Status Lifecycle

      2:02
    • 9. Visual Workflow

      1:35
    • 10. Starting with Git

      0:16
    • 11. Basic Operations 1.1

      3:34
    • 12. Basic Operations 1.2

      2:51
    • 13. Basic Operations 1.3

      4:37
    • 14. Basic Operations 1.4

      2:33
    • 15. Basic Operations 1.5

      2:15
    • 16. HIstory of the Project 1.1

      2:55
    • 17. HIstory of the Project 1.2

      2:25
    • 18. HIstory of the Project 1.3

      1:31
    • 19. Other Basic Operations

      5:50
    • 20. Undoing Things

      3:42
    • 21. Unstaging Files

      3:29
    • 22. Introduction to Branching

      1:19
    • 23. The Commit History

      2:27
    • 24. Merging Branches

      1:13
    • 25. Branching in Action

      3:44
    • 26. Merge Conflicts

      2:01
    • 27. Rebasing

      3:57
    • 28. Interactive Rebase

      3:37
    • 29. Tagging

      0:55
    • 30. Remote Repositories

      0:35
    • 31. Setting up a Github Account

      0:20
    • 32. Creating SSH Credentials

      1:58
    • 33. Our First Remote Repository

      1:19
    • 34. Remote Repository Operations

      3:03
    • 35. Git Fetch and Git Pull

      2:56
    • 36. Git Remote Branches and Tags

      3:25
    • 37. Conclusion

      0:35

About This Class

0e75d111

Why spend hours learning all Git and Github? Learn the parts professional developers use and get on with your coding.

This course simply teaches what you *really* need to know about Git. After working professionally with Git for more than 5 years with large and distributed teams, I will show you, step by step and cutting out all the fat, what Git is, what’s the use case behind each feature and how you can use it effectively like most professional web developers use it.

The course starts assuming you know nothing about Git and step by step explains the theory and introduces each command, progressing in a smooth, logical flow.

Additionally, you will be able to purchase a complete book of the whole course, so that you have an easy reference to all the knowledge.

The course has more than 2 hours of video tutorials and you can also purchase a book that covers all of the video content, so that you can refer any information in a printed format.

If you search on the web, you’ll find hundreds of courses, videos and other resources about Git, but it’s work that’s incredibly tedious and leaves more questions than answers. You can also buy a “Pro Git” book and try to learn all of Git as if it was your end goal. The truth is Git is only a very basic utility tool that you shouldn’t be thinking about. You should spend your valuable time learning more productive things, like computer languages. With this course you’ll get that level of comfort, knowing you will be using Git without thinking about it.

The course is divided in 8 sections:

  • Introduction
  • Installing Git
  • Git Fundamentals
  • Starting with Git
  • Git Tools
  • Git Branches and Tags
  • Remote Repositories
  • Git Workflows

Also, at the end of the course, we have a collaborative project that uses all the knowledge from the course and leverages Github as a community platform.

Additionally we’re constantly updating the course constantly, adding lessons thanks to the feedback of our students.

So stop feeling like Git is something complicated. You need this tool to become a successful, professional developer. Git is not hard.

Enroll now and learn the essential Git and move on the important stuff... like coding.

Who is the target audience?

  • Software developers who want to learn Git from scratch

What Will I Learn?

  • You will be able to start a Git repository from an existing project or clone a project hosted on the Internet.
  • You will become knowledgeable with the Github portal and how to use it professionally.
  • You will obtain a fundamental understanding of how to manage remote repositories.
  • You will learn the theory of and why branches are important.
  • You will participate in a Git collaborative project with other developers.

Requirements

  • A computer with internet access and administrative access to install packages
  • A basic understanding of how to use the internet and text editors

 

Transcripts

1. Introduction: welcome to Essential Gate Second edition. My name is Jorge Escobar and I have been managing development teams that use get on a daily basis for many years, and I know firsthand how important it is to be fluent in this fundamental tour. I also happen to have started my own nine instructor career teaching this course, and after thousands of students enrolled, I have decided to make this second edition that improves and expands the material on this wonderful place. Get has a lot of queers, and it does have a wide range of features. But to be honest, most professional developers only use a subset of the tool in their day to day job. So the goal of this course is that you understand from the verdict gaining and without any previous experience, the essential parts of kids that you will use managing sober development in any professional, that company. We'll begin our journey by introducing the concept of version control and why it's important we will dating still get over the file status lifecycle, get comfortable through hands on exercises with our first project and finally learn all about branching and remote report. Of course, we will look at some of the different workloads used today, and finally we will all work together in a real world wide open source project called the Global Restaurant Guy. So let's start learning the essential get. 2. What is Git: get is a version control system, or VCs, that allows developers to improve the way they work under code, as well as collaborate easier with other developers in software development projects. Since its inception in 2005 gate has become an essential tool for anyone wanting to work in the computer software industry. 3. Installing Git: there are multiple ways to install. Get on each operating system. If you have Lennox, give Usually calm springs told or just used are getting stuck it on a boom toe or young star kid on red hat. Let's check what are the best options based on your operating system, Windows or Mac. 4. Installing GIt on Windows: if you have Windows 10 the best alternative to install gate is to use Sugar Lady Ah, Windows Package manager similar to up get and human Lennox to install chuckle lady, head over to their website and read the instructions. They might have changed recently, but this is how I do it today. To begin the process, open the windows Power Shell and located here on the windows menu. Now, once you open that, you want to run this as an administrator. So you want to right? Click on the icon and select run as administrator. This will display a prompt you press. Yes, there. Spend just closed the older terminal and make sure that you have administrator here on the top of the window. You know, usually power shell runs with a restricted execution policy, which will be a problem if we want to run the shock. A lady install script. So change days by doing the following command. Said execution policy and type on restricted. Now you will get a prompt. That says if you want to do this to suppress yes. And now we should be good to go now to install Chuckle Lady, just click on their install option and copy and paste this command here. Press enter. Perfect. So we already have articulating stole, and we need to ah, restore the power shell so we can close that. So go ahead and open the power shell again, and you have to do the same thing open. That's administrator. And in that new window check that you have administrator in there close the older brother window and then just tied Choco in the prompt. And if you see Chuckle lady version, something there Ah, then that means that sugar ladies properly set up. Finally, we can install get by doing the following command Chuckle, Install git, Dash, Grimes and this strength and we just press enter. You want to say yes to run the script and perfect It was installed successfully. From this point on, whenever I mention opened the terminal and referring to the windows get Bash program. Although Power Shell is a better terminal program than the regular Windows Command line, it is still not as compatible with UNIX terminal commands. So we're going to be using that from this point on to get to the git bash. Just look at the windows menu and get to get back here, and that will open the git bash prompt 5. Installing Git on Mac: the best way to install Get in Mac OS is by using Homebrew, which is a package manager similar to red hats, Young or a Bhutto's app. Get to install home brewing your computer, head over to their website at brew dot s age, then open a terminal window. You can find it on the Applications Utilities folder or by doing a search by pressing command space and then typing terminal. Then copy and paste the command from the home brew. Install code after installing do brew doctor to see if everything is fine and then do brew update to hit the latest updates to the program. Finally type, brew, install, get and you should be set to start using. Get if for some reason you don't want to use homebrew and you are in Mac OS 10.9 Mavericks and above, you can install. Get by using the X Code development tools. Just open the terminal and type git. You'll get this prompt. That, says the give command requires the command line Developer tools. Would you like to install the tools now pressing still button and you wait for the installation to finish. However, this is not the best way to install get. Since this method usually installs an older version, I really recommend you use Homebrew as described in the previous section. 6. Checking if Git is Installed Correctly: to verify they have get install right get in the git bash windows or in Mac OS 10 Terminal , you should see a list of available commands to see what version of get you have just type get dash Dash version. 7. Git Fundamentals: in this section, we will be introduced. Toe gets vile styles, lifecycle. We'll also learn why the terminal is the best way to your skin and some of the most useful command line tool for found management. 8. The File Status Lifecycle: if there's one fundamental concept that you need to understand is how get manages its files and the stages they go through as you work on them. This movement between stages is called the file Status Lifecycle, and here's how it works. As you can see here, there are four faces of Falcon go through when they are contained in a directory managed by get. Depending on the work you're doing on them. The files can go through each of these faces many times. When a fellow is in one of these stages, we say it's in a specific status. Let's review each status. When you first create a file in a get folder. The file is assigned and untracked status. This means that get is not actively watching this file, and it will be ignored if any changes accord to it. There are some files that we want to leave untracked in a project. For example, temporary files or setting files, we can tell get to ignore specific files or file patterns using a special file called Git Ignore, which we will look at later. In the course. When a file is added to the repository, it will enter a tract satis from this point on on until you changed his status to untracked Get will be watching this file actively, and any changes you make to it will be noted. A truck file that changes. It's marked by Get Toby on a modified status. It's means that the file has spending charges that need to be completed at some point. In a way, this is consider an unstable or dirty state because at some point the file changes need to be completed and moved to the next face. A file is on a stage status when their work has been completed and it is ready to be included on the next snapshot that will be taken off that project. These snapshots are called comets. 9. Visual Workflow: now, Don't worry. If you don't understand all of these stages immediately, let's try to picture the workflow with an actual file that we're working on. First will create a file in a directory that has been initialized as a get project. As you can see, the foul was just created and get is not watching it. It's on a untracked status. Forget to start watching this file. We issue a command that will move it toe attract status. The command is called get at once that files being tracked. Any changes to it will be detected by get. Let's say that now we start working on that file and we do some changes to it. Once we save the file, get gold market with a modified status, we can now change the files that will be included in the next commit. Once we finish working on all the files we need and we're ready to save a snapshot, we issue the gate at command. Once again, this puts the file or files into the stage status. At this point, we're confident the work is ready to go out. Either we will push it to a production environment or we want all the developers to check our work and we finally issue that get commit command, which will take all the files back to the track status ready to begin the whole process again. Finally, if for some reason you elect toe on track the file, it would fall back in the untracked status. This would also be the case if you delete the file. 10. Starting with Git: in this section will start playing with get will create a repository, check the history of defrauding and very important how toe onto operations. But first, let's learn some basic commands to navigate the bowel system in the terminal. 11. Basic Operations 1.1: go ahead and open your terminal. Get bash on Windows or terminal Mac, and you should get a prompt ready for your commands. One of the most important things you will need is to know where you're at at any given moment. When you started terminal for the first time, you are placed in your user's home directory. This directory is where you normally put your own files. Now type P W D P W D stands for president Working Directory, which, as you can see, is your user's home page. The Home Directory is also referred as the tilde directory. If we wanted to see the contents off this directory, you can use the L S command. As you can see here, we get a list of the files and directories on your home directory. However, the file system might have hidden files in there. This hidden files can be temporary files that are being worked on setting files or even whole directories. As a matter of fact, we will see later in this section that the Git Directory is a hidden directory. To see these hidden directories and files we used to command LS dash a the dash a After the command is called a flag. The A flag for the L s command lists all the files hidden or not hidden as you're getting for hidden files or folders, start with a dot. There's another flag called Dash L that lists all the details of the file, including the permissions user and group owner and size. There are commands to handle these file properties, but we don't need to get into these for the purposes off this course. Finally, we can combine the A and L flags in one and get both all the hidden and on hidden files along with their details. If you want to clear the screen, you can use the clear Command or hit command plus K on Mac or control L on Windows. So let's start our first get project by creating a new folder, trade a folder, just type the following command. Make dear test kit and press enter. You should get the prompt back as if nothing happened. But now, if you type ls you should be able to see the directory. They're Now we need to change to that directory so that we can start working on our first git repository. The way we do that is by using the CD command, which allows us to change to a directory. So we do the following CD. Task it. Notice how the prompt, which is the text before the command, not reflects that we are in the task is directory. If you do on LS. Now, you will see that we have an empty directory. I useful command we will be using a lot is the clear command that clears the screen so that you can get a blank slate to continue working in Mac OS. You can also use Command plus K and in the Windows Git bash, you can use control out. Let's clear the screen and start working on a first gate project. 12. Basic Operations 1.2: make sure you are on the task it directory by typing pwd and confirming you are in that folder were ready to initialize our first repository. So all you need to do is type the following command. Get in it get will confirm they have created a new empty repository in the hidden folder. Get within the task it directory within this hidden folder, get will be tracking all the changes you make to your git repository. You can take a look at its contents by doing ls Docket. You will see a bunch of files and directories that get uses internally, but you won't be interacting with them too much. With the exception off the conflict file, the conflict file keeps a number off settings regarding the repository. Take a look at it by using the cat command. With this command, you can see the contents off any file so you can do cat Dugit conflict. Let's go ahead and use a new command called git status. Get status allows you to see the current status off a repository. He tells us that we're on the master branch, the master branches of the full branch that a repository starts in. We learn more about branches later in the course, we also see initial commit, which basically tells us we're working towards our first option off this repository. Finally, get tells us that we have nothing to commit to the snap shirt and that we need to create or copy files and then use get add to start tracking them. But before we actually start doing any file operations, we need to tell, get who we are and we do that using the git config command. So go ahead and type the following two commands pressing. Enter at the end of each one. Of course. Use your own name on your own email. This settings will be saved on the conflict file inside of the good directory, you can check this out by typing cat Don't get slash conflict. One word of caution here, you need to do this every time you start a new repository. If you want to avoid this and just want to have it preset for all repositories, you can pass dash, dash global after the conf equipment. Personally, I like to do it every time. I rather have control on the giddy user as I start a new project 13. Basic Operations 1.3: so we're finally ready to create a new file. Since I'm using Adam, I just write the following command to create a new file called Test Txt that will open the Adam editor with the file test txt open, you might need to close the world come taps that opened by default. If you get an error related to the Adam Command not found open Adam manually and on the Adam menu, look for an option that says install shell commands. If this still doesn't work, you might need to open the folder manually using the file Open Command type any text in the editor window? I will just write test number one. Notice how there's a little blue dot next to file name that tells us that the file hasn't been saved. Save the file by going to the file menu and clicking safe or use the keyboard shortcut. Command s on Mac or control s on Windows. The little dots should disappear. Always refer to this when working with files, many times honorable getting explaining related to us, not saving the file. Also, two things happen here. One is that the following turned green. This means that we have changes to this file that haven't been yet committed. The other is on the bottom right off the editor. You'll notice a plus two indicator, which means you have two lines that have changed on the file that are not yet committed. If you hover over the indicator, you'll see a more detailed message. So let's go back to a terminal and see if get detected this file change type, Get status, and you should see the following output. Get now tells us that we have untracked files and that we can add them to our next. Commit by using the gate at command. These files will be ignored by get, no matter how many changes we make to them. So let's see where we're at in the git workflow, as you might remember from our an explanation of the get file status Life cycle, this is the very first stage where the files are on the contract state as they're being just created. We're ready to start tracking this file, so let's add it to the repository. We can do that by typing, get at test dot txt and empress enter. Apparently, nothing happened, but if we now type get status. This is what we get. As you can see now we get a message saying that we have a new file in a green colored front , and we also are informed that this file is ready to be committed. Let's visualize what happened. The file moved from the untracked status all the way to the stage status. Get just days because he considers this foul ready Toby committed since you added it after finishing all the work you were going to do on it. Now let's take our first snapshot. We do that with the get commit command. Get commit, will take a snapshot off all the files that are on the state status and group them in one package we call commit. So type the following get comment. Does m our first coming? Here's what we see get is telling us that one file change and that there was one in search in which corresponds to the one line we created on the test txt file and finally and very important that we have a snapshot identified with the string one B F zero f C. Before this is called the hash, and it's a unique identify for this commit. From this point on, I can come back to the state of the project as it waas by this moment of time by using that identify now, if we do a get status, we will see that we're on a clean slate and that there's nothing to commit. Now let's see this on our file status. Life cycle diagram. As you can see, the file was incorporated into the snapshot one B F zero F zero for with the current state of the file being stored in it. After the committee was generated, the file immediately moved toe the track status on into a clean state. 14. Basic Operations 1.4: So now let's go ahead and make a change to the file. You should still have the atom editor open and, if not opened the test. Txt file again and insert a new line test number two and then save. As you can see, Adam marks a new line like Number two with a green bar, which sing us. This is a change on the file. It'll to this place plus one on the lower right indicator, telling us one more line was added to the file. Now let's do it. Gets status to see what has happened here. We can see get has marked the file in red again, but this time it's in a different status modified. In order for these files to be considered for the next snapshot, get tells us we need to get at the foul again. Since this foul was on the track status. Any changes we do to it are being picked up by Kidd. Why doesn't get just added to the stage status? Well, think about it. You might have saved the file, but that doesn't mean that you're done with the work. Not only that, it might be necessary to change other files before we're ready for the snapshot. So if you do changes and save them, it doesn't necessarily mean the files are ready to be committed. Let's see what just happened on the file status lifecycle. He would see that the file now has a second line test number two, and that after we saved it, it was moved to the modified state. So let's say we have completed our changes and I want to create a new snapshot with occurring file modifications. We just need to issue the gate at command again using get at test dot txt analysts to another get status. Here we see the file again in green color and get is telling us we can now commit this foul as it is now on the stage Stars. Let's see this officially, as we can see here the fouls back on the stage status. We're satisfied with the changes, so we'll go ahead and commit this change by issuing a commit command. Once again, Get has generated any hush for us this time. It's before eight f A b b. We are again in a clean state. So this is our status now. First we committed the second file change and then the foul went back to the track status on a repository, returned toe a clean state. 15. Basic Operations 1.5: Okay, so now we'll do something a bit different. We will notify our test txt file, but also at a second file to the repository. So open Adam again and at 1/3 line toe the test txt file and save it. If we do a get status, we get the following. No, let's add a new file. Go to the Adam File, select new file from the menu and add one line of content second file. When you save it, Adam will ask for the file name. Just enter food or txt. Now do a get status and you should see the following get is saying that we have two different buckets. The first is that test txt file that's not ready for committing, which means get things were still working on it. And the four txt file, which is in an untracked status at the moment. Here's what this looks like on the status lifecycle. So that's a Our work is done, and now we want to add the new file full txt to the repository and also move the test txt file to be ready to be staged. We can do a get ad with each foul or we can do the following command. Get add dot notice. There's a dot at the end of the command. This will add all files on tract and tracked toe the staging face. Now, if we do a get status, we will get the following in visual terms. This is what we have now. Both files are ready to be committed and we can do that by doing the following get commit dash M third commit. Notice how we have a new committee Hash FC 96349 And that get is reporting that two files were changed and to total new lines were created. So in the file status life cycle, we see how we created the new snapshot and then the files are back on the track status. 16. HIstory of the Project 1.1: as we have seen from our interactions with get. There's a concept of history built in as we move along. In the development of the project, each commit is like a photograph, often organism as it grows and grows frequently. You'll want to review that history to make sense of the current state of the project or potentially resolved an issue that might have been introduced in a previous comet. The main way of interacting with a history of the project is by using the Gate Lock Command . So go ahead and type. Get log and you will see something like this. Here you see all the commits we've done in our project so far, but notice there in reverse order. Our last commit is the first on the list, and the first is the last. The first night on each entry is the full commit hash. I noticed that it is longer than the ones displayed after the committee is done. This is because we can reference most commits with the 1st 7 digits, since there's already a good amount off uniqueness. But internally that hash is even longer. To make sure it is almost impossible to have two of them that are the same. The second line displaced the full name and email off the author of the Comet. As you can imagine, this is the same information we entered when we set up our user in the get come fake command with it. Earlier, the third line displaced the date and time of the committee with the Time Zone Delta. In my case, it's minus five because I live in the East Coast of the United States. Finally, we see the commit message we entered when we created the snapshot. One thing you'll notice is that if the output is larger than your current screen, you will get the contents off the log. In a paginated program called less, you can tell if you're in less mode. If you see a semi colon in the bottom of the screen in this mode, you can navigate through the contents of the file by clicking on the up and down arrows in your keyword to advance line by line, you compress the space key toe advance one full page and the beaky toe back a full page. You can also search for a string inside this window by typing the slash key and then entering a keyword m pressing enter to quit. Just hit the cuchi. If you want to always get the full output to the screen, you can change this behavior by using this conflict Command get config core pager cut. That will make the change just for the current repository. If you want to make this change for all your reports, just at the that stash global flag after the confirmed word, if you want to change it back to the way worse, replace cat with less on the conflict command above. 17. HIstory of the Project 1.2: If we want to see just the last X commit, you can pass a number after the get lock. A man with Dash, for example. To see the last two commits, you can do the following gate Log dash to another useful flag is dash Dash one line, which displays all the commits in just one line by listing the short version of the hash and the commit message. This is what that looks like. You can also combine flags. So, for example, if I want to get just the last two commits in one line, you can do the following Get log Die stash one line Nash, too. There are some useful time century filters that you can use, and there are three flags you can use for this since before and after. For example, let's say we want to get all the commits that happened before March 15. Off 2017 you can do good log Dark stash before equals 2017 03 15. You can also see the ones after March 1st of that year. Good log, dash dash After 2017 see or three serial one. You can put a very precise time and date by using the follow informant. This actually will display the last Commit on my Repo as I only have one. Commit after three PM off that date. Good luck. Dash Dash after equals. 2017 0307 15 0000 minus 0500 You can also use natural language for the ranges like get log . That stash since equals two days ago. Get log that stash after one week ago or get log that stash before equals one month ago. You can also search by the person who committed the changes like Git Log Dash Dash Author equals Jorge. You don't need to put the full name. It will search all commuters whose name starts with Jorge. There's a number off other options available that you can explore by typing. Get help log 18. HIstory of the Project 1.3: If you want to see what the court based looked like at the time off the snapshots, you can do so by using the get take out command. For example, let's see what our code based looked like other time off. The first. Commit first to a good log to get the hash of the commuter interested in, and then copy the 1st 6 or seven characters. In our case, it's one B F zero F zero. Then enter the following command. Get check out one B F zero F zero get alerts us that this is a detached head, which means we cannot do changes and commit to the repository from the state. But we can look around us much as we want. If, for any reason you want to save this as a stable state or start developing from this point , you'd need to create a branch from this commit. We'll take a look at branches later on. If you take a look at the test txt file on Adam, you'll see that it has just the first line test number one as it waas. When we first committed, you will also notice that the full txt file is gone. This simple exercise shows you the power off get and how everything we do is being recorded step by step. To get back to the normal state, you can do get check out, master. 19. Other Basic Operations: Let's see other useful git commands. The 1st 1 is get move. Let's give it a try. It moved. FOOD TXT BAR txt If you do an LS, you'll see that the file was moved or rename. But if you do get status, you say that the foul is in a state status, which means it would be considered on the next commit. Let's commit the change. Get commit that M moved for txt Tobar TXT. If you now do a get status, you'll see that the repository is back in a stable state. Another useful command is good removed. It allows us to remove a file. That's right. Get RM bar txt now, if you do on LS, you'll see the file has been removed from the file system, but once again, of repository has changes to be committed. Let's do a get status we need to commit to make this change permanent. Get commit Dash M removed Bar txt. It's important to note that both get, move and get remove can be used for both files and directories. There are certain files or types of files that you might not want to include on your repository ever files like temporary files or local setting files or cash files. It allows you to avoid adding those files or tracking them by creating a special hidden file. Cold get ignore. One common example is a swap file generated Every time we're editing a file, let's create one manually by using the touch Command touch test, not txt dot swp Touch is a UNIX utility that creates an empty file quickly. Now, if we do a get status will see that the file is detected by get. But we know for sure will never want to add any files that end on dot swp. So we'll create a getting nor filed with Adam to ignore these types of files. Inside the file we type star dot swp. That means that any file ending on dot SWP will be ignored. Save the file and do another get status. Now we see that the file is no longer pending. Toby at it, and now get Ignore is the one file pending. Let's add to the repository and committed. Now, if we try creating another swept file, you'll see that it's ignored a swell one more commander you'll use in certain situations is get there with this command, we can see the changes that we've done from one snapshot toe another or from one branch to another. Let's first with small change on test txt at the line test number four and save. Then go. I get ad and check gets status. Now we can see the changes that have been states so far by typing kit. They've that stash staged you can or some of the information here. But as you can see in green letters, get is telling us that the line test number four was added. We can also see the changes from our last commit and say the commit where we removed bar txt do a gate log one line first to see the commit hashes Then we can do the one we want by doing get if for 1 61 70 in here again, we can see young green that we added to get ignore file with the text Swb and we also see that we added test number four on test Txt But wait, why don't we see that bar txt was removed? The thing is that get if is giving us the changes between the two commits, not including the changes that happened right before that one. So when we committed for 16 d 1 70 the file had already being deleted. There are cases where it's useful to use a special character, the carrot toe, the note, the parent off the commit we're checking. We will use the carrot in a couple of examples in the next section. But just think of it as the previous commit off that committee, referring to so back to our example. We want to see the changes between our last commit and when we removed bar txt, including the change injected in that commit. Then we would do get if for 1 61 70 and then at the carrot. Now we can see the deleted file section Unready Fund to see the changes between the current commit on the previous one. We can use the following get if head character. Finally, we can see changes between two commits by putting two dots between the hashes. For example, we can see the changes between the second commit on the third. Commit by doing get if before eight F a B b dot dot FC 96349 Notice the order of the commits. You want to do the oldest first 20. Undoing Things: There are things we want to undo after we have pressed the enter button on our keyboard and get allows us to and do a lot of them. Let's see some of the ways we can undo things in Get. As you might remember, we have staged changes on a repository after we added the test number four line on test dot txt. Let's commit the file. But now let's say we don't like that commit message. We can do the following get commit dash dash amend. This allows us to change the commit message by presenting us with a simple text editor called V I to edit the name we need to hit the I key toe enter insert mode in this editor change to commit message and then hit the escape key than enter Colon Plus W. And then the letter Q. Here I changed to commit message to read added Important line on test. Txt. Now, if I see the last commit message, I see the corrected commit message. If you don't want to deal with the V I editor, you can change the editor, get uses with a command, get come fake core, dot editor and then the name off the editor. In my case, I want to use Adam as my editor. Remember to pass that Steph's Global. If you want to make this change across the board, the command to be used is get come fake core dot editor quote Adam Dust Ash weight in court . Let's try that again. Notice how get opened the atom editor. I can do the changes to the commit messages and heat safe. The caveat is that the commit message is saved only when you close the editor. So if you have the editor already open, it opens a new editor window, make the changes he'd save and then close that Adam Window. Another use of a man is when you forget to add a file to a commit he just completed. So, for example, let's edit test txt and at a lying toe, it test number five, save it, do get at and then get commit. M new change to test txt. But then you realize that you needed to add a new file. Food are txt to dis commit? No worries. Just great the file at some content. Save it and then get at dot and now, instead of a regular regular commit, you do get commit dash, dash a man. As you can see in the commit message, there's the modified file test. Txt. But now we're adding food or txt, and it's all going on the same. Commit. We can change the common message if we wanted to. You can also do further changes to an already committed file and incorporate those changes to the existing commit Go ahead and add another line toe test. Txt like death number six. Save the file and do a get at now. Instead of doing the regular, commit to a commit amend and you'll see that the file appears has modified. Save the commit message and close the window on your changes will be incorporated. 21. Unstaging Files: So that's a you created a new file called Bar Txt and you added to the repository. The father is now on the state status ready to be included in the next comet. But what if we change our minds and want to continue working on this foul and not included in the next commit get is already kind of telling us what to do. You just need to issue the following command. Get reset head bar txt. Notice that the foul went back to its original status, which waas untracked. If you try doing this with a truck file like testy Eckstine and you re sent that file, it takes that file back toe the modified status. There are certain times when you have made such a mess, looking for a solution that you just want to undo all the changes back to when you last committed or even toe the previous commit. Even though you might think that this is an unlikely scenario, it happens more often than you think. So go ahead and make some changes toe the text txt file, go nuts and change all the lines if you want. Now save the file and check What gets status is as you gonna read, get tells us that we can discard the changes in the working directory with a check out command. So go ahead and type the following. It's extra fun if you do it while keeping the Adam window in view. Get take out dust ash test txt Magic The fathers Now exactly the way waas Before we did the changes. Now we're gonna do something similar, but this time change multiple files and put a bunch of random texts in them, making sure to save them, do a get status and make sure they're old Change. Now we can issue the following command. Give Reset Head that stash heart. This will take all the files in the working directory to the state. They were on the last Commit after you press enter, check the files on you should see they're back to their original state. Now let's say we have already committed a bunch of bad code. So go ahead and change all the faults again with Give a Ridge. But this time around saved the files. Do I get at and commit them using the commit message? Bad commit. Let's see the get logged us to to see the new committee is there, but now would realize this whole committee is wrong. Back code or around. What can we do? Thankfully, get makes it easy to discard this. Commit and go back to the previous commit. Just used the following command. Give reset head carrot that stash hard Notice We have a carrot next to the head. Remember what that was, right? The carry would refer to the parent. Commit off the one we're referencing after you press enter, you should be taken to the previous commit on. The fouls should be in the original states. You can check it by using kid log and that's the end of this section. Hopefully, you now have a good graphs off the power of using gate. Go ahead and practice what you've learned and I'll see you back in the next section. 22. Introduction to Branching: a basic component off get is its branching capabilities. It used to be very complicated to do branching in other version control systems and get really brought this capability to developers in a seamless way. But what do we need? Branches? The answer is simple. You need to keep different streams of work for separate use cases. Ah, basically, example is the typical architecture of an application. You normally have a development environment where developers are actively working on the new features. A staging environment where more stable code is being tested by other non engineering teams in the company, like the Quality Assurance team product managers or the sales team. And finally, a production environment where the code that has been tested can be pushed to the rest of world. With it, you can have a branch for each one of the environments, and you would start work on the development branch, and when your work is good, you could import or move that work toe. The staging branch on After the testing is done, moved the CO two production to be consumed by your users. This action off porting or moving code is called Merging and Get allows you to do this easily with the commands we're going to see in this section 23. The Commit History: Let's quickly review the commit process. Let's say you have a repository with three commits Master is that the full branch get creates when you initialize a branch, so even though you don't know it, you have actually being working with a branch. Already. Master is usually the branch associated with the production environment. In tech companies. Most teams talk about master as the main branch where stable code is stored. Now we create a branch. We would do the following get branch new feature. Don't do this just yet on your terminal will do it step by step later. Now, with this command, we have two following. As you can see, there's no new branch per se. Both master and you feature point to the same commit, However, get knows we're currently working on the master branch. What both master any feature are cold pointers, and that's basically what branches are. However, there's another important pointer called the head, which points the local branch you're currently on in order for also start working on the new feature branch. We need to switch to it and we do this by using the check out command get take out new feature notice how the head pointer is on the new feature branch. This is our signal. We have switched to that branch. Now let's say we work a bit on the code, change a couple of the files and now commit. Let's say the new commit hash is B F 98 both the head on the new feature Pointers moved ahead one step from master. Now let's say we have a bug and we need a quick change on Master with which to master by doing get check out Master. Now let's say we completed the work on Master and committed. We'll get a new Kamina hash A 32 and we would have the following. We can now see that we have a more visual concept of a branch. This is called a divergent history. Notice how easy we can switch back and forth within branches, using the check out command and continue working on each branch 24. Merging Branches: continue with the example. Let's say that we have completed the work on the new future branch. We did a check out on the branch. Did one more commit and now we need to incorporate those changes back to the master branch . This is what we have at this moment. We can now do what's called a merge. It does this by looking at the new changes. Don't in the new branch and adding those changes to the files in the master branch. To do that, we need to do get check out, master and then do get merge New feature. What happens at this moment is that get looks at all the changed files and incorporates those changes to the master files. I generates a new snapshot. See a 11 that has all the changed files. Notice that this committee is special in the sense that he has more than one parent. This is called a merge commit And yes, the head is now at the C a 11 commit. You can now tell it this brunch by doing get branch dusty new feature 25. Branching in Action: Now let's try doing these operations in our terminal. Go to your home folder by doing seedy till D create a new folder and initialize the repository. Set up your name and email with git Config and now great a file called Test Txt and put one line of code in it at the file to the repository by doing get at dot and now committed a named a comet. First, commit now. Repeat this operation two more times at a new line. Do the get at dot and get commit unnamed to commit second commit and third commit. If you do a kid log, you should see the following. Now let's do our first branch just to get branch new feature and press enter. You cannot see that the branch was created, but issuing the following command get branch. As you can see here, the master branch has an asterisk next to it. That means that the head is currently pointing to master. You can also see the new feature branch in the list. Let's change the head toe the new feature branch Give check out a new feature Now the head is up. New feature. Let's do a change on the test Txt file at the bottom type. This is a line in the new feature branch. No safe and commit. Now switch back to master and create a new file called Test to txt at some content with save it at it and committed. We now have a divergent history with master and new feature in different paths. Switch back to a new feature using get take out new feature Notice how test txt disappears from the file system Do another change on test txt Get ad and committed Now try doing a good luck One line Notice how their history only shows up until we diverged and the log has no record of the last. Commit with it in master Let's pretend we finished the work in the new feature branch We no need to merge the changes with it on the new feature branch into master. So let's do a get check out Master to switch to the master branch and then do the following Get merch new feature Notice how we get the editor as if we were doing a commit which we are. This new committee will be the combination off the work with it on new feature and the last commit on master. Enter a message for the commit and safe. Remember, if you're using the V I editor, just type the eye for interactive mode. Type the message, then do escape Cullen and then w and cute notice how the changes would it in test txt are now in the master branch. Now, if you do a kid loved one line, you'll notice that the commits with it a new feature now appear as part of the history off the master branch. Finally, we can delete the new feature branch. Since we're done working with it, get Branch Dust, the new feature. 26. Merge Conflicts: Often you'll find yourself with Merche conflicts. When get tries to merge the content off a foul from two different branches where it doesn't know exactly how to merge it, it will throw on air. Don't worry, this is easily fixed. Let's create another branch. Let's call it appropriately conflict. Here's the trick you can do when creating a new branch instead of creating the branch and then doing a check out, you can do get check out. That's be conflict that will create the branch, and we'll put the head on it. Now change like three intestine 60 with some text. Save it, get at it and committed. Now Check out Master and Change Line three as well On test txt. Save it, Get out and committed. Now try to merge the conflict branch into master. You will get a conflict error. Open the test txt file. As you can see here, get is confused with Line three. Which one is the right one? Get doesn't know. So he displays the version on the head or master and diversion on the conflict branch. Get has effectively paused the merch process until you resolve this and then you can commit when you're done. If you need to see the files in conflict, just type get status. All you need to do is edit the file and keep the version you want, making sure the file looks like it should. If you have more than one file, go ahead and open them. Resolved a conflict and save them. Finally, do a get add to stage all the fixed files. If you do a get status, you'll see if all the conflicts have been solved to complete the merge. Just do a git commit on the merch will have been completed. 27. Rebasing: there is another method to merge two branches called Re Basing. The theory behind re basing is that your committee history is cleaner and that it appears more linear toe people looking at the history. It's a little bit like writing a book. Think of merging as putting out the book with the drafts and the different corrections to the chapters versus Re Basing, which looks more like a finished book, with each chapter telling a story in a logical fashion. Remember our previous example with the diverging brunch. Now, instead of merging, we're going to re base the master branch until the new feature branch. So we to get check out in your feature. Get rebased master notice how we're putting the head on new feature and doing the re base operation from there. What happens now is that get goes to the common ancestor of both branches and then applies all the changes in those commits to produce a new line near commit that will call G 88 quote. This committee has the last commit on the new feature branch, but also has the latest master commits as well. Then we can just do the merge with master, which will be what's called a fast for merge because there's no real merging since the new commit already has the existing changes on the master code Base gait. Check out Master, get merged New feature. Okay, enough theory. Let's see this in action. Since you want to put the court based on the state we were when we had three commits on Master, do a git, log one line and check the hash you have for the commit title. Third, commit then toe the following reset using that hash kid reset dark stash heart. We now have the master branch with three commits. Now let's create the new feature branch and do a couple of commits You took out Dash Be new feature Edit the testy Eckstine and at the line. This is like number one in new feature. Save the file, get ad and commit. Then repeat the operation and put This is the number two in new feature Save the file, get out and commit. If you do a get luck, you should see the follow. Now do a get take out master and at the new file test to txt Put some content on it save, Get out and commit. If you do a kid luck, you should see the following Now Go back and get Take out a new feature. Notice how test to txt is not in the file system Now do get re base Master Notice how test to txt appeared now in the near future branch If we do a git log, you'll notice also how it appears as if the work in the branches linear It went back and applied another changing master commit after the third comet even though we know that's not how it happened. We had done the first committing new feature before that. Now we could go ahead and check out master and merge new feature and we would have master with all the changes in the order we have here and really no merges happening. But I want to surprise you with one more feature of re base called interactive freebasing 28. Interactive Rebase: Let's say that you don't want to show the two commits for the new feature branch. When we re basing Toe Master because the two commits are related, you can actually edit the history by doing an interactive free base. Interactive rebased allows you to run a script that essentially allows you to change the order of the commits merch, commits or the lead commits in any way you want. You can even insert new commits if you wanted to. You should still be in the new feature branch, and you shouldn't have merged with master yet. Go ahead and do the following command. Get rid Base Dash I master. You will see a list of the commits with its own new feature that are going to be rebased into master. As you can see, get now shows us commenced. We can apply to each commit. You can pick to use a commit reward to use the commit but change the commit message, add it to stop the script in the middle toe, allow you to do any operations and then commit and squash to use a commit but merged into the one below. You just have to type any of those keywords in front of the committee hash. And once you save the file and exit get will run this file as a script step by step. If you just add it, the script will stop. You can do all the changes to the first want commit and then do get re base. Continue. I don t know the script where you left things off. If you don't want to do anything, delete all the lines that aren't commented out. Those are the ones with the hatch sign and save the file. I also noticed that the order of the commits here is reversed. From what you see on Get Log here, the oldest commit is on the top, so let's combine the two commits in tow one and change the commit message. If you're using the V I editor, remember to type I toe enter edit mode once again if you're using B I for escape and then type colon W Q. Once you do get starts to re base script and present you a non option to enter a commit message, notice how get tells us in what step of the rebate script it's currently at. Change the first commit message and then commented the second message by putting a hush in front of the one you don't want. Then go ahead and save the file with Escape Colon W Q. You should now see get completes the script. And if you do a good log, you should now only see one commit. We can now go ahead and merging to master. Get check out Master Did merge New feature. If you do a kid lug, you should see the following. You can now safely delete the new feature Branch one. File a note. You can apply this committee history editing toe the current branch by using the head pointer. So, for example, let's say I wanted to rename commit messages or squash permits in the master branch for the last three commits. You would do the following command. Give re base dash I head till they're three. The tilde. Sign the notes. The previous three commits 29. Tagging: get offers us a way to create special pointers called tax tagging is useful to mark points in your committee history that are important. Most of the times tax are used to the note versions off your application. So let's say at this point we have completed version 1.2 of our application. You would then issue this command get tag version dash 1.2. From this point on, this committee will be also referenced as version 1.2. To see a list of tax you've created Do get tag. You can also go to the repository at this point by doing get check out version Dash 1.2 notice that is just to browse around since you're in a detached head state. 30. Remote Repositories: most of the times you re working with a remote repository that you and your team are using as a pseudo centralized repository. Although we already know that get is a distributed version control system that doesn't need a central server, that central server can be accustomed. Get server or it could be a commercially available one. Get hope for big buckets I will be using Get help for the section as it is one of the most popular ones on everything you learn here is applicable. Toe any remote server, you'll you? 31. Setting up a Github Account: so head over to get her to come and create an account with them. Typically, you'll need to provide a user name, email and password. Get up is completely free for public repositories, but if you want to keep some off them private, you will need to pay them a monthly fee. 32. Creating SSH Credentials: the first thing we want to do is create an ssh key to be able to push and pull code from your repositories, Think of ssh as a key and lock pair that allows get up to know that you are who you say you are. The first step is to create both the key and the lock files in your local computer. Open your terminal and make sure you are in your home directory and then type the following command. Is this HQ Gen Dusty Arce Dutch See? And then your email. You will be asked where to save to file. Leave the default option by pressing enter. Then it will ask you to create a pass phrase. I recommend you create one as an additional layer of security. You will be asked to want to it again. Your keys are saved on your home directory on a hidden directory called dot ssh. Notice that there are two files I d ever say and I d r say dot p u b. We will need to upload the PDB file to get her. Now go back to get up and find the settings option in the profile menu. You can find that by clicking on your user profile picture on the top. Right. Next, find the ssh and G PG Keys option and click on it on the left list. I'm finally click on the new ssh key, but on the title field, enter label like my R s a key and now co opium paste the contents off. The idea s a dot p u B In the key field, you can get the contents of the file by doing cat dot ssh slash i d on the score arcee dot p u b and then click on at ssh key. 33. Our First Remote Repository: Let's create our first remote repository, go back to your profile, click on repositories and then click on the green new button. You will get a dialogue to create a new repository, just a test remote ripple on the repository name and click on Create Repository. Now we have some options. We can create a new repository manually. We can import an existing repository, but we'll do the easiest option, which is using Git Clone Give Clone creates an initial local gate copy off a remote repository in your computer. Make sure to click on the Ssh button on the Ural section and then copy and paste the text or click on the little great Aiken at the end. Now go back to your terminal. Make sure you are on your home user's directory and tied, get clone and based a your l you copy it Previously get will burn you that you have cloned an empty repository. If you look at the directory now, you'll see you have a test remote report directory. Now change the directory and let's start doing some operations with our new repository 34. Remote Repository Operations: make sure you're in the test remote repo directory and do a get status. You'll see your in the master branch and that nothing has been committed yet. To see the remote repositories associated with this repository, you can do gate remote Dash V. You will see their stew entries. They're both titled Origin, but one is for fetch operations and dollar is for Bush operations. Fact is the action of getting changes from the remote repository to your local repository. Bush is the opposite polish in your changes from your local computer toe, the remote repository. Sometimes you could be in a situation where you pull from one repository and pushed to another, but it's not common. The origin is a default label for a remote repository, but he could potentially work with multiple remote servers, and you would add them or substructure them. This is not coming either. Let's set up the repository with the user's settings. As usual, get config, user name your name and get complete user dot email and your email. Make sure you use the same email used to great your gate of account, create a test txt and put some content on it. get out and commit Now we want to push this code on the remote repository. We can do that by doing get bush origin Master, Notice what it says in the results. A new branch The way to think about this now is that you have a local master branch And you now have a local tracker for the remote origin Master Branch If you do a get status, you will see the following notice. It says that your branch master is up to date with origin Master, this means that both branches are caught up now Try doing a change toe test Txt Save it! Get out and commit If you see the get look, you'll see your second commit But if you do a get status you'll notice It says that your branch is ahead off Origin Master by one Commit As you can see You have advanced one step ahead of the Origin Master Branch If you check your get hub Repository Page, you will see that you still show on Lee one commit So in order for us to catch up we need to do a new get push Get Bush origin Master, You will see your code. Push to the get help repository and you're caught up with origin remote. For the last example, we're going to get acquainted with pulling changes from the remote repository. 35. Git Fetch and Git Pull: when you're working with a team of developers, often times there will be pushing coat toe the remote repository, and you will need to get those changes incorporated to your code base. As you work along your own timeline. The main way we get this changes is by using get, pull and get fetch. So I'm going to simulate that another team member just did. I commit on the remote repository that you don't have available locally yet by using get hops Editing function Get up allows you to do small changes in their website, and although I don't recommend using this in a professional environment, we can get away with it for this test. So open your gate, have repository page and click on Create new file on the top, named the file test to dot txt and enter some content in it, Then scroll to the bottom and enter a commit message. Make sure they commit directly to Master Branch is selected and press on the committee new file button. Once you commit, you will go back to the Ripple stories home page, and you will notice there's a new commit Now go back to your terminal and do a get stacks, you'll notice there's no mention of what just happened in the remote repository. So in order for us to get this latest changes, we will use the git fetch command. So go ahead and type. Get fetch origin. As you can see, Gate is referencing this new commit identified by the 33577 F. But we don't see this locally yet. If you type l s, you will see that the file test to txt. It's not in your file system. If you do a get status, you'll see that kid is telling you that your local master branch is behind one commit from origin master and that we can do a fast forward merge. So now to advance our master head, we just do a get merge, get merge Origin Master. So now we're back to a stable state just like this. The process of pulling the changes and then doing the merge can be accomplished in one step by using get Paul to try it out, go to the get help site and select test to txt and then edit it at a second line and then committed If you check the commits on. Get hope you should see. Then you commit. Now, instead of doing a get fit and then merge will do a get pole, Get pool origin. As you can see, the changes were fetched from the origin server and then merged in one step. 36. Git Remote Branches and Tags: We can also have local and remote branches. This can be pushed or pulled just like we did with a master branch. Let's create a local branch and see how we can push it to the remote repository. Enter the following Get took out. That's bee local branch. Now let's change the test txt file and add a line that says this line created in local branch. No safe get at and commit. Now how do we get this pranks upto a remote repository Just so the following Get push dash you origin local branch What's the EU flag here? It's short for set up stream, which helps us to not have to pass the branch name on subsequent pushes or pulls. Now, if you look in the remote repository, you'll see that the branch appears there. You can switch to that branch by clicking on the branch name or by going toe the branches menu and selecting local branch. Check out test txt and you will see the language just created. Now let's say we finished the work in this branch that switch back to master locally and merge the changes from local branch and deleted. However, this doesn't delete the remote branch in orderto that you will need to do the following get push origin. That's the local branch. Now what happens if someone remotely pushes a new branch of the repository? Let's simulate that by creating a branch on Get up. Go to get help and in your repository homepage. Click on the branch Master Button and into the name remote branch and then click on the blue area that reads Create branch Remote branch. Get hope will create the new branch and switch to it. Madouas. Small change on test txt adding the line this line created in remote branch, then committed on the lower part of the page. Now go to the terminal. We would normally do a git Fetch origin master to get the remote changes, but this time we have a new branch. If we knew the name we could to get fetch origin Remote branch. But more often you will want to get all new branches so you use the following command. Give fetch dust, ash. All that would get all the changes in any branches and bulls new branches as well as you can see here. It tells us there's a new branch. If you now do a check out to the new brand, you will see that test. TXT has a change with it. Go back to your master branch. Now let's say somebody deleted that branch in the remote repository doing get fetch Origin that stash all want the leader branch locally, so we need another command for that. So go to get help, click on branches and press the little trash can icon in the end off the remote branch line . Now, if you go to your terminal, do the following command. Get fetch. Dash, dash, All dash, dash, prune. As you can see here, the remote branch has been deleted. 37. Conclusion: This is the end of our get journey. Now the only thing you need to do is play with kids and learn some of the remaining tricks it has on the rates hood. Believe me, I still learn a new feature every other week. You now have a very powerful tool in your developer tool belt. Congratulations on making it all the way to the end. If you want to continue your development career, make sure to check out my other courses and sign up for my newsletter at www dot from zero what I am.