 Welcome to this GitLab training video. Today's lesson, getting started with Git. Today we're going to cover the basics of Git, the open source version control system that GitLab is based on. First, Git is distributed. Unlike legacy centralized version control systems, Git does not require a connection to a central server in order for you to work on your project. Git is also adaptive. The modern development knowledge workers environment is fast paced. The ability to keep up with competition, regulation, or innovation is fast becoming the way modern enterprises can differentiate themselves. The basic model and primitives that Git contains enables teams to innovate quickly, all while following the workflow process that works best for them. Git is the choice for modern teams because of its fast, reliable architecture. All changes are tracked and can be easily audited, corrected, or reverted. Collaboration is central to the core of Git and it is the way that the most effective knowledge workers manage their work. Git, by its very design, is an extremely flexible platform that provides basic concepts that your team can use as they see fit. Git allows developers to use command line tools to interact with their repository while allowing others to contribute using tools that place a graphical interface on top of the power of Git. In a previous video, we introduced the basic concepts of version control. Next, we're going to dig deeper into how Git implements those concepts and enables teams to have distributed version control over all collaborators. First, let's look at some terms for working with Git. A branch is any independent line of development. New commits are recorded in the history for the current branch, which results in taking the source from someone's repository, the place where the history of the work is stored at a certain point in time and applying your own changes to it. Typically, the main branch for a project is a special branch called master that may be protected against changes by anyone that is not authorized to do so. A tag lets you name or version a specific point in time on a branch, even on master. This allows you to create a point in time like v1.0 and mark the code at that point. You can then check out or revert to that point in time if you ever need to. The concept of checking out your code also exists within Git. It's where you get a local copy of the code at the branch you specify so that you can start making your desired changes. As you make changes to a branch, you'll commit those changes to record the record of those changes into the repository. To send them to a remote repository, you'll push those commits upstream. We'll learn more about this coming up. The workspace is a directory on your computer where you've chosen to store the repository and the code that goes along with it. Untracked files are any new files in that workspace that you have not yet added to get to tell Git to track the changes on those files. Some files are intentionally left untracked, such as those that might contain passwords or other sensitive information. We can even tell Git to explicitly ignore those types of files. The working area refers to any files that we have changed since our last commit, but haven't yet gotten ready to commit. When we're ready to commit those files, we move them into the staging area. From there, we can commit them with a message describing our changes to the team. Once we've committed them, those changes in the message are in the local repository, the local copy of the entire Git repository that lives inside our workspace. When we push them to an upstream repository, we call that the remote repository or remote repo. This is a hosted repository on our shared server using server-side software, such as GitLab. Next, let's put it all together by looking at the basic Git workflow. While this diagram may seem complex at first, we're going to go over each part. First, we need to have a Git repository. Oftentimes, this is acquired by cloning an existing repository from the remote to our local computer. However, if we're starting a brand new project, the command Git and Net allows us to create an entire repository locally without the need for connection to our remote to get started. From there, we simply make the changes we want, add, delete or change files at will. We can reorganize the entire project or just make one small spelling change. Once we're satisfied with the changes, the command Git commit allows us to mark the project in its current state as a kind of snapshot in time. Then, if we want to collaborate on these changes with our team, we can send them to the remote repository by saying Git push. To bring other changes that team members have made to the remote repository down to our local working copy, we can say Git fetch and that will bring them into our local repository, and Git checkout will replace what's in our working directory with a branch we just fetched. But don't worry, because Git is constantly keeping track of our commits and changes, it will always be possible for us to get back to where we were at any point in time. And finally, we can merge our changes with others or with the main or master branch of the project with Git merge. Up next, we're going to talk about how this workflow can scale to be used across entire teams or entire organizations.