Connect to the Repository

Cloning a repository#

Git’s advantage as a distributed source control system is its ability to clone a copy of the repository locally. Having a local copy of the repository gives you complete autonomy.

Use the git clone command to clone the repository you created. The clone command requires the <GitHub clone URL>.

Clone the repository by following these steps:

1. Click Clone or Download, then click the copy or clipboard button.

2. Use the git clone command in the terminal, replace the <Github clone URL> with the repository’s URL.

3. Change into the repository’s directory using the command below:

5. List all the contents of the directory and show hidden files using the command below for the bash shell:

You can use the following command for listing the contents in PowerShell:

Notice the .git directory. The .git folder makes it a Git repository. It was added when you created the repository using GitHub’s web interface.

Tracking changes#

Git does not automatically commit your changes. You are responsible for staging and committing the changes. Git is aware of the changes, but you have to tell it which changes it should care about.

When you create new files, they start in the working area. Git does not track changes to these files, but it is aware they were created. The working area is also referred to as “untracked.”

Let’s dive into how to track changes step by step.

1. Create a new file within the ansible repository by using the following command:

2. View untracked changes in the working area using the command:

The git status command’s output informs you that there is one untracked file, ansible.sh. Review the Line-5 of the output below:

3. Add an ad-hoc Ansible command to ansible.sh:

4. View git changes using the command:

The git status command returns the same output as before. That’s what untracked means. Git is simply aware that the file exists but does not keep any information on that file’s changes.

Staging changes in Git#

To keep track of the changes to a file, you have to move it from the working area to the staging area.

You can stage the changes to the ansible.sh file using the git add command. Explore the steps below,

1. Track changes to ansible.sh:

2. View git changes:

The output displays that the file ansible.sh is now being tracked and is in the staging area.

3. Modify ansible.sh, add another ad-hoc command:

4. View git changes:

The output now shows a tracked change and an untracked change. Git has the first change in the staging area and the second change, which is untracked, in the working area.

5. Show the difference between changes. Use the git diff command:

By using the git diff command you can see the differences in the working area and staging area versions.

6. Add the second changes to the staging:

You can use the git add command to stage the changes.

Committing changes#

The power of source control is having a rich history to audit and rollback to. Commits make up that rich history.

Before you can audit or roll back to a change, it needs to be committed. When you commit a change, it moves from the staging area into the repository. Commit requires a commit message. You can make the history rich and informative through meaningful, thoughtful, and concise commit messages.

Use the git commit command to commit the changes to the local repository.

1. Commit the staged change to the local repository. Use -m to leave a commit message.

You will come across the following output:

Tracking changes isn’t enough. You also need to know who made the changes. Git’s configuration is used to provide the user name and email associated with the person who committed to the repository.

2. Add user.email to the git config, replace <YourEmail> with your email.

3. Add user.name to the git config, replace <YourName> with your name.

4. Add the ansible.sh to the staging area again. Use the git add command to stage the changes.

5. Commit the changes.

Your change has been committed to the local repository with the commit message you provided.

The output of the command will look like the one below:

Visualize the Git workflow below.

Pushing changes#

The final step is to push your committed changes back to the centralized repository on GitHub. Pushing your changes makes them available for others to retrieve and also serves as a backup.

1. Push local commits.

2. When prompted, enter your Github username and password.

Personal Access Token
If you have two-factor authentication enabled, you’ll have to use a personal access token(PAT) instead of a username and password. You will have to use PAT in the future as the password-based authentication will go obsolete. Learn more here.

3. Get the status of the repository.

The commits you made to your local repository are now available on GitHub.

Review the output of the git status command below:

Practice the commands in the terminal.

We have provided a summarized view of the commands below:

In this lesson, we introduced the essential git commands. Review the commands below:

• clone: To clone the remote GitHub repository.
• status: To get the current status of the repository.
• add: To stage the changes in the repository.
• diff: To get the difference between the staging area and working area versions.
• commit: To commit the staged changes to the local repository.
• push: To push the committed changes to the GitHub repository.