what is git/version control?
In: Technology
If you ever worked on a school project (presentation, essay, report, etc), I’m sure you did like most people do at some point:
– You create a folder like 2019-09-12_FinalVersion
– Then you make changes, but you’re not too sure about them, so you copy everything into 2019-09-12_FinalVersionV2
– Then your friends suggests some corrections, but the version you sent him was 2019-09-11_Draft12, so now you have to check the comments on this version and add them to a 2019-09-12_FinalVersion2_modified
And so on. It’s even worse if you work collaboratively on a document, maybe contributing yourself to a third of a document.
If you already worked like this at some point, then you know what version control is: it’s a way to streamline this process and make it less of a mess.
Any project can be tracked with git (but it works better with text than binary, more on that later), you just have to go into a folder and type _git init_.
Now, you can start working as you normally would. When you feel like you’ve made sufficient changes, you can tell git to take a sort of snapshot of your folder; you can give it a short description like “Added the thing to part 1” to describe what you did. Then git will keep a copy of your documents somewhere, so that you can come back to this snaphshot almost anytime you want 🙂
You can easily keep an history of the changes like this, with snapshots of your folder (we call those snapshots *commits*, by the way). This history is very powerful! You can revert back to a previous version by simply asking git to get the document of a previous commit. You don’t even have to know *where* the different versions are: git will get them for you if you ask him 🙂
You can also *compare* two commits, to precisely see what changed between them (lines and files added, lines and files removed) (this is the part for text is easier to deal with than binary)
You know that people always suggest to make backups, right? Git can help with that as well! If a git project exists on two different computers (yours and a server, or your’s and a friend’s), then git can automatically synchronize both instances really easily. Taking care of sending the files that changed, and so on. You just have to *push* your changes to the other computer.
Now git helps immensely with collaborative work! Let’s say you commited something on 2019-09-12 at 2pm, and your friends want to work on their part of the project.
You can setup a git server (like github) and start to git project there. Now, everyone who wants to contribute has to create a git project on there computer by telling git “I want to work on project ‘MyCoolPresentation’ that is hosted on GitHub”
Git will get for you the history of the project (remember, the commits). And you can start makeing changes and pushing them.
Now what happens if two contributors try to push changes at the same time? This is where ‘branches’ happen, and that git becomes very powerful.
Commits don’t have to all follow each other, they can also *diverge*! A branch is like a path of commits that your project can take. At some point in history, you will say “Okay, now I want to work on part III”, and your friend will say “Righto, now I want to work on part XI”.
The same document will then evolve in two separate ways: part III completed and part XI empty, and the reverse. Think of it like alternative timelines. You can each progress on your part without impacting the work of your friend, and when you think you are done with your part, you can easily merge them back together and keep going from there (the process gets more involved now, and I lack time to continue too)
Did you understand everything? Now finish your plate and go to your room.
Latest Answers