Git is a distributed version control system that is designed to scale from small projects with a single developer to large projects with thousands of developers worldwide. This video builds a foundation for subsequent learning activities that develop essential skills with Git. [MUSIC] No one, not even the best software developers write perfect code the first time. There are many reasons code must be modified. Changing requirements, compatibility with new platforms, and market competition to name a few. But perhaps the simplest reason is that we're human, we all make mistakes. Unfortunately, keeping track of changes to even a single file is challenging. Maybe you can relate to this geek in pop cartoon on the slide. The essence of a version control system is managing this complexity so you don't have to. Modern version control systems can handle thousands of people working on projects with hundreds of thousands of files. Moreover, the benefit of using a version control system quickly outstrips its cost not only to large teams, but also to individuals working alone. Historically, there are two types of version control systems, centralized and distributed. Grossly contrasting these approaches, a centralized version control system has, well, a central server that stores the complete history of the project. When someone makes a change, that change is immediately visible to everyone else. In contrast, a distributed version control system stores the entire history of the project locally and there's a two-step process to share changes with others. First, you commit the change which records it locally. Second, you share that change or a whole bunch of changes with others working on the project. There are benefits to both approaches, but the trend over the past two decades has been an overwhelming adoption of distributed version control systems specifically Git. From the initial question, do you write perfect code the first time and the prior description? It's not difficult to understand why distributed version control systems are so popular. In short, they make it easier to break a big change into a series of smaller ones and to share that set of changes when they work correctly in the context of the entire project. Linus Torvalds, the creator of the Linux Kernel, started the development of Git in April 2005. Git was designed for the needs of Linux kernel development. Specifically supporting a distributed workflow and merging short-lived branches. That is combining different versions of files that were modified independently by developers. Git has proved wildly successful, being used by 90% of respondents and stack overflows 2021 developer survey. Although Git has a reputation for a steep learning curve, its command line interface has evolved considerably over the years. Resolving many issues known to confuse new users. Like other distributed version control systems, Git records metadata and files in a repository which is stored in a hidden directory named .git. Anyone working on the project has a complete copy of the repository which improves the performance of many operations, such as viewing the history of a particular file. Files are modified in the working directory, and a commit records a version of one or more files in the repository. Unlike many other version control systems, Git requires users to explicitly indicate which changes to file should be part of the next commit through its staging area or index. Although a Git repository is self-contained, collaboration is simplified by a remote, which is a copy of the repository that others can access. A remote essentially facilitates sharing changes, instead of resorting to, say, emailing patches to anyone who needs them. In many cases, the remote repository acts like a centralized version control system, maintaining the authoritative history of the project but unaffected by experiments in local repositories. The basic workflow when using Git is as follows. First, a user creates a repository often by copying an existing one. Services like GitHub provide internet hosting for repositories to facilitate collaboration. These services are widely used for open-source projects with a global community of developers. Next, the user specifies a branch or independent line of development for their work. One benefit of using branches is ensuring the main line of development is always deployable. Furthermore, Git's branches are lightweight, perfect for breaking large complex changes into a series of small changes that are simpler. After changing one or more files, the user adds them to the staging area. This step is helpful for large changes because the staging area allows the user, probably a software developer to control what is committed to the repository. For example, maybe the developer corrected some documentation before re-factoring code. The staging area makes it easy to commit the revised documentation before the re-factored code, keeping logical changes separate. Next, the user commits the changes. The commit creates a permanent record of the modified files and allows them to be shared with others. Finally, the user shares the changes in the local repository. If others have been working in parallel on the same branch, the user must fetch and merge their changes before sharing the changes made in the local repository. This requirement avoids overriding someone else's hard work. That is, the user must intentionally decide to discard other's changes, if it's appropriate to do so. Although normally Git reconciles all the various changes without any human intervention. [MUSIC]
