-
Notifications
You must be signed in to change notification settings - Fork 46
Understanding git
Git is a type of source version control, which in short gives us a single location with shared code. Changes will have log entries and all previous versions can be fetched, which is sometimes used for bug hunting.
Git is a command line tool, but today everybody uses a graphical interface, which is build on top of the command line tool. Since the tool is the same for all clients, choice of client can be based on personal preference and switching is often possible without redownloading everything from GitHub.
GitHub is one of multiple hosts, which hosts git repositories. GitHub uses git, but git can be used without GitHub.
Git has a lot of features, which we will never need. For that reason we use a simplified setup compared to what is possible with git.
We use one repository on GitHub and all transfers will be between that one and the individual users. We do not make use of multi or decentralized server systems. This simplifies the setup to something more like a shared folder on a network drive, which everybody uses. This is the easiest setup to understand and the easiest way to get the newest version to everybody.
Git aims at reducing network traffic and to do that, each client will run a local server. Most tasks will interact with the local server and as such unlike most version control systems, git works well even on low quality internet connections, or (particularly useful for laptops) remains almost fully functional even when offline.
This means there is a 3 layer setup even through only two are obvious.
| Name | Description |
|---|---|
| Remote Origin | The GitHub server |
| Local server | This server exist on your HD, but it is hidden in a .git directory. You normally don't have to look at it |
| Working copy | This is the files you can see in explorer |
Moving files: Creating a local server: use clone. It will create a local copy of everything, which is on GitHub. It also creates a working copy. Getting updates from GitHub: use pull. It copies updates from Remote Origin to local server and updates working copy accordingly. Fetch will update local server with GitHub updates without updating the working copy (usually NOT what you want to do) Moving from working copy to local server: commit file(s) Moving from local server to GitHub: push (requires write permission on our GitHub project)
Generally no. Git will try to merge and unless you changed something in a file, which is also updated on GitHub and there are changes close to each other (like within 5 lines), git should be able to create a merged version, which will work just fine. Generally speaking, nothing should be lost by updating, but in case of conflict, it is possible to get questions where answering incorrectly will overwrite local changes.
Git logs all changes every single time somebody commits something. Also the auto merge of changes means using git will ensure we all have one shared version. Not using git will force us to constantly fork and have one personal project each, which will be a pain to merge manually.
This is done by following the guide how to play the development version