From bb8596aef900e4aeb4272c6573d688b044282c56 Mon Sep 17 00:00:00 2001 From: Griatch Date: Mon, 10 Jan 2022 23:54:56 +0100 Subject: [PATCH] Update version control docs. Resolve #2304 --- docs/source/Coding/Version-Control.md | 526 +++++++++++++------------- 1 file changed, 260 insertions(+), 266 deletions(-) diff --git a/docs/source/Coding/Version-Control.md b/docs/source/Coding/Version-Control.md index 06f5df57f3..9639608957 100644 --- a/docs/source/Coding/Version-Control.md +++ b/docs/source/Coding/Version-Control.md @@ -1,40 +1,40 @@ # Version Control - Version control software allows you to track the changes you make to your code, as well as being -able to easily backtrack these changes, share your development efforts and more. Even if you are not -contributing to Evennia itself, and only wish to develop your own MU* using Evennia, having a -version control system in place is a good idea (and standard coding practice). For an introduction -to the concept, start with the Wikipedia article -[here](https://en.wikipedia.org/wiki/Version_control). Evennia uses the version control system -[Git](https://git-scm.com/) and this is what will be covered henceforth. Note that this page also -deals with commands for Linux operating systems, and the steps below may vary for other systems, -however where possible links will be provided for alternative instructions. +able to easily backtrack these changes, share your development efforts and more. + +It's strongly recommended that you put your game code under version control. Version +control is also the way to contribue to Evennia itself. + +For an introduction to the concept, start with the Wikipedia article +[here](https://en.wikipedia.org/wiki/Version_control). Evennia uses the version +control system [Git](https://git-scm.com/) and this is what will be covered +henceforth. Note that this page primarily shows commands for Linux, but the +syntax should be the same for Windows and Mac. For more help on using Git, please refer to the [Official GitHub documentation](https://help.github.com/articles/set-up-git#platform-all). ## Setting up Git -If you have gotten Evennia installed, you will have Git already and can skip to **Step 2** below. -Otherwise you will need to install Git on your platform. You can find expanded instructions for +You can find expanded instructions for installation [here](https://git-scm.com/book/en/Getting-Started-Installing-Git). ### Step 1: Install Git - **Fedora Linux** - yum install git-core + yum install git-core -- **Debian Linux** _(Ubuntu, Linux Mint, etc.)_ +- **Debian Linux** _(Ubuntu, Linux Mint, etc.)_ - apt-get install git + apt-get install git -- **Windows**: It is recommended to use [Git for Windows](https://gitforwindows.org/). +- **Windows**: It is recommended to use [Git for Windows](https://gitforwindows.org/). - **Mac**: Mac platforms offer two methods for installation, one via MacPorts, which you can find out about [here](https://git-scm.com/book/en/Getting-Started-Installing-Git#Installing-on-Mac), or you can use the [Git OSX Installer](https://sourceforge.net/projects/git-osx-installer/). - + ### Step 2: Define user/e-mail Settings for Git To avoid a common issue later, you will need to set a couple of settings; first you will need to @@ -56,258 +56,303 @@ real, full name online, put a nickname here. ## Putting your game folder under version control -> Note: The game folder's version control is completely separate from Evennia's repository. +> Note: The game folder's version control is completely separate from Evennia's repository. After you have set up your game you will have created a new folder to host your particular game (let's call this folder `mygame` for now). -This folder is *not* under version control at this point. +This folder is *not* under version control at this point. git init mygame -Your mygame folder is now ready for version control! Now add all the content and make a first +Your mygame folder is now ready for version control! Add all the content and make a first commit: cd mygame git add * - git commit -m "Initial commit" + git commit -a -m "Initial commit" -Read on for help on what these commands do. +In turn these commands: +- Move us into the `mygame` folder +- Tell `git` that everything `*` means everything) in this folder should be put + under version control. +- _Commit_ all (`-a`) those newly added files to git and add a message `-m` so you remember + what you did at this point. Doing a commit is like saving a snapshot of the + current state of everything. +Read on for details! ### Tracking files When working on your code or fix bugs in your local branches you may end up creating new files. If -you do you must tell Git to track them by using the add command: +you do you must tell Git to track them by using the add command. -``` -git add + git add + +You only need to do this once per file. + + git status + +will show if you have any modified, added or otherwise changed files. Some +files, like database files, logs and temporary PID files are usually *not* +tracked in version control. These should either not show up or have a question +mark in front of them. + +```{note} +You will notice that some files are not covered by your git version control, +notably your settings file (`mygame/server/conf/settings.py`) and your sqlite3 +database file `mygame/server/evennia.db3`. What is auto-ignored by is controlled +by the hidden file `mygame/.gitignore`. Evennia creates this file as part of +the creation of your game directory. Everything matched in this file will be +ignored by git. If you want to, for example, include your settings file for +collaborators to access, remove that entry in `.gitignore`. ``` -You can check the current status of version control with `git status`. This will show if you have -any modified, added or otherwise changed files. Some files, like database files, logs and temporary -PID files are usually *not* tracked in version control. These should either not show up or have a -question mark in front of them. - -### Controlling tracking - -You will notice that some files are not covered by your git version control, notably your settings -file (`mygame/server/conf/settings.py`) and your sqlite3 database file `mygame/server/evennia.db3`. -This is controlled by the hidden file `mygame/.gitignore`. Evennia creates this file as part of the -creation of your game directory. Everything matched in this file will be ignored by GIT. If you want -to, for example, include your settings file for collaborators to access, remove that entry in -`.gitignore`. - -> Note: You should *never* put your sqlite3 database file into git by removing its entry in -`.gitignore`. GIT is for backing up your code, not your database. That way lies madness and a good -chance you'll confuse yourself so that after a few commits and reverts don't know what is in your -database or not. If you want to backup your database, do so by simply copying the file on your hard -drive to a backup-name. +```{warning} +You should *never* put your sqlite3 database file into git by removing its entry +in `.gitignore`. GIT is for backing up your code, not your database. That way +lies madness and a good chance you'll confuse yourself so that after a few +commits and reverts don't know what is in your database or not. If you want to +backup your database, do so by simply copying the file on your hard drive to a +backup-name. +``` ### Committing your Code -> Committing means storing the current snapshot of your code within git. This creates a "save point" -or "history" of your development process. You can later jump back and forth in your history, for -example to figure out just when a bug was introduced or see what results the code used to produce -compared to now. +_Committing_ your code means storing the current snapshot of your code within +git. This creates a "save point" or "history" of your development process. You +can later jump back and forth in your history, for example to figure out just +when a bug was introduced or see what results the code used to produce compared +to now. Or just wiping everything since the last commit, if you did something +stupid. -It's usually a good idea to commit your changes often. Committing is fast and local only - you will -never commit anything online at this point. To commit your changes, use +It's usually a good idea to commit your changes often. Committing is fast and +local only - you will never commit anything online at this point. To commit your +changes, use -``` -git commit --all -``` + git commit --all -This will save all changes you made since last commit. The command will open a text editor where you -can add a message detailing the changes you've made. Make it brief but informative. You can see the -history of commits with `git log`. If you don't want to use the editor you can set the message -directly by using the `-m` flag: +Also `-a` works. This will open a text editor for you to describe your change. +Be brief but informative in your message - you'll appreciate it later. When you +save and close the editor, the commit will be saved. You can create the message +directly with + + git commit -a -m "This fixes a bug in the combat code." -``` -git commit --all -m "This fixes a bug in the combat code." -``` ### Changing your mind -If you have non-committed changes that you realize you want to throw away, you can do the following: +If you have non-committed changes that you realize you want to throw away, you +'check out' the file you want - this will re-load it from the last committed +state: -``` -git checkout -``` + git checkout + git checkout foo/bar/dummy.py -This will revert the file to the state it was in at your last `commit`, throwing away the changes -you did to it since. It's a good way to make wild experiments without having to remember just what -you changed. If you do ` git checkout .` you will throw away _all_ changes since the last commit. +If you want to revert _all_ changes you did since last commit, do + + git checkout . + +(that is, add a single `.` at the end). ### Pushing your code online -So far your code is only located on your private machine. A good idea is to back it up online. The -easiest way to do this is to push it to your own remote repository on GitHub. +So far your code is only located on your private machine. A good idea is to back +it up online. The easiest way to do this is to push it to your own remote +repository on GitHub. -1. Make sure you have your game directory setup under git version control as described above. Make -sure to commit any changes. +```{important} +Just to avoid confusion, be aware that Github's documentation has changed to +calling the primary branch 'main' rather than 'master'. While Evennia still +uses 'master' branch (and this is what we refer to below), you can use either +name for your personal primary branch - they are equivalent. +``` + +1. Make sure you have your game directory setup under git version control as + described in the previous section. Make sure to commit any changes you did. 2. Create a new, empty repository on Github. Github explains how -[here](https://help.github.com/articles/create-a-repo/) (do *not* "Initialize the repository with a -README" or else you'll create unrelated histories). -3. From your local game dir, do `git remote add origin ` where `` is the URL -to your online repo. This tells your game dir that it should be pushing to the remote online dir. + [here](https://help.github.com/articles/create-a-repo/) (do *not* "Initialize + the repository with a README" or else you'll create unrelated histories). +3. From your local game dir, do `git remote add origin ` where + `` is the URL to your online repo. This tells your game dir that + it should be pushing to the remote online dir. 4. `git remote -v` to verify the online dir. -5. `git push origin master` now pushes your game dir online so you can see it on github.com. +5. `git push origin master` (or `git push origin main`) now pushes your game dir + online so you can see it on github.com. -You can commit your work locally (`git commit --all -m "Make a change that ..."`) as many times as -you want. When you want to push those changes to your online repo, you do `git push`. You can also -`git clone ` from your online repo to somewhere else (like your production -server) and henceforth do `git pull` to update that to the latest thing you pushed. +You can commit your work locally (`git commit --all -m "Make a change that +..."`) as many times as you want. When you want to push those changes to your +online repo, you do `git push`. You can also `git clone ` +from your online repo to somewhere else (like your production server) and +henceforth do `git pull` to update that to the latest thing you pushed. -Note that GitHub's repos are, by default publicly visible by all. Creating a publicly visible online -clone might not be what you want for all parts of your development process - you may prefer a more -private venue when sharing your revolutionary work with your team. If that's the case you can change -your repository to "Private" in the github settings. Then your code will only be visible to those -you specifically grant access. +Note that GitHub's repos are, by default publicly visible by all. Creating a +publicly visible online clone might not be what you want for all parts of your +development process - you may prefer a more private venue when sharing your +revolutionary work with your team. If that's the case you can change your +repository to "Private" in the github settings. Then your code will only be +visible to those you specifically grant access. ## Forking Evennia -This helps you set up an online *fork* of Evennia so you can easily commit fixes and help with -upstream development. +This helps you set up an online *fork* of the main Evennia repository so you can +easily commit fixes and help with upstream development. You can do this step +also if you _didn't_ put your game dir under version control like in the +previous section - the evennia repo and your game dir repo are completely +separate. ### Step 1: Fork the evennia/master repository -> Before proceeding with the following step, make sure you have registered and created an account on -[GitHub.com](https://github.com/). This is necessary in order to create a fork of Evennia's master -repository, and to push your commits to your fork either for yourself or for contributing to +> Before proceeding with the following step, make sure you have registered and +> created an account on [GitHub.com](https://github.com/). This is necessary in order to create a fork +of Evennia's master repository, and to push your commits to your fork either for +yourself or for contributing to Evennia. -A _fork_ is a clone of the master repository that you can make your own commits and changes to. At -the top of [this page](https://github.com/evennia/evennia), click the "Fork" button, as it appears -below. ![](https://github-images.s3.amazonaws.com/help/bootcamp/Bootcamp-Fork.png) +A _fork_ is a clone of the master repository that you can make your own commits +and changes to. At the top of [this page](https://github.com/evennia/evennia), +click the "Fork" button, as it appears below. +![](https://github-images.s3.amazonaws.com/help/bootcamp/Bootcamp-Fork.png) -### Step 2: Clone your fork +### Step 2: Clone your online fork of Evennia -The fork only exists online as of yet. In a terminal, change your directory to the folder you wish -to develop in. From this directory run the following command: +The fork only exists online as of yet. In a terminal, change your directory to +the folder you wish to develop in. From this directory run the following +command: -``` -git clone https://github.com/yourusername/evennia.git -``` + git clone https://github.com/yourusername/evennia.git + +This will download your fork to your computer. It creates a new folder +`evennia/` at your current location. -This will download your fork to your computer. It creates a new folder `evennia/` at your current -location. - ### Step 3: Configure remotes -A _remote_ is a repository stored on another computer, in this case on GitHub's server. When a -repository is cloned, it has a default remote called `origin`. This points to your fork on GitHub, -not the original repository it was forked from. To easily keep track of the original repository -(that is, Evennia's official repository), you need to add another remote. The standard name for this -remote is "upstream". +Your Evennia-fork is now separate from upstream, 'official' Evennia. You will +want to set it up so that you can easily sync our updates and changes to your +fork. -Below we change the active directory to the newly cloned "evennia" directory and then assign the -original Evennia repository to a remote called "upstream": +We do this by setting up a new _remote_. We actually already have one remote, +that is our own github form of Evennia. This got created when you cloned the +repo and defaults to being called `origin`. -``` -cd evennia -git remote add upstream https://github.com/evennia/evennia.git -``` +We will now create a new remote called `upstream`. -If you also want to access Evennia's `develop` branch (the bleeding edge development branch) do the -following: + cd evennia + git remote add upstream https://github.com/evennia/evennia.git -``` -git fetch upstream develop -git checkout develop -``` +This adds a remote to the main evennia repo. -You should now have the upstream branch available locally. You can use this instead of `master` -below if you are contributing new features rather than bug fixes. +If you also want to access Evennia's `develop` branch (the bleeding edge +development) do the following: + + git fetch upstream develop + git checkout develop + +Use + git checkout master + git checkout develop + +to switch between the branches. If you want to contribute a fix, ask first which +branch to use. Normally `master` is for bug fixes and `develop` is for new +features, but late in the development of a new Evennia version, all changes +often go into `develop`. -## Working with your fork +## Working with your Evennia fork -> A _branch_ is a separate instance of your code. Changes you do to code in a branch does not affect -that in other branches (so if you for example add/commit a file to one branch and then switches to -another branch, that file will be gone until you switch back to the first branch again). One can -switch between branches at will and create as many branches as one needs for a given project. The -content of branches can also be merged together or deleted without affecting other branches. This is -not only a common way to organize development but also to test features without messing with -existing code. +_Branches_ are stand-alone editions of the same code. You make a commit to a +branch. Switching to a branch will change the code on-disk. You can easily +make a new branch off a parent branch, and then merge it back into the same +branch later (or throw it away). This is a very common way to work on new +features in safety and isolation. -The default _branch_ of git is called the "master" branch. As a rule of thumb, you should *never* -make modifications directly to your local copy of the master branch. Rather keep the master clean -and only update it by pulling our latest changes to it. Any work you do should instead happen in a -local, other branches. +### Updating to latest Evennia -### Making a work branch +When Evennia's official repository updates, first make sure to commit all your +changes to your branch and then checkout the "clean" master branch: -``` -git checkout -b myfixes -``` + git checkout master + git pull upstream master -This command will checkout and automatically create the new branch `myfixes` on your machine. If you -stared out in the master branch, *myfixes* will be a perfect copy of the master branch. You can see -which branch you are on with `git branch` and change between different branches with `git checkout -`. +Or, if you are working against Evennia's development branch: -Branches are fast and cheap to create and manage. It is common practice to create a new branch for -every bug you want to work on or feature you want to create, then create a *pull request* for that -branch to be merged upstream (see below). Not only will this organize your work, it will also make -sure that *your* master branch version of Evennia is always exactly in sync with the upstream -version's master branch. + git checkout develop + git pull upstream develop -### Updating with upstream changes +The `pull` command will fetch all the changes from the "upstream" remote and +merge it into your local master/develop branch. It should now be a perfect copy +of the latest Evennia changes. -When Evennia's official repository updates, first make sure to commit all your changes to your -branch and then checkout the "clean" master branch: +### Making changes -``` -git commit --all -git checkout master -``` +As a rule of thumb you should _never_ work directly in Evennia's `master` or +`develop` branches. Instead you make a _new_ branch off the branch you want +and change _that_. -Pull the latest changes from upstream: + git checkout master (or develop) + check checkout -b strange_bug -``` -git pull upstream master -``` +You now have a new branch `strange_bug` that is an exact replica of the branch you +had checked out when you created it. Here you can now make your own +modifications. -This should sync your local master branch with upstream Evennia's master branch. Now we go back to -our own work-branch (let's say it's still called "myfixes") and _merge_ the updated master into our -branch. + git branches -``` -git checkout myfixes -git merge master -``` +will show you which branches are available and which one you are currently +using. Use `git checkout ` to move between them, but remember to commit +your changes before you do. -If everything went well, your `myfixes` branch will now have the latest version of Evennia merged -with whatever changes you have done. Use `git log` to see what has changed. You may need to restart -the server or run `manage.py migrate` if the database schema changed (this will be seen in the -commit log and on the mailing list). See the [Git manuals](https://git-scm.com/documentation) for -learning more about useful day-to-day commands, and special situations such as dealing with merge -collisions. +You often want to make sure also your work-branch has the latest upstream +changes. To do this, you need to first update your copy of the +`master`/`develop` branch and then _merge_ those changes into your work branch. +Make sure you have committed everything first! -## Sharing your Code Publicly + git commit -a -m "My latest changes ..." # on your strange_bug branch + git checkout master (or develop) + git pull upstream develop + git checkout strange_bug + git merge master (or develop) -Up to this point your `myfixes` branch only exists on your local computer. No one else can see it. -If you want a copy of this branch to also appear in your online fork on GitHub, make sure to have -checked out your "myfixes" branch and then run the following: +If everything went well, your `strange_bug` branch will now have the latest version +of Evennia merged with whatever changes you have done. -``` -git push -u origin myfixes -``` +Now work away on your code and commit with reasonable commit messages -This will create a new _remote branch_ named "myfixes" in your online repository (which is refered -to as "origin" by default); the `-u` flag makes sure to set this to the default push location. -Henceforth you can just use `git push` from your myfixes branch to push your changes online. This is -a great way to keep your source backed-up and accessible. Remember though that by default your -repository will be public so everyone will be able to browse and download your code (same way as you -can with Evennia itself). If you want secrecy you can change your repository to "Private" in the -Github settings. Note though that if you do, you might have trouble contributing to Evennia (since -we can't see the code you want to share). + git commit -a -m "Fixed the issue in ..." + git commit -a -m "Adding unit tests. This resolves #123." -*Note: If you hadn't setup a public key on GitHub or aren't asked for a username/password, you might -get an error `403: Forbidden Access` at this stage. In that case, some users have reported that the -workaround is to create a file `.netrc` under your home directory and add your credentials there:* +Use + + git diff + +to see what you changed since last commit, and + + git log + +to see past commits (including those made by Evennia upstream, remember that +your branch is a copy of the upstream one, including its history!) + +## Sharing your Evennia fixes on Github + +Up to this point your `strange_bug` branch only exists on your local computer. No +one else can see it. If you want a copy of this branch to also appear in your +online fork on GitHub, make sure to have checked out your "myfixes" branch and +then run the following: + + git push -u origin strange_bug + +You only need to do this once, the `-u` makes this the default push-location. In +the future, you can just push things online like this: + + git push + +### Troubleshooting + +If you hadn't setup a public key on GitHub or aren't asked for a +username/password, you might get an error `403: Forbidden Access` at this stage. +In that case, some users have reported that the workaround is to create a file +`.netrc` under your home directory and add your github credentials there: ```bash machine github.com @@ -315,87 +360,38 @@ login password ``` -## Committing fixes to Evennia +## Making an Evennia Pull Request -_Contributing_ can mean both bug-fixes or adding new features to Evennia. Please note that if your -change is not already listed and accepted in the [Issue -Tracker](https://github.com/evennia/evennia/issues), it is recommended that you first hit the -developer mailing list or IRC chat to see beforehand if your feature is deemed suitable to include -as a core feature in the engine. When it comes to bug-fixes, other developers may also have good -input on how to go about resolving the issue. +If you think that the fixes you did in your `strange_bug` branch should be a +part of the regular Evennia, you should create a _Pull Request_ (PR). This is a +call for the Evennia maintainer to pull your change into an upstream branch. -To contribute you need to have [forked Evennia](./Version-Control.md#forking-evennia) first. As described -above you should do your modification in a separate local branch (not in the master branch). This -branch is what you then present to us (as a *Pull request*, PR, see below). We can then merge your -change into the upstream master and you then do `git pull` to update master usual. Now that the -master is updated with your fixes, you can safely delete your local work branch. Below we describe -this work flow. +> It is wise to make separate branches for every fix or series of fixes you want +to contribute. -First update the Evennia master branch to the latest Evennia version: +Assuming you have followed the instructions above and have pushed your changes +online, [create a pull request](https://github.com/evennia/evennia/pulls) and +follow the instructions. Make sure to specifically select your `strange_bug` +branch to be the source of the merge and use the branch you based that branch +off (`master` or `develop`) as the target. -``` -git checkout master -git pull upstream master -``` +Evennia developers will then be able to examine your request and merge it if +it's deemed suitable. They may also come back with feedback and request you do +some changes. -Next, create a new branch to hold your contribution. Let's call it the "fixing_strange_bug" branch: +Once approved and merged, your change will now be available in the upstream +branch: -``` -git checkout -b fixing_strange_bug -``` + git checkout master (or develope) + git pull upstream master (or develop) -It is wise to make separate branches for every fix or series of fixes you want to contribute. You -are now in your new `fixing_strange_bug` branch. You can list all branches with `git branch` and -jump between branches with `git checkout `. Code and test things in here, committing as -you go: +Since your changes are now in upstream, your local `strange_bug` branch is now +superfluous and should be deleted: -``` -git commit --all -m "Fix strange bug in look command. Resolves #123." -``` + git branch -D strange_bug -You can make multiple commits if you want, depending on your work flow and progress. Make sure to -always make clear and descriptive commit messages so it's easy to see what you intended. To refer -to, say, issue number 123, write `#123`, it will turn to a link on GitHub. If you include the text -"Resolves #123", that issue will be auto-closed on GitHub if your commit gets merged into main -Evennia. - ->If you refer to in-game commands that start with `@`(such as `@examine`), please put them in -backticks \`, for example \`@examine\`. The reason for this is that GitHub uses `@username` to refer -to GitHub users, so if you forget the ticks, any user happening to be named `examine` will get a -notification .... - -If you implement multiple separate features/bug-fixes, split them into different branches if they -are very different and should be handled as separate PRs. You can do any number of commits to your -branch as you work. Once you are at a stage where you want to show the world what you did you might -want to consider making it clean for merging into Evennia's master branch by using [git -rebase](https://www.git-scm.com/book/en/v2/Git-Branching-Rebasing) (this is not always necessary, -and if it sounds too hard, say so and we'll handle it on our end). - -Once you are ready, push your work to your online Evennia fork on github, in a new remote branch: - -``` -git push -u origin fixing_strange_bug -``` - -The `-u` flag is only needed the first time - this tells GIT to create a remote branch. If you -already created the remote branch earlier, just stand in your `fixing_strange_bug` branch and do -`git push`. - -Now you should tell the Evennia developers that they should consider merging your brilliant changes -into Evennia proper. [Create a pull request](https://github.com/evennia/evennia/pulls) and follow -the instructions. Make sure to specifically select your `fixing_strange_bug` branch to be the source -of the merge. Evennia developers will then be able to examine your request and merge it if it's -deemed suitable. - -Once your changes have been merged into Evennia your local `fixing_strange_bug` can be deleted -(since your changes are now available in the "clean" Evennia repository). Do - -``` -git branch -D fixing_strange_bug -``` - -to delete your work branch. Update your master branch (`checkout master` and then `git pull`) and -you should get your fix back, now as a part of official Evennia! +You can also safely delete your online `strange_bug` branch in your fork +(you can do this from the PR page on github). ## GIT tips and tricks @@ -405,7 +401,7 @@ can create aliases for those. Here are some useful commands to run: ``` -# git st +# git st # - view brief status info git config --global alias.st 'status -s' ``` @@ -415,13 +411,13 @@ alias. Afterwards, just do `git st` to get status info. All the examples below f template. ``` -# git cl +# git cl # - clone a repository git config --global alias.cl clone ``` ``` -# git cma "commit message" +# git cma "commit message" # - commit all changes without opening editor for message git config --global alias.cma 'commit -a -m' ``` @@ -440,7 +436,7 @@ git config --global alias.fl 'log -u' ``` # git co [branchname] -# - checkout +# - checkout git config --global alias.co checkout ``` @@ -469,7 +465,5 @@ git config --global alias.diff 'diff --word-diff' git config --global alias.grep 'grep -Ii' ``` -To get a further feel for GIT there is also [a good YouTube talk about -it](https://www.youtube.com/watch?v=1ffBJ4sVUb4#t=1m58s) - it's a bit long but it will help you -understand the underlying ideas behind GIT +To get a further feel for GIT there is also [a good YouTube talk about it](https://www.youtube.com/watch?v=1ffBJ4sVUb4#t=1m58s) - it's a bit long but it will help you understand the underlying ideas behind GIT (which in turn makes it a lot more intuitive to use).