Skip to content

Introduction-to-git.md

Latest commit

 

History

History
103 lines (61 loc) · 6.47 KB

Introduction-to-git.md

File metadata and controls

103 lines (61 loc) · 6.47 KB
Raw

Introduction to Git

Now that we understand the importance of source control, let’s get into Git.

Git is a source control management system (SCM), and it has become a very widely used tool to manage source code. Git has many features, but some of the key ones are:

  • Pull working files from a repository
  • Push the files back to the repository after you have made changes
  • Create a local repository from within which the working files can be tracked, staged, and pushed

DIAGRAM

What is a Repository?

We've used this term a few times, let's define it before we move on.

A repository is simply a container for files and data assets. Strictly speaking a folder on your hard disk is a repository, but when we use this term we typically mean a container with a specific purpose, such as the resources for a particular project.

From a software engineering POV, a repository refers to a location which contains all of the code and assets for a particular application. This type of repository offers functionality to facilitate this purpose, such as access control, automation and API access, remote access, and many others.

A common platform which allows you to make repositories such as this is called GitHub, but many others exist such as BitBucket, GitLab, and Cloud Service Provider (CSP) specific options. If you do not wish to store your code with a 3rd party, you may also host your own repositories on an on-premise server.

How to Start Using Git

You first need to start with installing Git.

Many (Linux) machines will have this already installed, but you can check by typing git version or git --version in your Terminal.

Windows includes a couple of CLI interfaces, the oldest one is the Command Prompt or CMD, which actually pre-dates Windows. The more modern CLI in Windows is called PowerShell. Some functionality is only available in one CLI or the other, but 3rd party tools can often be used from either. In Windows 10 you can open either one individually, but in Windows 11 they're both accessed from within a separate app called Terminal

If you do not have Git installed review the following guide for instructions.

installing-git.md

Git: A Visual Overview

Now that we’ve learned about how Git helps us track changes, let’s break down some of the key components that make up the Git workflow:

  1. Working Directory (Local Environment): This is where you make changes to your code. It refers to the files and folders you’re currently working on.

  2. Staging Area (Index): Before committing changes, you add them to the staging area. This is like preparing a draft of changes you’re about to finalize. It's a buffer area between the working directory and the local repository.

  3. Local Repository: This is your version of the project stored locally on your machine. After you finalize the changes by committing, they are saved here.

  4. Remote Repository (GitHub/Server): This is the repository on GitHub or a remote server. When you "push" your local changes, they are uploaded to the remote repository where others can see or collaborate.(We will discuss this later!)

whiteboard

The above image is a visual way to think about Git. All of the components above connect together to build a Git workflow. Also illustrated are some important commands to keep in mind to allow our changes to be moved from one stage to another.

Some of the key stages in more detail:

Working Directory

The working directory is where the magic happens; This is the local environment on your computer, where you actually write and edit your code using your preferred IDE. This is where you make all the changes to your files and folders you are currently working on, but these changes are not yet tracked by Git. You make all of your changes before finalizing them.

Imagine you're working on a file called hello-world.txt in the working directory. You can edit it, save it, or even delete it without Git or your GitHub repository knowing about those changes.
This is the behaviour we want, because developers may make and undo dozens or hundreds of changes per day as they add and test new functionality. So, we don't want every single change to the file(s) tracked.

Staging Area

It is likely that not all files in the project have been changed, so this is where the staging area comes in. The files in your project can be tracked and the ones which have been changed are staged with git add [filename] (or more commonly git add . to track everything).

When all of your changes are ready, you can then commit everything in the staging area at once, rather than one file at a time.

Once you've completed all of your updates, you are ready to commit the changed files, which is effectively pushing a package containing all of the updates back to the relevant branch.

In addition to the changes, the commit also includes meta-data, some of which is captured automatically, such as a timestamp, and the user's identity. You're also prompted to include a message with your commit which should be a brief summary of what is included.

Branching

A branch is a version of a codebase which is taken from the primary branch at a point in time, and allows a developer to work on new features or bugs, experiment, and collaborate safely, without causing and problems in the production version of the code.

Some common branches include:

Branch Description
main/master The primary, stable version of the code
feature/abc A branch for working upon feature 'abc'
bug/xyz A branch for working upon bug 'xyz'
dev The branch for ongoing development

Older projects may still use the name master for the primary branch, but typically it is now called main.

Some of the common Git CLI commands are shown below, you may also create branches through the web-GUI if using a repository like GitHub.

git branch            # List branches
git branch new-branch # Create a new branch
git checkout new-branch  # Switch to a branch
git merge new-branch     # Merge changes into current branch
git branch -d new-branch # Delete a branch

A typical workflow involves:

  1. Start on main branch
  2. Create a new feature or bug branch
  3. Ensure you are working on the new branch
  4. Make changes and commit to feature branch
  5. Once your feature is complete, and successfully tested, merge the changes from the feature branch back to the main.

Click here for a lab on branching from the CLI