We use git at Bump for all sorts of things. Recently, we've started converting our designers and product managers. You can think about git like Dropbox: it takes files on your computer, puts them in the cloud, and lets other people work on them too. But it has some pretty rocking advantages:
Like Dropbox, git lets multiple people work on the same files at the same time. This is great when many people are working on a document together, or a group of people are creating assets for a website. Everyone can be contributing to the same folder and files, without fear of overwriting eachother's work, something Dropbox can scew up.
Even if you don't have a team of people, git has some awesome-sauce. It can act like a time machine, allowing you go and see what you did last week, or even last year, help you recover files you deleted, and keep track of progress over time. It has powerful tools to let you see what you've changed over time.
git is also great for backing things up, so you don't lose them. It can let you learn about how you work: when do you do your best work? How often do you change everything? There are tools to show you visual differences between versions of images, and all sorts of things.
git is awesome... but conceptually it's a leap from most people's mental models of what a file is.
There are so many wonderful reasons for non-programmers to use git when working with other people (especially programmers) and I'd like to convince you that there are even more awesome rewards down the way of git, but I won't do that today.
My goal today:
>Provide an analogy to Dropbox to help designers and product managers understand the mental model of how git works.
It might help you to think about git like Dropbox to start. It's like Dropbox but with a whole lot more steps. Have faith (for the moment) that the more steps are worth it, and I'll talk you through the differences.
First, a quick overview of how Dropbox works: many people can be working on the same file on their own computers, and magically they all get each other's changes. Behind the scenes Dropbox is doing all sorts of things to make this work. With git, you end up helping do some of the behind the scenes work, and git thanks you.
Here is a more explicit model of how Dropbox works.
- You install Dropbox.
- Someone shares a folder with you.
- Your computer downloads the contents of that folder from the "Cloud"
- You make some changes to a file in the folder and save it.
- Your changes get sent up to the Dropbox "Cloud" immediately
- Everyone else gets your changes downloaded to their computers immediately.
Yay. This is just like git! Only git lacks some of the "immediately" magic. Steps 4, 5, and 6 don't happen automatically: you have to tell git when you want it to do each step. Let me break it down for you.
The first difference is that git doesn't assume that you want to send every saved change to the cloud. It makes you be explicit about what you want to send to the cloud.
>Whereas Dropbox automatically uploads everything when you save it, git adds a new step: commitment. After you save a file, you must tell git that you are "committed" to this change.
To do this, you do what is called "staging." This is really just telling git which changes you were sure about. This way, git doesn't waste other people's time if you make a draft you don't like.
Second difference: Dropbox uploads your files immediately. (It tries to anyway). git isn't quite as eager to get things into the cloud.
>In git, uploading to the cloud is called "pushing." You are literally pushing the changes from your computer up in to the cloud. Only then will other people be able to download them.
The next difference is downloading. Can you spot the difference? Why, that's right! While Dropbox downloads the new changes automatically, git waits for you to tell it too.
>You must ask git explicitly to "pull" the changes down from the cloud to your computer. This gives you the latest greatest copy of the documents, including everyone else's changes
Stay strong! Keep faith that even though there is seemingly less magic, and more work, there are reasons for all this mortal toil [sic]!
git requires you to operate with a slightly different order of operations because it is more manual (slightly less magic).
Before you start changing things, you want to make sure you have the latest and greatest version with everyone else's changes. That means the first thing you want to do is download the latest stuff from the cloud (i.e. do a pull).
Now that you have the latest, you can change it and edit it to your heart's content. When you are happy with your changes you are ready to tell git you're happy (i.e. commit).
>You can also rinse lather and repeat step 4 many times, committing small changes before going to the next step.
But wait a second! What if Brian in marketing changed the document WHILE you were working on it? Because git doesn't automatically download the changes, your computer (and you, by extension) doesn't know about the new changes. So this adds another step, redownloading (i.e. doing another pull!)
Okay, now git knows about your changes, it knows about Brian's changes, and the only thing left to do is... Push! Finally we can upload our changes to the cloud for everyone else to see and look at.
It's like Dropbox, but you have to tell it to download, save, download, and upload each time. (Pull, stage & commit, pull, and push)
If you are digging it so far, let's tackle some Advanced differences.
There are some other model differences between git and dropbox. The first are conflicts: what happens when two people change the same file. Another big one is the fact that git is "distributed," i.e. there is no company holding the cloud for you... there can even be multiple clouds.
Here are some quick overviews of salient differences.
Every commit makes a little tick on a timeline. git keeps track of EVERY little tick. That means you can zoom back in time, and watch as your document changes from day 0 to present. You can see every change, along with who made it, and what there "commit message" was. Pretty cool.
>git has multi-player undo You can find out exactly who made the typo, and when and then fix it really easily. (git has really awesome tools for this too).
What happens when Brian changed that file in the cloud, while you were working on it on your computer? Dropbox takes care of it magically in the cloud, now… it's your job. The second step 6 (re-pulling changes from the cloud) in your work flow is when you are most likely to have "merge conflicts".
>Usually git is pretty magical and figures out what to do if both you and Brian were editing the same file. For example if he changed the title of the document, and you added some foot notes, git will figure it out. However, if you change your salary to $350,000, and Brian changes it to $40, git isn't going to know what to do.
If Brian pushed his change first, git will make you fix it. It will say: "Brian said you make $40 an hour, but you said you make $350,000, who's right". Your call. Fix it, save it (commit it) and push it it! (but do pull it in case Brian caught his error and changed it to $400,000 while you were typing)
Every time you save (commit really) some changes, git asks you for a "commit message". This is couple of sentences that describe the changes you made: a brief overview so that someone could review the list of changes to this document, without having to read the whole thing.
Because git is a little more manual, there are a few stylistic changes suggested to make everyone happy. First of all, small changes. You should commit every time you finish changing a coherent piece. I.e. if you are changing your salary, and Brian's, first make one commit with your increase and a commit message like "merit based salary adjustments", then adjust Brian's with a commit message of "balance the budget". Good (informative) commit messages are very appreciated in git land.
Due to the nature of fixing conflicts, git also prefers text. Images are much harder for it (and you) to merge if both people change at once. So whenever possible use a text format (like html or markdown).
Well, I don't know if I convinced you that you HAVE to use git, but hopefully you understand it a little better now. If you are already using it, hopefully now it makes a little more sense. At the very least, you are a step closer to being a friend and co-conspirator of git.
This will be translated and added into a class repository. Will add link when done.