Quick Start, Part 2: Configuration, Clone, and Git Basic Workflow

Jason Taylor
A free video tutorial from Jason Taylor
Lead Software Engineer, Dev Trainer (19 courses,50k reviews)
4.4 instructor rating • 19 courses • 464,426 students

Lecture description

Part two of the "Quick Start" section -- configuration, cloning from GitHub and the entire Git workflow (add, commit, push and pull).

Learn more from the full course

Git Complete: The definitive, step-by-step guide to Git

Go from zero to hero with Git source control step-by-step with easy to understand examples. Become the next Git expert!

05:46:03 of on-demand video • Updated September 2018

  • Learn the key concepts of the Git source control system
  • Step through the entire Git workflow
  • Compare the different states in Git and compare between branches and commits
  • Manage files with Git (move, rename, delete) and update files managed outside Git
  • Create and fork repositories on GitHub and push changes back after working after working on them locally
  • Create branches and resolve merge conflicts like a pro
English On Windows, if you installed Git for Windows, and you are using Git Bash, then you know Git is installed. On the Mac, it is less obvious; so we need to ask Git for the version, in order to confirm that Git is available: "git version". If Git responds with a version number, then Git is installed. Otherwise, you may need to install Git before proceeding. Git requires two bits of information before we can do very much; that is the name and email address. If we don't provide that information, Git will attempt to automatically figure it out. However, I have found this process to be rather unreliable. So let's just take care of it right now: "git config --global user.name", space, and, in double quotes, just put your name. And then next we'll do a similar command for the email address: "git config --global user.email", space, and, in double quotes, put your email address. Press enter, and now, let's confirm: "git config --global --list". Git should list back your name and email address you entered above. Now that our local system is all ready to go, let's return to our browser where we left off. Which should be in our new repository's main page. Now, I want to get a copy of this repository onto my local system. The process to do that is called cloning a repository. So, locate the clone options at the bottom of the right hand side of the page. Make sure "HTTPS" is selected, and then click the copy button, to copy the HTTPS URL for the repository to your system's clipboard. If, for some reason, that button isn't available or isn't working, just select the HTTPS URL, and then copy it into your clipboard manually. Now that it's done, return back to the terminal and type "git clone", space, and now just paste in your GitHub URL. Double check that line, and then press enter. Git will now go out to GitHub and make a full copy of our repository on GitHub to our local system. Doing so, Git will automatically create a directory named after our repository; which we can confirm by typing "ls", then press enter, which lists out the contents of our current directory. Now, let's go into our local repository's directory: "cd github-demo/". Now if we "ls", we can see we have our readme file that was created when we initialized our repository on GitHub. Now, if I ask Git about the state of the repository with "git status", "git status" tells us that I'm on the master branch. The master branch is the default branch, by convention, for a Git repository. The "git status" command also tells us master is "up-to-date with 'origin/master'.", which refers to the master branch on the GitHub version of the repository; the "git clone" command automatically set up a relationship back to the repository on GitHub, and named that reference "origin". Finally, Git tells us the working directory is clean; the working directory is where we do all the work, and that Git monitors for changes. We use the "git status" command to see if there are any changes between the working directory, the staging area, our local repository, and our remote repository. Now that we have our repository on our local system, let's add a new file. For that, I'm going to use the bash commands to create a simple text file. So type "echo"; space; and in, double quotes, the contents of our file, "Test Git Quick start demo"; and then two greater than signs, that pipes the contents of the "echo" command into a "start.txt" file; after that, press enter. Now, we can see the file in our working directory; "ls". Also, we can use the "cat" command to display the contents of that file: "cat start.txt", press enter. Now, let's see what Git thinks about this file: "git status", press enter. Now, when we do that, Git says that we have an untracked file. An untracked file is just a file in our working directory that hasn't been added to Git yet. Our change, that is our new file, is in our working directory; we haven't specifically told Git about it yet, so let's take care of that now with Git's "add" command: "git add", space, and then the name of the file "start.txt", press enter. Now if we do a "git status", Git tells us there is a new file in the staging area, which Git describes as "Changes to be committed:". So, now that our file is in the staging area awaiting the commit. We haven't committed anything yet; we can still back out the change from the staging area, and not impact Git's history in any way. The staging area is designed to allow you to build up several related changes, so they can be committed as a single, atomic, unit. Now, let's move forward by committing the new file into the repository: "git commit -m", space, and in double quotes a commit message "Adding start text file", then press enter. Great, now if I do a "git status", Git tells us that we're back in a clean working directory state, and that our master branch is ahead of "origin/master" by one commit. So, now the new file has been moved from the staging area into the local repository. Since there are no other pending changes, once the commit happens, Git marks the working directory as clean. After the commit, I mentioned the fact that our new file is now on the local repository. The commit is still a local command, which means that our file is not yet on GitHub. So, to prove this, let's return to our browser. We should still be on our repository main page, so refresh or reload your browser, to refresh the contents of that page. What you should notice is that we still have just the README file on GitHub. So, there is one last step we need to do, and that is a push. So return to the terminal, and type "git push origin master". This version of the "git push" command specifies the remote name, which is origin which was set up for us automatically when we cloned the repository from GitHub; and, the name of the name of the branch to push, which is "master", since it is the only branch we have; now press enter. Since you are making changes on your repository on GitHub, the "git push" command will prompt you for your GitHub username and password. Once the push command returns, then we can check the results. If we did everything correctly, our new file should be on the GitHub copy of our repository. Let's verify that by returning to our browser; now, refresh the page again. Now we should see our "start.txt" file listed. If I click on the filename, I can see the contents of that file as well.