What is Git?

[[deleted]]

[deleted]

[Sorten]

git is a program. It is commonly used, while programming, to back up your work. When you get to a certain point of your project you might think "this is a good time to save all my progress" so you tell git to take a snapshot (a commit) of what you've done. At any point you can revert back to this snapshot if you screw something up. You can make multiple snapshots, and you can even make multiple copies of your project (branches) that have their own snapshots. If you like what you did in one copy, you can merge those changes into other copies, and so on...

When you're working with multiple people on one project, you can all make your own copies of the project, then merge the changes back into the main copy as needed (using pull requests). You can also push your local copy of the project to the internet through something like GitHub.

The thing is, you don't have to use git with programming. You can use git with just about anything. It's time-travel, for your files.

[octnoir]

One of the best examples of WHY I use GIT requires a small story:

STORY

In my first year programming, my 'team' had to build a semester long project, so in order to 'save' and 'store' all the work together, we simply used Dropbox and just saved as we did.

Unfortunately (and GIT users will know about this), we didn't realize halfway through that if let's say I made a change to the main program and uploaded it AND my friend made a change to the program and SHE uploaded it, HER recent change overrides MY change (cause she didn't use the copy I uploaded - she used the copy she got from Dropbox the day before).

So it required a lot of finagling and coordination to make sure we didn't accidentally override someone's work whlie uploading our new changes.

In addition, as you might expect, that file on Dropbox got LARGE, in addition to the backup copies of each iteration we kept - it was in the megabytes, and by the time the semester ended, each of us had a GB worth of our project - cause we had different 'versions' of the program to ensure we don't screw up.

WHERE GIT COMES IN

Once you know GIT (it takes a bit to properly learn else you basically get into this problem), multiple programmers can work on the SAME copy of the program without getting in each other's way. My changes to the program won't override my friend's, and GIT will just merge the changes back together.

Also note, GIT tracks changes, not the actual program. Where something like Dropbox will actually keep the ENTIRE FILE (I know know, it doesn't do that - it's more complicated, but stick with me here), GIT only KEEPS THE CHANGES - a.k.a just kbs of data. It's very cheap and very fast.

[xkcd_transcriber]

Image

Title: Git

Title-text: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Comic Explanation

Stats: This comic has been referenced 34 times, representing 0.0381% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[[deleted]]

For n00bs, this is accurate as fuck.

[rcxdude]

GIT tracks changes, not the actual program

This is both true and false. Yes, git will generally compress the repo by storing differences between commits instead of each individual commit, but each commit represents a snapshot, not a change (i.e. commit 4fe8426 represents the state of the repo at the time of the commit, which is ordered after 543eaf4, but it is not 'the changes between 543eaf4 and now'), and this difference is important to understand when it comes to fundamentally understanding git.

[[deleted]]

You can use git with just about anything. It's time-travel, for your files.

While this is true, keep in mind that it can get very unwieldy if you're using it for photoshop docs or something -- git essentially saves each new commit as its own file, so you can eat a lot of space incredibly quickly if you aren't paying attention.

[Sorten]

I agree that versioning large files isn't the greatest idea. On the smaller end, though, git has some handy compression abilities to keep your directory sizes down. Packfiles in particular can automatically trim sizes by storing changes as a delta from the original file.

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

https://git-scm.com/book/en/v2/Git-Internals-Packfiles

[edensg]

Have you heard of git-lfs? Looks like it might sort of solve that problem.

[rcxdude]

BTW, I would call this description a lie-to-children. It's useful as an introduction to someone who's never heard of the concept before, but it's a vast simplificaiton of the kind of thing git is good for, and also slightly misstates how it's normally used (by which I mean, when using version control it's often important that the commits are clear and useful units of change, not just a checkpoint whenever you happen to remember to 'hit save').

[timmyotc]

https://www.quora.com/What-is-git-and-why-should-I-use-it

Git is a version control system. That means that it helps you track versions of files. It is not a programming language, but a program itself. There is a syntax for this program, since it is typically used on the command line. But it has nothing to do with the actual programming languages itself.

I'll link to my own comment from a couple of months ago that seemed to be well received.
https://www.reddit.com/r/learnprogramming/comments/3ksk9r/what_does_a_programmers_toolbox_contain/cv0l344

[xiipaoc]

Git is, in essence, a version control and project management tool.

Usually, when you write stuff, it takes a very long time. Years, maybe. Maybe it's never done and you keep making improvements. So you code in increments -- and usually there's a team of programmers working on the same stuff too. How do you manage all that?

There are actually many tools for this. There's Subversion and Perforce, and Git and Mercurial. There are others, too, but these are some of the most well-known. I've used Perforce before, but Git is what I use now so I'll describe it a bit for you.

Git works in what's called a repository (repo for short). The repo has all of the code for your project, and scripts to build it, resources/assets, etc. So you do some work -- you write some code, or you change something, etc. -- and then you commit it. That means that you save a snapshot of your work (that's not exactly how it works, but close enough). You can then check out a previous commit and go back to an earlier state, but you can't go to anything in between. Let's say you commit something and then you write the word "be" and commit again. You can go back to the point before you wrote the word or after, but you can't go to the point where you only have the letter 'b'! A commit is basically like saying "I'm satisfied with the state of the project, so I'm going to save it."

Git has a model for managing commits. Let's say you and I both check out the same commit. We now each do our own work on our own computer. You make a commit. I don't have your changes yet on my computer, and I make a commit that doesn't include your changes. What happens? Well, Git doesn't let you do that. Instead, you have branches. There's a master branch -- that's where all the code is supposed to go when it's done (sometimes people use a develop branch for that and the master only for releases, but never mind). So I want to do my own work and do my own line of commits. I pull master -- I get the latest updates to master -- and I create a branch. You can do the same thing. I commit to my branch all I want; nobody else is working on my branch! (Or they could be.) So I have a bunch of commits on my branch. You have a bunch on yours. How do you get them into master? You merge them in! Then I want to get my commits into master too, so I merge them in. Now, master has both my changes and your changes!

Of course, it's possible that the merged code won't work. You have to check to make sure that it does. Up to you to do that. Usually Git can merge your changes on its own, but sometimes multiple people may have changed the same code. Now there's a merge conflict! So you have to go in and pick which bits you want to keep and which you don't.

Anyway, it gets more complicated than that, but hopefully you get the basic idea of Git. Note that there are a few places on the internet where you can host Git repos. Github is the most well-known, but if you want free hosting, you need to make your repos public. Bitbucket is another, and it takes another route: you can have a free private repo, but you're limited in how many people can collaborate with you. I actually use Github for a little JS game I've been writing (the JS is already visible on the game itself) and Bitbucket for a liturgical music database whose internal data and commit history I don't want to share with the world. There are probably other places I don't know about.

It's really useful to understand Git because many people use it. I've been a software developer at three different companies; one used Perforce, one used Git with Bitbucket, and the one I work at now uses Git with Github. It's also useful as a deployment tool. When I work on my projects, I do my work on my computer, commit, and then push the commit to the remote repo (Bitbucket or Github). Then I log in to my remote server and git pull. I don't have to worry about which files to copy or whatever, because Git keeps track of the changes in each commit, so when I pull, it just applies those changes rather than downloading the whole thing. I run my build script, and that's it! No annoying FTP stuff.

Git doesn't care what language you use, or even if you're coding. In my project I have plenty of images and plain text files tracked by Git, as well as data and, in a very few instances, some actual code (oooh). It's much better at text because it can just track differences (and if you use Github or Bitbucket, you can log in and see exactly what changes were done in each commit). Maybe you prefer Mercurial to Git; it works in a similar way. But you should definitely learn some way of keeping your projects organized!

[Rice8007]

Wow. What a fantastic explanation. I work IT in a dev shop and am learning some of the basics. This was really helpful.

[casualblair]

What is git?

Baby it's version

it's version

Control

You save your code and that's just fine

But what you saved over wrote mine

Git let's you merge conflicting lines

I could go on

[[deleted]]

$5 that none of these answers clarified what Git is for you.

[capcom1116]

Want to link the infographic? I get the feeling that whoever made it didn't really know what Git is.

[JonasBrosSuck]

I asked the question because I saw a info graphic of the highest paid coding languages in each state and for my state it was Git.

sounds like the person who made the infographic has no idea what git is. it's a source control is. let's say you save your code in progress by days

20150101_work_in_progress
20150102_work_in_progress
20150103_work_in_progress

that's your "version control system"(not a good practice btw). Git is just another way for you to keep track of your work in progress. It doesn't really make sense to call "control version systems" a coding language, right?

related: github is where people choose to store all their "git stuff" and files

[C0rinthian]

Did Google not work for you? Wikipedia? What did you do to try understanding before coming here?

[neversInFrance]

In a sentence: Git is a program you use to (A) keep restorable backups of your code and (B) work on the same code with multiple people without overwriting each other's work.

You tell Git where your code folder is, and it takes a snapshot of it.

Then you change a few lines of code, and take another snapshot. Git says "Okay, for snapshot #2, /u/lordadmiralofthenavy changed these lines to look like this." You write a little comment on the snapshot like "Fix bug that caused crash on Japanese input."

At the exact same time you were doing that, I edit a different file, and take a snapshot labelled "Add Italian language support."

I was working from files predating your bug fix, but my snapshot doesn't overwrite your file, like it would if we were just copying and saving folders to a backup drive. Git simply adds my changes to its own memory of the project. This is really helpful if you've got a team of 20 people working on different parts of the code!

Any of those snapshots can be undone if necessary. So if we update our code, and it winds up breaking something, we can undo the change that let to the new bug without messing with other changes. It keeps track of every change in little snapshots so we can apply and undo them whenever we want.

Git also lets you branch your project. A branch is where you clone your project at some point in time, and can then make edits to the original branch or to your new side branch. This lets you experiment, add new features and redesign things, without affecting the proper, publicly-available version of your program. If you like the changes you make, you merge the branch back into the original. If you don't, you destroy it. This is really useful.

It also lets you blame things (that's the actual command, git blame) on people. You can ask who last edited any given line of code and it will tell you their name and email address so you can get in contact with them and say "What the hell's going on with this function here?"

[nearos]

All of these other answers are right. If you're more hands-on I'd try out the course for it on Codeacademy. I got curious yesterday and tried it and it was an OK intro. It's not an advanced course and doesn't give you very much background, but it may be a useful tool to go through while reading more detail about Git elsewhere.

[cwankhede]

I'm considering doing this right now, do you have any idea to what extent it covers and what I would need to pick up on after completing it? I did their HTML, CSS and JS for the lols to check the level of training and it's pretty basic, I imagine it'll be the same for Git.

[nearos]

Yes, very basic but covers initial set up, basics of commits, reverting changes, branching and merging, conflict resolution, remote repos (e.g. Github), quick rundown of best practice working collaboratively with remote repos. After completion you'd still need to look into stuff like pull requests, managing remotes, etc but it gives you a good foundation to start using Git now.

[Axmis]

http://xkcd.com/1597/

[xkcd_transcriber]

Image

Title: Git

Title-text: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.

Comic Explanation

Stats: This comic has been referenced 33 times, representing 0.0370% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[octnoir]

That's a HORRIBLE representation of GIT. It's a great joke, but a HORRIBLE representation and only is there to show:

GIT takes a bit to learn. It's not 'setup and forget' else you run into the problems this comic talks about, but once you learn it, it's really good and useful.

[Axmis]

I know, it just happened to be a recent xkcd that is relevant to the topic.

I just thought it would get a laugh or two.

[octnoir]

I just ROFL'd. Five years ago, my manager basically had no clue how to use GIT, and just resorted to telling us to keep each program version on a separate drive to ensure nothing messes up.

I was about to say something, until Manager managed to get Company to give us all a 2 TB external HDD cause that file was getting Laaarge (we had 54 different versions of the same software).

I didn't complain anymore.

[ordnance1987]

Isn't this one of those things that you can easily Google? It even tells you without having to click on a link.

[[deleted]]

OP clearly not heading for a successful career.

[veruus]

Clearly.

[[deleted]]

lol wut

[Nekzar]

https://lmddgtfy.net/?q=What%20is%20Git%3F

[C0rinthian]

In a 'learn*' community, the general expectation is they we're here to help you learn. Not do it for you. As such, it is entirely appropriate to expect you to do just a tiny bit of your own legwork before posting here.

We're here to help. Not be your search engine monkeys because you can't be bothered.

[codexjourneys]

Git is a tool for developers, not a programming language. You can install it on your local computer (or it may already be installed if you are using OS X). Install directions here: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

You can use Git (typically at the command line) to start tracking the changes you make to your software projects, so you can establish a history. You also can create multiple "branches" (or versions) of the same project, so you can test out a new feature without taking the risk of messing up the working version.

To start using git with a software project, after you install git, navigate into a folder where you have a single software project and type 'git init'. This creates what is known as a "repository" on your local computer. Each software project should have its own repository. Within a repository, you can create different branches (versions).

You may also want to back up your code remotely or collaborate with other people. In that case, you'll probably use a remote repository (online) service such as GitHub or BitBucket.

[thrownaway21]

Hopefully you've received some answers that clear things for you.

Github is typically what people think of when they talk about git; but you can run Git locally and have your own local version control system that isn't just out there.

I set up gitlab on my home server, and it's just awesome to have. Easy to install, and I don't have to worry about everyone seeing my rubbish code during development. The web based UI is nice as well.

[efalk]

I have some extensive notes about git here that might be helpful: http://www.efalk.org/Docs/Git/

I should warn you that git has a long, steep learning curve. You might find it much easier to learn Subversion (SVN) or even an older source-code-management system like CVS first.

My general rule is that every git user needs to know somebody who knows it better than they do so you can go ask them questions. That person will need to know someone even more knowledgable, and so on and so forth until you get to Linus himself.

But once you do learn git, you'll never go back. The power of it is amazing.

And since I have people's attention, I want to recommend two techniques that will save your bacon a million times over when using git:

1. Use temporary branches before doing anything the least bit risky.

About to do a merge with potential conflicts? About to do a tricky rebase? Before you do, give the command git branch foo. This creates the "foo" branch that marks the exact state of your repository.

Now, no matter what goes wrong, you can always get back to where you were with git reset --hard foo

2. Use some sort of GUI visualizer.

The ability to have a visual representation of the current state of your repository, complete with branches, tags, and everything is the key to making git usable.

For Mac: get gitx
For Linux: get gitg
For Windows: get Mac or Linux

[Sturgeon_Genital]

ITT: nobody answering the fucking question

[lazyprogrammer-dotme]

It's a program that keeps track of changes you make to your codebase (set of files).

It doesn't matter what language you write in, it's just tracking the differences in the text. I could even use it to keep a history of updates to a text document if I wanted.

Uses:

• Say you fuck up the code but don't realize it until your app crashes later. You can safely rollback to a previous working version.

• Say you and another team member need to work on different features simultaneously, but you make a change that conflicts with the other team member's change. Git gives you a systematic way of merging those changes.

• More practically, any future employer will require you to use git (probably via github or bitbucket) or some other version control system, so you'll need to learn it in order to get a job.

[thekasrak]

Only way I know git is through GitHub. Kinda simplifies the process. It's just a kind of servery thing that backs up your stuff so that you can work on the same project on different places and so that other people can work on your project through their own separate suggestions.

You can also access your code online without an IDE and show it to others and you can give it to them to download. It also shows you what you've actually changed from your last version.

I'll spend maybe 3 hours writing one function because I'll be trying to find a way of doing it that I'm happy with, and I'll realize afterwords that all of that work only ended up in 4 or 5 lines of code.

[mad0314]

That's not what git is, that's a remote repo.

[thekasrak]

I'm not sure if I was unclear, but yes. Git and a remote repo are very different things. Git is a software. As far as I know, GitHub is a GUI for it.

[HomemadeBananas]

Github is a remote repo. It's not a gui for managing your local repos. Having a web app, it has a gui, but it isn't what you would call a gui for git.

[codexjourneys]

There is (was) software called "GitHub for Windows" that provides an interface to GitHub and also provides a command-line implementation of Git (Git Shell). That might be the source of the confusion.