Intro to Git Hub
GitHub is a Web-based distributed version control hosting service for software development and code sharing.
GitHub offers free public repositories and collaborations for open-source software creation and charges small and large businesses for private repositories and collaboration. From a social perspective, GitHub allows users to change, adapt and improve software — each project is called a “fork” — in its public repositories. Users can work together in teams or alone. Public users create profiles which display repositories and public activity and help programmers find projects.
What is version control system and other terms regarding to it
Different people have different opinions:
- Some says Git Hub is a Version Control System,
- Some says Git Hub is a Revision Control System,
- Some says Git hub is a Source Code Management System,
- Some says Git Hub is a Source Control System,
- Some says both terms Version Control System and Revision Control System are similar &
- Some says they all are almost symmetric, so doesn’t matter what you call it.
Git Hub is a Distributed Version Control System.
Now then what are all the others?
So, let get a glimpse of every term mentioned above:
- Revision control. Deals with revisions (document/artifact reviews and subsequent versions of document/artifact) or numbers (as an abstraction of revision concept).
- Source control. Deals with text (source) files, not binary. This difference plays a great role as long as it is much more easier to perform comparison and get difference between text files. There is a whole range of basic tools related to source control: diff, diff3, patch, etc. This set of tools can be extended to form source control solution. Example of such solution is RCS.
- Source code management. Deals with more complex operations over the source code: storing it in a repository with the possibility of creating separate branches. It is also assumed that branches can be merged. Another part of source code management is tagging. One problem with source code management is that it has abbreviation SCM. This abbreviation is used to describe more broad set of activities – Software Configuration Management. There’s a lot of confusion because source code management is a subset of software configuration management which also deals with such activities as build management, deployment management, continuous integration, dependencies management, release management, etc.
- Version control. It is used as substitution for such term as source code management in order to avoid ambiguity. It incorporates both concepts of revision control and source control making it to describe almost the same concept. Currently, both terms revision control, source control are substituted with version control as more appropriate taking into account the wide range of tools (CVS, SVN, Git, Mercurial, ClearCase, Perforce, VSS, etc) which solve both tasks of revision control and source control simultaneously.
Picture to illustrate more clearly distinction between all of these concepts:
What is then Distributed mean in it?
Let’s break-down this topic in steps,
- Version Control If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
- Local Version Control Systems
Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
- Centralized Version Control Systems
The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
- Distributed Version Control Systems
This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data.
This is a post from Codecademy Community by Dipesh Bhardwaj
Hope you liked it!