Last updated: December 12, 2018
Git is an open source version control system. It provides a distributed approach to version control, as opposed to the centralized paradigm of most other version control systems.
With typical version control systems, the code base for an entire project is stored in a centralized repository.
Files are “checked out” by developers, which involves copying those files locally and then locking the originals from further editing until the developer who checked them out uploads their changes and unlocks them.
In contrast to that, with a distributed version control system, all nodes have a complete copy of both the entire code and every previous commit to the code base.
The biggest advantage of a distributed version control system is agility.
Many people can work on the project, and even on the same file, without locking each other out.
Secondarily to creating a better workflow, a distributed system is less fragile because there is no single source of failure — the entire project can be reconstructed from any of the repos maintained by an entire development team.
The merge/pull feature provides detailed views into what has changed in each file and provides tools for ensuring that code is merged properly.
Additionally, the typical development team (or Open Source project) using git usually alters their organization and workflow a bit to ensure there are no such problems.
Git is a software application for doing distributed version control. GitHub is a website and software service that provides a centralized Git server and additional development tools like an issue tracker, a project wiki and pull requests.
Yes. Git is a standalone piece of software that can be used apart from GitHub.
Even in a decentralized paradigm, some copy of the code has to be recognized as the authoritative copy.
Most Git users employ a single copy of the repo which acts as a central, or origin, repo.
The canonical repo is centralized from a business and process standpoint but is on equal technical footing. No one repo is privileged over other repos.
The typical workflow for developing with git and GitHub is fork, branch, merge, pull (request).
When the developer begins on another feature, the cycle repeats again with *fork*. It is important for developers to get a fresh copy of the code base at the beginning of each development cycle.
You will have to check the specific rules and requirements with your hosting provider. However, in most cases there is nothing stopping you from doing this.
Git provides a quick (one line of typing) way to copy an entire code base from one computer to another, even a remote server. This makes git an excellent option for fast and easy deployment.
No, but it helps.
Git is primarily a command-line tool: you navigate to the directory of your Git repository and use the command like to manage the git repository found in that directory. There is a GUI-based desktop application for both Windows and Man available.
However, the desktop application does not provide as much advanced control of the Git utility as the command-line does.
Further, the simple tasks that the GUI-based application can provide for you are easy enough for almost anyone to learn. This makes the GUI app less needed.
Yes. If you are tracking your git repo on GitHub, they provide a number of in-browser tools, including file editing.
The .gitignore file is a file in a Git repo which allows the developers to specify certain files or types of files to exclude from the repo.
Files mentioned in the .gitignore file can be included in the same directory, but they are not tracked, and so they do not get copied to remote servers when repos are merged, nor can earlier versions of those files be found or recovered.