Git is a source code repository. It allows multiple developers working on a project to manage their changes to a single codebase without stepping all over each others work. Changes are committed to the repository in a way that there is a log of each change, which can be undone if needed. There is a LOT more to it than that, but at its core that’s what it is.
Git was originally developed by Linus Torvals (who created Linux) to manage the Linux source code, but it is not directly related/dependent on Linux. Many, many developers use it for a wide variety of projects.
It a versionning tool (mostly for code).
When you’re working on a project, you want to be able to:
– go back at a previous point in time
– have multiple people working on the same document then merging their work together
– working on several version at the same time
– save document both on you computer to work on and on a company server for everyone to use
You could just save your document in a different file (Document_1, Document_1bis, Document_copy) and have them on your computer, on a company server and manually merge the work of multiple people, but it’s a nightmare to manage, especially for complex projects with many people working on it.
Instead git allows to do all of the above.
– You can save small changes in *commits*. git does not save the all file, just the changes.
– You can work on different *branches* aka versions of your document
– You can *merge* differents version to merge the work of different people together
– You can *pull* and *push* code between your computer and a company server aka *repository* (or a public one like github.com)
TL;DR: it’s a tool to store and manage versions of files and make it much easier to work with a lot of people.
Imagine I have ten people working on a project. Each person may be working on different things, they all could be working on the same thing, or anywhere in between.
For a software project, especially a large one, we need a tool to coordinate and log these changes. Otherwise, you could have a situation in which one person accidentally makes changes that mess up another person’s, a bad change is made that is difficult to weed out, etc.
Enter Git, a tool that allows users to retain their own copy of the entire code and sync it with the master copy. Because Git keeps track of these copies and when they are merged with a master copy, changes are easy to add, remove, and keep track of. This allows for large-scale coordination on software projects.
Okay I’m gonna try attempt this in the spirit of ELI5…
GIT:
You have a folder that you like to put things in (documents, code, etc).
Your friends can get their own copies of this folder, and they too can make changes to things in the folder.
Sometimes you want to do weird shit with the folder, like only allow some friends to make changes, or only allow changes into the shared folder if you’ve seen them and think they’re cool changes. You can tell the folder to do that and if it’s feeling cooperative, it will.
Sometimes you want to put unfinished products in the folder but don’t want anyone else to see think they’re done until you say so. You can do that too.
You can ask the folder to recite the history of everyone who has ever put anything in it, what they put in it, and when, and the folder knows.
Basically any weird thing you would ever want to do with a shared folder you can probably do, so long as you have lots of patience with learning obscure ways to lull the folder into playing nicely.
Sometimes you access your folder from a computer running Linux. Sometimes from OSX. Sometimes, if you’re willing to endure more pain, from Windows.
Have you ever worked on a large complicated project? Especially with multiple people involved? After a while the project folder tends to look like this:
Financial Report.doc
Financial Report (1).doc
Financial Report (2).doc
Financial Report (3).doc
Financial Report (2)a.doc
Financial Report – Latest.doc
Financial Report – With Bobs changes.doc
Financial Report – Feedback.doc
Financial Report – Latest (1).doc
Financial Report (Final).doc
Financial Report (Revised).doc
Financial Report (Final) (1).doc
After a while, you might lose any sense of how these various versions of the document are related and what they’re all for. You might struggle to answer basic important questions like:
– Which is the latest version?
– Where are the unfinished changes was making?
– Who changed what when?
– Might there be some emails where the people who made changes made important comments about their changes?
– Which versions of the document are “works-in-progress” and which are considered “shipped products”?
A program that helps you manage these concerns is called a “version control system” (VCS for short). Basically a VCS is a program for organizing backup copies of old versions, branching (Bob circulated his changes for review but isn’t ready to put them into the main document), merging (okay Bob’s changes are ready to go in the main version now, but other people have changed the main version in the meantime), and so on.
“Git” is a version control system that is mainly used for computer code. Git was created in 2005 by the creator of Linux (Linus Torvalds), and within a few years it quickly displaced existing version control systems (CVS, Subversion) and other Git-inspired systems (Mercurial, Fossil) never gained the same traction.
Unlike many earlier systems, Git is a “Decentralized” version control, meaning each person has a complete copy of the project’s entire history. (This sounds wasteful, but computer code files are very small compared to modern hard drives and Internet connections, and Git has internal tricks like compression, and only saving the parts that changed.)
Many people use a website called Github to store their Git projects. Github also has features like an issue tracker. (Basically the issue tracker lets users and developers file tickets for specific bugs, features, etc.) But you don’t have to use Github to use Git for your own projects. Github is just a convenient place for finding other people’s projects that they want to be public.
In the spirit of the sub:
Imagine you’re building a Lego castle. You have an image of what you want your castle to look like in your head and each day you put a few pieces in their place and make progress towards your castle.
Then a friend comes over, and while you’re in the bathroom, puts pieces where they think they should go. This is against what you wanted, so you’re forced to take those pieces off and place them where you want. Now imagine 20 of your friends come over and want to help build the castle. You have people grabbing the same pieces, or making changes to your castle without making sure that it fits into your vision for what the castle should be.
Application development can be similar to building a Lego castle. Git provides a system for reviewing changes, working on the same code simultaneously, and many other benefits to make sure a team of developers is working towards the same goal.
Git is not a nasty name you call someone. It’s a version control system. This allows you to save previous copies of your project as you continue to add to it. You can go back to a previous version if you need to. You can also introduce new ideas to your project, and not add them until you’re absolutely sure that you want to add them. Github is a website. It includes all of these but it saves them to a folder online. If your computer goes down, you can download your projects from your account on Github. I hope this helps.
Latest Answers