Git Complete: git init, git clone, git (add, commit, pull, push)

So far so good! As you would expect with any course, you will go over the basics before you dive into the more complex material. However, for readers who know very little about git overall, I wanted to cover some of the basics that we have been reviewing in the course.

Git is a decentralized and distributed version control system, meaning that most operations are local and a central server is not required. While thats true, of course most companies do use a centralized server to serve as the main repository for their team.

Lets go over one of the first aspects of any project: Git Init and Git Clone

The git init command creates a new Git repository. This can be used to convert a project into a git repository or create a brand new one. When using this command inside of your working directory that you name testProject, you will see something like this:

So that means that once I run the git init command, I should be able to see this subdirectory when running the ls command right? Not exactly. With Unix, any file or folder that begins with dot notation is treated as hidden. To reveal, simply run the command below to get a glimpse of the .git subdirectory that the git init command gives you. This subdirectory contains all of the metadata needed for your new repository.

So what is the difference between git init and git clone and when should I use them? Good question and they can be easily confused. If you have untracked code or a brand new project, git init is great to get started. However, let’s say you roll onto a client or join a company that already has a repository under git with multiple contributors. The way to get started is to use the git clone command to clone the existing repository into your newly created directory. Let’s break down what is actually happening when you running the git clone command and its relationship to git init.

• git init is called, which creates the local repository
• git remote add, which adds the URL to the newly generated repository
• git fetch, which grabs all of the branches associated with that repository
• git checkout, which checks out, by default, to the master branch

Now lets move onto some other basic git commands. Once I have created a new file, Git will show it as an untracked file which means that we need to stage it for commit. The git add command updates the index (where you place files you want to commit to the git repository) using the current content found in the working directory to stage to be committed. The two you will commonly see is:

The difference between the two is that git add <your file name> only stages that individual file, while git add . stages all of the files to be committed. Once you have staged your commit, you can run a git status command to see the changes to be committed.

Now that we have our staged file, we need to commit our change to the repository and designate a log message describing what we are committing. Typically you will see this done in two ways:

The last example will prompt a new view in the terminal asking for you to enter your commit message. Once you are done, you can press the esc key and quit out of the window using :wq (write and quit). Once you committed your code, git will give you what changed and the commit information.

Lastly, let’s cover the git push and git pull commands. Often times when you have multiple contributors, it’s important to make a habit of pulling from origin. What does that mean? If you recall earlier we discussed cloning a repository and git fetches all of the branches for us, this would be all of the remote branches that we have access now to contribute to. The git pull command fetches and downloads content from the remote repository specified to what branch you are on and updates your local repository to match that content. It first runs the git fetch command that pulls the content from the origin branch you specify: git pull origin master. Then, git merge is executed to merge the remote content refs and heads into a new local merge commit.

So now that we have our commit staged, all that is left to do is perform a git push command to update the remote repository with the content of your local repository specified to the branch that we are currently checked out on. Be sure to exercise caution when performing a git push as you could potentially overwrite changes.

If anyone has any questions or comments, please add something below or feel free to reach out to me personally. For more content, please check out this excellent guide that served as a source for material shared on this post. As I continue in the course, I will be posting more content.