Annikka/evennia
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update version control docs. Resolve #2304

Browse source
This commit is contained in:
Griatch 2022-01-10 23:54:56 +01:00
parent 95bc3427e2
commit bb8596aef9
1 changed files with 260 additions and 266 deletions
Download patch file Download diff file Expand all files Collapse all files

526
docs/source/Coding/Version-Control.md
View file

@ -1,40 +1,40 @@
# Version Control # Version Control
Version control software allows you to track the changes you make to your code, as well as being 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 able to easily backtrack these changes, share your development efforts and more.
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 It's strongly recommended that you put your game code under version control. Version
to the concept, start with the Wikipedia article control is also the way to contribue to Evennia itself.
[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 For an introduction to the concept, start with the Wikipedia article
deals with commands for Linux operating systems, and the steps below may vary for other systems, [here](https://en.wikipedia.org/wiki/Version_control). Evennia uses the version
however where possible links will be provided for alternative instructions. 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 For more help on using Git, please refer to the [Official GitHub
documentation](https://help.github.com/articles/set-up-git#platform-all). documentation](https://help.github.com/articles/set-up-git#platform-all).
## Setting up Git ## Setting up Git
If you have gotten Evennia installed, you will have Git already and can skip to **Step 2** below. You can find expanded instructions for
Otherwise you will need to install Git on your platform. You can find expanded instructions for
installation [here](https://git-scm.com/book/en/Getting-Started-Installing-Git). installation [here](https://git-scm.com/book/en/Getting-Started-Installing-Git).
### Step 1: Install Git ### Step 1: Install Git
- **Fedora Linux** - **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 - **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 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/). you can use the [Git OSX Installer](https://sourceforge.net/projects/git-osx-installer/).
### Step 2: Define user/e-mail Settings for Git ### 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 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 ## 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 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). (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 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: commit:
cd mygame cd mygame
git add * 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 ### Tracking files
When working on your code or fix bugs in your local branches you may end up creating new files. If 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 <filename>
git add <filename>
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 ```{warning}
any modified, added or otherwise changed files. Some files, like database files, logs and temporary You should *never* put your sqlite3 database file into git by removing its entry
PID files are usually *not* tracked in version control. These should either not show up or have a in `.gitignore`. GIT is for backing up your code, not your database. That way
question mark in front of them. 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
### Controlling tracking backup your database, do so by simply copying the file on your hard drive to a
backup-name.
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.
### Committing your Code ### Committing your Code
> Committing means storing the current snapshot of your code within git. This creates a "save point" _Committing_ your code means storing the current snapshot of your code within
or "history" of your development process. You can later jump back and forth in your history, for git. This creates a "save point" or "history" of your development process. You
example to figure out just when a bug was introduced or see what results the code used to produce can later jump back and forth in your history, for example to figure out just
compared to now. 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 It's usually a good idea to commit your changes often. Committing is fast and
never commit anything online at this point. To commit your changes, use 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 Also `-a` works. This will open a text editor for you to describe your change.
can add a message detailing the changes you've made. Make it brief but informative. You can see the Be brief but informative in your message - you'll appreciate it later. When you
history of commits with `git log`. If you don't want to use the editor you can set the message save and close the editor, the commit will be saved. You can create the message
directly by using the `-m` flag: 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 ### 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 <file_to_revert>
git checkout <file to revert> 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 If you want to revert _all_ changes you did since last commit, do
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. git checkout .
(that is, add a single `.` at the end).
### Pushing your code online ### 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 So far your code is only located on your private machine. A good idea is to back
easiest way to do this is to push it to your own remote repository on GitHub. 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 ```{important}
sure to commit any changes. 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 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 [here](https://help.github.com/articles/create-a-repo/) (do *not* "Initialize
README" or else you'll create unrelated histories). the repository with a README" or else you'll create unrelated histories).
3. From your local game dir, do `git remote add origin <github URL>` where `<github URL>` is the URL 3. From your local game dir, do `git remote add origin <github URL>` where
to your online repo. This tells your game dir that it should be pushing to the remote online dir. `<github URL>` 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. 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 can commit your work locally (`git commit --all -m "Make a change that
you want. When you want to push those changes to your online repo, you do `git push`. You can also ..."`) as many times as you want. When you want to push those changes to your
`git clone <url_to_online_repo>` from your online repo to somewhere else (like your production online repo, you do `git push`. You can also `git clone <url_to_online_repo>`
server) and henceforth do `git pull` to update that to the latest thing you pushed. 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 Note that GitHub's repos are, by default publicly visible by all. Creating a
clone might not be what you want for all parts of your development process - you may prefer a more publicly visible online clone might not be what you want for all parts of your
private venue when sharing your revolutionary work with your team. If that's the case you can change development process - you may prefer a more private venue when sharing your
your repository to "Private" in the github settings. Then your code will only be visible to those revolutionary work with your team. If that's the case you can change your
you specifically grant access. repository to "Private" in the github settings. Then your code will only be
visible to those you specifically grant access.
## Forking Evennia ## Forking Evennia
This helps you set up an online *fork* of Evennia so you can easily commit fixes and help with This helps you set up an online *fork* of the main Evennia repository so you can
upstream development. 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 ### Step 1: Fork the evennia/master repository
> Before proceeding with the following step, make sure you have registered and created an account on > Before proceeding with the following step, make sure you have registered and
[GitHub.com](https://github.com/). This is necessary in order to create a fork of Evennia's master > created an account on [GitHub.com](https://github.com/). This is necessary in order to create a fork
repository, and to push your commits to your fork either for yourself or for contributing to of Evennia's master repository, and to push your commits to your fork either for
yourself or for contributing to
Evennia. Evennia.
A _fork_ is a clone of the master repository that you can make your own commits and changes to. At A _fork_ is a clone of the master repository that you can make your own commits
the top of [this page](https://github.com/evennia/evennia), click the "Fork" button, as it appears and changes to. At the top of [this page](https://github.com/evennia/evennia),
below. ![](https://github-images.s3.amazonaws.com/help/bootcamp/Bootcamp-Fork.png) 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 The fork only exists online as of yet. In a terminal, change your directory to
to develop in. From this directory run the following command: 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 ### Step 3: Configure remotes
A _remote_ is a repository stored on another computer, in this case on GitHub's server. When a Your Evennia-fork is now separate from upstream, 'official' Evennia. You will
repository is cloned, it has a default remote called `origin`. This points to your fork on GitHub, want to set it up so that you can easily sync our updates and changes to your
not the original repository it was forked from. To easily keep track of the original repository fork.
(that is, Evennia's official repository), you need to add another remote. The standard name for this
remote is "upstream".
Below we change the active directory to the newly cloned "evennia" directory and then assign the We do this by setting up a new _remote_. We actually already have one remote,
original Evennia repository to a remote called "upstream": that is our own github form of Evennia. This got created when you cloned the
repo and defaults to being called `origin`.
``` We will now create a new remote called `upstream`.
cd evennia
git remote add upstream https://github.com/evennia/evennia.git
```
If you also want to access Evennia's `develop` branch (the bleeding edge development branch) do the cd evennia
following: git remote add upstream https://github.com/evennia/evennia.git
``` This adds a remote to the main evennia repo.
git fetch upstream develop
git checkout develop
```
You should now have the upstream branch available locally. You can use this instead of `master` If you also want to access Evennia's `develop` branch (the bleeding edge
below if you are contributing new features rather than bug fixes. 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 _Branches_ are stand-alone editions of the same code. You make a commit to a
that in other branches (so if you for example add/commit a file to one branch and then switches to branch. Switching to a branch will change the code on-disk. You can easily
another branch, that file will be gone until you switch back to the first branch again). One can make a new branch off a parent branch, and then merge it back into the same
switch between branches at will and create as many branches as one needs for a given project. The branch later (or throw it away). This is a very common way to work on new
content of branches can also be merged together or deleted without affecting other branches. This is features in safety and isolation.
not only a common way to organize development but also to test features without messing with
existing code.
The default _branch_ of git is called the "master" branch. As a rule of thumb, you should *never* ### Updating to latest Evennia
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.
### 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 master
git checkout -b myfixes git pull upstream master
```
This command will checkout and automatically create the new branch `myfixes` on your machine. If you Or, if you are working against Evennia's development branch:
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
<branchname>`.
Branches are fast and cheap to create and manage. It is common practice to create a new branch for git checkout develop
every bug you want to work on or feature you want to create, then create a *pull request* for that git pull upstream develop
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.
### 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 ### Making changes
branch and then checkout the "clean" master branch:
``` As a rule of thumb you should _never_ work directly in Evennia's `master` or
git commit --all `develop` branches. Instead you make a _new_ branch off the branch you want
git checkout master and change _that_.
```
Pull the latest changes from upstream: git checkout master (or develop)
check checkout -b strange_bug
``` You now have a new branch `strange_bug` that is an exact replica of the branch you
git pull upstream master 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 git branches
our own work-branch (let's say it's still called "myfixes") and _merge_ the updated master into our
branch.
``` will show you which branches are available and which one you are currently
git checkout myfixes using. Use `git checkout <branch>` to move between them, but remember to commit
git merge master your changes before you do.
```
If everything went well, your `myfixes` branch will now have the latest version of Evennia merged You often want to make sure also your work-branch has the latest upstream
with whatever changes you have done. Use `git log` to see what has changed. You may need to restart changes. To do this, you need to first update your copy of the
the server or run `manage.py migrate` if the database schema changed (this will be seen in the `master`/`develop` branch and then _merge_ those changes into your work branch.
commit log and on the mailing list). See the [Git manuals](https://git-scm.com/documentation) for Make sure you have committed everything first!
learning more about useful day-to-day commands, and special situations such as dealing with merge
collisions.
## 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 everything went well, your `strange_bug` branch will now have the latest version
If you want a copy of this branch to also appear in your online fork on GitHub, make sure to have of Evennia merged with whatever changes you have done.
checked out your "myfixes" branch and then run the following:
``` Now work away on your code and commit with reasonable commit messages
git push -u origin myfixes
```
This will create a new _remote branch_ named "myfixes" in your online repository (which is refered git commit -a -m "Fixed the issue in ..."
to as "origin" by default); the `-u` flag makes sure to set this to the default push location. git commit -a -m "Adding unit tests. This resolves #123."
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).
*Note: If you hadn't setup a public key on GitHub or aren't asked for a username/password, you might Use
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:* 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 ```bash
machine github.com machine github.com
@ -315,87 +360,38 @@ login <my_github_username>
password <my_github_password> password <my_github_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 If you think that the fixes you did in your `strange_bug` branch should be a
change is not already listed and accepted in the [Issue part of the regular Evennia, you should create a _Pull Request_ (PR). This is a
Tracker](https://github.com/evennia/evennia/issues), it is recommended that you first hit the call for the Evennia maintainer to pull your change into an upstream branch.
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.
To contribute you need to have [forked Evennia](./Version-Control.md#forking-evennia) first. As described > It is wise to make separate branches for every fix or series of fixes you want
above you should do your modification in a separate local branch (not in the master branch). This to contribute.
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.
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.
``` Evennia developers will then be able to examine your request and merge it if
git checkout master it's deemed suitable. They may also come back with feedback and request you do
git pull upstream master 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 master (or develope)
git checkout -b fixing_strange_bug 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 Since your changes are now in upstream, your local `strange_bug` branch is now
are now in your new `fixing_strange_bug` branch. You can list all branches with `git branch` and superfluous and should be deleted:
jump between branches with `git checkout <branchname>`. Code and test things in here, committing as
you go:
``` git branch -D strange_bug
git commit --all -m "Fix strange bug in look command. Resolves #123."
```
You can make multiple commits if you want, depending on your work flow and progress. Make sure to You can also safely delete your online `strange_bug` branch in your fork
always make clear and descriptive commit messages so it's easy to see what you intended. To refer (you can do this from the PR page on github).
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!
## GIT tips and tricks ## 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 # - view brief status info
git config --global alias.st 'status -s' 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. template.
``` ```
# git cl # git cl
# - clone a repository # - clone a repository
git config --global alias.cl clone git config --global alias.cl clone
``` ```
``` ```
# git cma "commit message" # git cma "commit message"
# - commit all changes without opening editor for message # - commit all changes without opening editor for message
git config --global alias.cma 'commit -a -m' git config --global alias.cma 'commit -a -m'
``` ```
@ -440,7 +436,7 @@ git config --global alias.fl 'log -u'
``` ```
# git co [branchname] # git co [branchname]
# - checkout # - checkout
git config --global alias.co 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' git config --global alias.grep 'grep -Ii'
``` ```
To get a further feel for GIT there is also [a good YouTube talk about 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
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). (which in turn makes it a lot more intuitive to use).