mirror of
https://github.com/evennia/evennia.git
synced 2026-03-18 22:06:30 +01:00
Updated HTML docs
This commit is contained in:
Griatch
parent
210c5ee4db
commit
1999a4caeb
38 changed files with 634 additions and 612 deletions
|
|
@ -43,31 +43,30 @@
|
|||
<section class="tex2jax_ignore mathjax_ignore" id="version-control">
|
||||
<h1>Version Control<a class="headerlink" href="#version-control" title="Permalink to this headline">¶</a></h1>
|
||||
<p>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
|
||||
<a class="reference external" href="https://en.wikipedia.org/wiki/Version_control">here</a>. Evennia uses the version control system
|
||||
<a class="reference external" href="https://git-scm.com/">Git</a> 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.</p>
|
||||
able to easily backtrack these changes, share your development efforts and more.</p>
|
||||
<p>It’s strongly recommended that you put your game code under version control. Version
|
||||
control is also the way to contribue to Evennia itself.</p>
|
||||
<p>For an introduction to the concept, start with the Wikipedia article
|
||||
<a class="reference external" href="https://en.wikipedia.org/wiki/Version_control">here</a>. Evennia uses the version
|
||||
control system <a class="reference external" href="https://git-scm.com/">Git</a> 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.</p>
|
||||
<p>For more help on using Git, please refer to the <a class="reference external" href="https://help.github.com/articles/set-up-git#platform-all">Official GitHub
|
||||
documentation</a>.</p>
|
||||
<section id="setting-up-git">
|
||||
<h2>Setting up Git<a class="headerlink" href="#setting-up-git" title="Permalink to this headline">¶</a></h2>
|
||||
<p>If you have gotten Evennia installed, you will have Git already and can skip to <strong>Step 2</strong> below.
|
||||
Otherwise you will need to install Git on your platform. You can find expanded instructions for
|
||||
<p>You can find expanded instructions for
|
||||
installation <a class="reference external" href="https://git-scm.com/book/en/Getting-Started-Installing-Git">here</a>.</p>
|
||||
<section id="step-1-install-git">
|
||||
<h3>Step 1: Install Git<a class="headerlink" href="#step-1-install-git" title="Permalink to this headline">¶</a></h3>
|
||||
<ul>
|
||||
<li><p><strong>Fedora Linux</strong></p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span> yum install git-core
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span> yum install git-core
|
||||
</pre></div>
|
||||
</div>
|
||||
</li>
|
||||
<li><p><strong>Debian Linux</strong> <em>(Ubuntu, Linux Mint, etc.)</em></p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span> apt-get install git
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span> apt-get install git
|
||||
</pre></div>
|
||||
</div>
|
||||
</li>
|
||||
|
|
@ -112,301 +111,328 @@ real, full name online, put a nickname here.</p>
|
|||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git init mygame
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Your mygame folder is now ready for version control! Now add all the content and make a first
|
||||
<p>Your mygame folder is now ready for version control! Add all the content and make a first
|
||||
commit:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>cd mygame
|
||||
git add *
|
||||
git commit -m "Initial commit"
|
||||
git commit -a -m "Initial commit"
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Read on for help on what these commands do.</p>
|
||||
<p>In turn these commands:</p>
|
||||
<ul class="simple">
|
||||
<li><p>Move us into the <code class="docutils literal notranslate"><span class="pre">mygame</span></code> folder</p></li>
|
||||
<li><p>Tell <code class="docutils literal notranslate"><span class="pre">git</span></code> that everything <code class="docutils literal notranslate"><span class="pre">*</span></code> means everything) in this folder should be put
|
||||
under version control.</p></li>
|
||||
<li><p><em>Commit</em> all (<code class="docutils literal notranslate"><span class="pre">-a</span></code>) those newly added files to git and add a message <code class="docutils literal notranslate"><span class="pre">-m</span></code> so you remember
|
||||
what you did at this point. Doing a commit is like saving a snapshot of the
|
||||
current state of everything.</p></li>
|
||||
</ul>
|
||||
<p>Read on for details!</p>
|
||||
<section id="tracking-files">
|
||||
<h3>Tracking files<a class="headerlink" href="#tracking-files" title="Permalink to this headline">¶</a></h3>
|
||||
<p>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:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">add</span> <span class="o"><</span><span class="n">filename</span><span class="o">></span>
|
||||
you do you must tell Git to track them by using the add command.</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git add <filename>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You can check the current status of version control with <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">status</span></code>. 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 <em>not</em> tracked in version control. These should either not show up or have a
|
||||
question mark in front of them.</p>
|
||||
</section>
|
||||
<section id="controlling-tracking">
|
||||
<h3>Controlling tracking<a class="headerlink" href="#controlling-tracking" title="Permalink to this headline">¶</a></h3>
|
||||
<p>You will notice that some files are not covered by your git version control, notably your settings
|
||||
file (<code class="docutils literal notranslate"><span class="pre">mygame/server/conf/settings.py</span></code>) and your sqlite3 database file <code class="docutils literal notranslate"><span class="pre">mygame/server/evennia.db3</span></code>.
|
||||
This is controlled by the hidden file <code class="docutils literal notranslate"><span class="pre">mygame/.gitignore</span></code>. 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
|
||||
<code class="docutils literal notranslate"><span class="pre">.gitignore</span></code>.</p>
|
||||
<blockquote>
|
||||
<div><p>Note: You should <em>never</em> put your sqlite3 database file into git by removing its entry in
|
||||
<code class="docutils literal notranslate"><span class="pre">.gitignore</span></code>. 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.</p>
|
||||
</div></blockquote>
|
||||
<p>You only need to do this once per file.</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git status
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>will show if you have any modified, added or otherwise changed files. Some
|
||||
files, like database files, logs and temporary PID files are usually <em>not</em>
|
||||
tracked in version control. These should either not show up or have a question
|
||||
mark in front of them.</p>
|
||||
<div class="admonition note">
|
||||
<p class="admonition-title">Note</p>
|
||||
<p>You will notice that some files are not covered by your git version control,
|
||||
notably your settings file (<code class="docutils literal notranslate"><span class="pre">mygame/server/conf/settings.py</span></code>) and your sqlite3
|
||||
database file <code class="docutils literal notranslate"><span class="pre">mygame/server/evennia.db3</span></code>. What is auto-ignored by is controlled
|
||||
by the hidden file <code class="docutils literal notranslate"><span class="pre">mygame/.gitignore</span></code>. 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 <code class="docutils literal notranslate"><span class="pre">.gitignore</span></code>.</p>
|
||||
</div>
|
||||
<div class="admonition warning">
|
||||
<p class="admonition-title">Warning</p>
|
||||
<p>You should <em>never</em> put your sqlite3 database file into git by removing its entry
|
||||
in <code class="docutils literal notranslate"><span class="pre">.gitignore</span></code>. 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.</p>
|
||||
</div>
|
||||
</section>
|
||||
<section id="committing-your-code">
|
||||
<h3>Committing your Code<a class="headerlink" href="#committing-your-code" title="Permalink to this headline">¶</a></h3>
|
||||
<blockquote>
|
||||
<div><p>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.</p>
|
||||
</div></blockquote>
|
||||
<p>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</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">commit</span> <span class="o">--</span><span class="nb">all</span>
|
||||
<p><em>Committing</em> 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.</p>
|
||||
<p>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</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git commit --all
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>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 <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">log</span></code>. If you don’t want to use the editor you can set the message
|
||||
directly by using the <code class="docutils literal notranslate"><span class="pre">-m</span></code> flag:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">commit</span> <span class="o">--</span><span class="nb">all</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"This fixes a bug in the combat code."</span>
|
||||
<p>Also <code class="docutils literal notranslate"><span class="pre">-a</span></code> 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</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git commit -a -m "This fixes a bug in the combat code."
|
||||
</pre></div>
|
||||
</div>
|
||||
</section>
|
||||
<section id="changing-your-mind">
|
||||
<h3>Changing your mind<a class="headerlink" href="#changing-your-mind" title="Permalink to this headline">¶</a></h3>
|
||||
<p>If you have non-committed changes that you realize you want to throw away, you can do the following:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="o"><</span><span class="n">file</span> <span class="n">to</span> <span class="n">revert</span><span class="o">></span>
|
||||
<p>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:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout <file_to_revert>
|
||||
git checkout foo/bar/dummy.py
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>This will revert the file to the state it was in at your last <code class="docutils literal notranslate"><span class="pre">commit</span></code>, 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 <code class="docutils literal notranslate"> <span class="pre">git</span> <span class="pre">checkout</span> <span class="pre">.</span></code> you will throw away <em>all</em> changes since the last commit.</p>
|
||||
<p>If you want to revert <em>all</em> changes you did since last commit, do</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout .
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>(that is, add a single <code class="docutils literal notranslate"><span class="pre">.</span></code> at the end).</p>
|
||||
</section>
|
||||
<section id="pushing-your-code-online">
|
||||
<h3>Pushing your code online<a class="headerlink" href="#pushing-your-code-online" title="Permalink to this headline">¶</a></h3>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
<div class="admonition important">
|
||||
<p class="admonition-title">Important</p>
|
||||
<p>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.</p>
|
||||
</div>
|
||||
<ol class="simple">
|
||||
<li><p>Make sure you have your game directory setup under git version control as described above. Make
|
||||
sure to commit any changes.</p></li>
|
||||
<li><p>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.</p></li>
|
||||
<li><p>Create a new, empty repository on Github. Github explains how
|
||||
<a class="reference external" href="https://help.github.com/articles/create-a-repo/">here</a> (do <em>not</em> “Initialize the repository with a
|
||||
README” or else you’ll create unrelated histories).</p></li>
|
||||
<li><p>From your local game dir, do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">remote</span> <span class="pre">add</span> <span class="pre">origin</span> <span class="pre"><github</span> <span class="pre">URL></span></code> where <code class="docutils literal notranslate"><span class="pre"><github</span> <span class="pre">URL></span></code> is the URL
|
||||
to your online repo. This tells your game dir that it should be pushing to the remote online dir.</p></li>
|
||||
<a class="reference external" href="https://help.github.com/articles/create-a-repo/">here</a> (do <em>not</em> “Initialize
|
||||
the repository with a README” or else you’ll create unrelated histories).</p></li>
|
||||
<li><p>From your local game dir, do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">remote</span> <span class="pre">add</span> <span class="pre">origin</span> <span class="pre"><github</span> <span class="pre">URL></span></code> where
|
||||
<code class="docutils literal notranslate"><span class="pre"><github</span> <span class="pre">URL></span></code> is the URL to your online repo. This tells your game dir that
|
||||
it should be pushing to the remote online dir.</p></li>
|
||||
<li><p><code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">remote</span> <span class="pre">-v</span></code> to verify the online dir.</p></li>
|
||||
<li><p><code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span> <span class="pre">origin</span> <span class="pre">master</span></code> now pushes your game dir online so you can see it on <a class="reference external" href="http://github.com">github.com</a>.</p></li>
|
||||
<li><p><code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span> <span class="pre">origin</span> <span class="pre">master</span></code> (or <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span> <span class="pre">origin</span> <span class="pre">main</span></code>) now pushes your game dir
|
||||
online so you can see it on <a class="reference external" href="http://github.com">github.com</a>.</p></li>
|
||||
</ol>
|
||||
<p>You can commit your work locally (<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">commit</span> <span class="pre">--all</span> <span class="pre">-m</span> <span class="pre">"Make</span> <span class="pre">a</span> <span class="pre">change</span> <span class="pre">that</span> <span class="pre">..."</span></code>) as many times as
|
||||
you want. When you want to push those changes to your online repo, you do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span></code>. You can also
|
||||
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">clone</span> <span class="pre"><url_to_online_repo></span></code> from your online repo to somewhere else (like your production
|
||||
server) and henceforth do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">pull</span></code> to update that to the latest thing you pushed.</p>
|
||||
<p>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.</p>
|
||||
<p>You can commit your work locally (<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">commit</span> <span class="pre">--all</span> <span class="pre">-m</span> <span class="pre">"Make</span> <span class="pre">a</span> <span class="pre">change</span> <span class="pre">that</span> <span class="pre">..."</span></code>) as many times as you want. When you want to push those changes to your
|
||||
online repo, you do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span></code>. You can also <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">clone</span> <span class="pre"><url_to_online_repo></span></code>
|
||||
from your online repo to somewhere else (like your production server) and
|
||||
henceforth do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">pull</span></code> to update that to the latest thing you pushed.</p>
|
||||
<p>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.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="forking-evennia">
|
||||
<h2>Forking Evennia<a class="headerlink" href="#forking-evennia" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This helps you set up an online <em>fork</em> of Evennia so you can easily commit fixes and help with
|
||||
upstream development.</p>
|
||||
<p>This helps you set up an online <em>fork</em> of the main Evennia repository so you can
|
||||
easily commit fixes and help with upstream development. You can do this step
|
||||
also if you <em>didn’t</em> put your game dir under version control like in the
|
||||
previous section - the evennia repo and your game dir repo are completely
|
||||
separate.</p>
|
||||
<section id="step-1-fork-the-evennia-master-repository">
|
||||
<h3>Step 1: Fork the evennia/master repository<a class="headerlink" href="#step-1-fork-the-evennia-master-repository" title="Permalink to this headline">¶</a></h3>
|
||||
<blockquote>
|
||||
<div><p>Before proceeding with the following step, make sure you have registered and created an account on
|
||||
<a class="reference external" href="https://github.com/">GitHub.com</a>. 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
|
||||
<div><p>Before proceeding with the following step, make sure you have registered and
|
||||
created an account on <a class="reference external" href="https://github.com/">GitHub.com</a>. 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.</p>
|
||||
</div></blockquote>
|
||||
<p>A <em>fork</em> is a clone of the master repository that you can make your own commits and changes to. At
|
||||
the top of <a class="reference external" href="https://github.com/evennia/evennia">this page</a>, click the “Fork” button, as it appears
|
||||
below. <img alt="" src="https://github-images.s3.amazonaws.com/help/bootcamp/Bootcamp-Fork.png" /></p>
|
||||
<p>A <em>fork</em> is a clone of the master repository that you can make your own commits
|
||||
and changes to. At the top of <a class="reference external" href="https://github.com/evennia/evennia">this page</a>,
|
||||
click the “Fork” button, as it appears below.
|
||||
<img alt="" src="https://github-images.s3.amazonaws.com/help/bootcamp/Bootcamp-Fork.png" /></p>
|
||||
</section>
|
||||
<section id="step-2-clone-your-fork">
|
||||
<h3>Step 2: Clone your fork<a class="headerlink" href="#step-2-clone-your-fork" title="Permalink to this headline">¶</a></h3>
|
||||
<p>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:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clone</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">yourusername</span><span class="o">/</span><span class="n">evennia</span><span class="o">.</span><span class="n">git</span>
|
||||
<section id="step-2-clone-your-online-fork-of-evennia">
|
||||
<h3>Step 2: Clone your online fork of Evennia<a class="headerlink" href="#step-2-clone-your-online-fork-of-evennia" title="Permalink to this headline">¶</a></h3>
|
||||
<p>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:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git clone https://github.com/yourusername/evennia.git
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>This will download your fork to your computer. It creates a new folder <code class="docutils literal notranslate"><span class="pre">evennia/</span></code> at your current
|
||||
location.</p>
|
||||
<p>This will download your fork to your computer. It creates a new folder
|
||||
<code class="docutils literal notranslate"><span class="pre">evennia/</span></code> at your current location.</p>
|
||||
</section>
|
||||
<section id="step-3-configure-remotes">
|
||||
<h3>Step 3: Configure remotes<a class="headerlink" href="#step-3-configure-remotes" title="Permalink to this headline">¶</a></h3>
|
||||
<p>A <em>remote</em> 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 <code class="docutils literal notranslate"><span class="pre">origin</span></code>. 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”.</p>
|
||||
<p>Below we change the active directory to the newly cloned “evennia” directory and then assign the
|
||||
original Evennia repository to a remote called “upstream”:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">evennia</span>
|
||||
<span class="n">git</span> <span class="n">remote</span> <span class="n">add</span> <span class="n">upstream</span> <span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">evennia</span><span class="o">/</span><span class="n">evennia</span><span class="o">.</span><span class="n">git</span>
|
||||
<p>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.</p>
|
||||
<p>We do this by setting up a new <em>remote</em>. 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 <code class="docutils literal notranslate"><span class="pre">origin</span></code>.</p>
|
||||
<p>We will now create a new remote called <code class="docutils literal notranslate"><span class="pre">upstream</span></code>.</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>cd evennia
|
||||
git remote add upstream https://github.com/evennia/evennia.git
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>If you also want to access Evennia’s <code class="docutils literal notranslate"><span class="pre">develop</span></code> branch (the bleeding edge development branch) do the
|
||||
following:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">fetch</span> <span class="n">upstream</span> <span class="n">develop</span>
|
||||
<span class="n">git</span> <span class="n">checkout</span> <span class="n">develop</span>
|
||||
<p>This adds a remote to the main evennia repo.</p>
|
||||
<p>If you also want to access Evennia’s <code class="docutils literal notranslate"><span class="pre">develop</span></code> branch (the bleeding edge
|
||||
development) do the following:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git fetch upstream develop
|
||||
git checkout develop
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You should now have the upstream branch available locally. You can use this instead of <code class="docutils literal notranslate"><span class="pre">master</span></code>
|
||||
below if you are contributing new features rather than bug fixes.</p>
|
||||
<p>Use
|
||||
git checkout master
|
||||
git checkout develop</p>
|
||||
<p>to switch between the branches. If you want to contribute a fix, ask first which
|
||||
branch to use. Normally <code class="docutils literal notranslate"><span class="pre">master</span></code> is for bug fixes and <code class="docutils literal notranslate"><span class="pre">develop</span></code> is for new
|
||||
features, but late in the development of a new Evennia version, all changes
|
||||
often go into <code class="docutils literal notranslate"><span class="pre">develop</span></code>.</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="working-with-your-fork">
|
||||
<h2>Working with your fork<a class="headerlink" href="#working-with-your-fork" title="Permalink to this headline">¶</a></h2>
|
||||
<blockquote>
|
||||
<div><p>A <em>branch</em> 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.</p>
|
||||
</div></blockquote>
|
||||
<p>The default <em>branch</em> of git is called the “master” branch. As a rule of thumb, you should <em>never</em>
|
||||
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.</p>
|
||||
<section id="making-a-work-branch">
|
||||
<h3>Making a work branch<a class="headerlink" href="#making-a-work-branch" title="Permalink to this headline">¶</a></h3>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="o">-</span><span class="n">b</span> <span class="n">myfixes</span>
|
||||
<section id="working-with-your-evennia-fork">
|
||||
<h2>Working with your Evennia fork<a class="headerlink" href="#working-with-your-evennia-fork" title="Permalink to this headline">¶</a></h2>
|
||||
<p><em>Branches</em> 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.</p>
|
||||
<section id="updating-to-latest-evennia">
|
||||
<h3>Updating to latest Evennia<a class="headerlink" href="#updating-to-latest-evennia" title="Permalink to this headline">¶</a></h3>
|
||||
<p>When Evennia’s official repository updates, first make sure to commit all your
|
||||
changes to your branch and then checkout the “clean” master branch:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout master
|
||||
git pull upstream master
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>This command will checkout and automatically create the new branch <code class="docutils literal notranslate"><span class="pre">myfixes</span></code> on your machine. If you
|
||||
stared out in the master branch, <em>myfixes</em> will be a perfect copy of the master branch. You can see
|
||||
which branch you are on with <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">branch</span></code> and change between different branches with <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">checkout</span> <span class="pre"><branchname></span></code>.</p>
|
||||
<p>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 <em>pull request</em> for that
|
||||
branch to be merged upstream (see below). Not only will this organize your work, it will also make
|
||||
sure that <em>your</em> master branch version of Evennia is always exactly in sync with the upstream
|
||||
version’s master branch.</p>
|
||||
<p>Or, if you are working against Evennia’s development branch:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout develop
|
||||
git pull upstream develop
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">pull</span></code> 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.</p>
|
||||
</section>
|
||||
<section id="updating-with-upstream-changes">
|
||||
<h3>Updating with upstream changes<a class="headerlink" href="#updating-with-upstream-changes" title="Permalink to this headline">¶</a></h3>
|
||||
<p>When Evennia’s official repository updates, first make sure to commit all your changes to your
|
||||
branch and then checkout the “clean” master branch:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">commit</span> <span class="o">--</span><span class="nb">all</span>
|
||||
<span class="n">git</span> <span class="n">checkout</span> <span class="n">master</span>
|
||||
<section id="making-changes">
|
||||
<h3>Making changes<a class="headerlink" href="#making-changes" title="Permalink to this headline">¶</a></h3>
|
||||
<p>As a rule of thumb you should <em>never</em> work directly in Evennia’s <code class="docutils literal notranslate"><span class="pre">master</span></code> or
|
||||
<code class="docutils literal notranslate"><span class="pre">develop</span></code> branches. Instead you make a <em>new</em> branch off the branch you want
|
||||
and change <em>that</em>.</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout master (or develop)
|
||||
check checkout -b strange_bug
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Pull the latest changes from upstream:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">pull</span> <span class="n">upstream</span> <span class="n">master</span>
|
||||
<p>You now have a new branch <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> that is an exact replica of the branch you
|
||||
had checked out when you created it. Here you can now make your own
|
||||
modifications.</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git branches
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>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 <em>merge</em> the updated master into our
|
||||
branch.</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="n">myfixes</span>
|
||||
<span class="n">git</span> <span class="n">merge</span> <span class="n">master</span>
|
||||
<p>will show you which branches are available and which one you are currently
|
||||
using. Use <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">checkout</span> <span class="pre"><branch></span></code> to move between them, but remember to commit
|
||||
your changes before you do.</p>
|
||||
<p>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
|
||||
<code class="docutils literal notranslate"><span class="pre">master</span></code>/<code class="docutils literal notranslate"><span class="pre">develop</span></code> branch and then <em>merge</em> those changes into your work branch.
|
||||
Make sure you have committed everything first!</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>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)
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>If everything went well, your <code class="docutils literal notranslate"><span class="pre">myfixes</span></code> branch will now have the latest version of Evennia merged
|
||||
with whatever changes you have done. Use <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">log</span></code> to see what has changed. You may need to restart
|
||||
the server or run <code class="docutils literal notranslate"><span class="pre">manage.py</span> <span class="pre">migrate</span></code> if the database schema changed (this will be seen in the
|
||||
commit log and on the mailing list). See the <a class="reference external" href="https://git-scm.com/documentation">Git manuals</a> for
|
||||
learning more about useful day-to-day commands, and special situations such as dealing with merge
|
||||
collisions.</p>
|
||||
<p>If everything went well, your <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> branch will now have the latest version
|
||||
of Evennia merged with whatever changes you have done.</p>
|
||||
<p>Now work away on your code and commit with reasonable commit messages</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git commit -a -m "Fixed the issue in ..."
|
||||
git commit -a -m "Adding unit tests. This resolves #123."
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Use</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git diff
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>to see what you changed since last commit, and</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git log
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>to see past commits (including those made by Evennia upstream, remember that
|
||||
your branch is a copy of the upstream one, including its history!)</p>
|
||||
</section>
|
||||
</section>
|
||||
<section id="sharing-your-code-publicly">
|
||||
<h2>Sharing your Code Publicly<a class="headerlink" href="#sharing-your-code-publicly" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Up to this point your <code class="docutils literal notranslate"><span class="pre">myfixes</span></code> 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:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">push</span> <span class="o">-</span><span class="n">u</span> <span class="n">origin</span> <span class="n">myfixes</span>
|
||||
<section id="sharing-your-evennia-fixes-on-github">
|
||||
<h2>Sharing your Evennia fixes on Github<a class="headerlink" href="#sharing-your-evennia-fixes-on-github" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Up to this point your <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> 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:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git push -u origin strange_bug
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>This will create a new <em>remote branch</em> named “myfixes” in your online repository (which is refered
|
||||
to as “origin” by default); the <code class="docutils literal notranslate"><span class="pre">-u</span></code> flag makes sure to set this to the default push location.
|
||||
Henceforth you can just use <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span></code> 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).</p>
|
||||
<p><em>Note: If you hadn’t setup a public key on GitHub or aren’t asked for a username/password, you might
|
||||
get an error <code class="docutils literal notranslate"><span class="pre">403:</span> <span class="pre">Forbidden</span> <span class="pre">Access</span></code> at this stage. In that case, some users have reported that the
|
||||
workaround is to create a file <code class="docutils literal notranslate"><span class="pre">.netrc</span></code> under your home directory and add your credentials there:</em></p>
|
||||
<p>You only need to do this once, the <code class="docutils literal notranslate"><span class="pre">-u</span></code> makes this the default push-location. In
|
||||
the future, you can just push things online like this:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git push
|
||||
</pre></div>
|
||||
</div>
|
||||
<section id="troubleshooting">
|
||||
<h3>Troubleshooting<a class="headerlink" href="#troubleshooting" title="Permalink to this headline">¶</a></h3>
|
||||
<p>If you hadn’t setup a public key on GitHub or aren’t asked for a
|
||||
username/password, you might get an error <code class="docutils literal notranslate"><span class="pre">403:</span> <span class="pre">Forbidden</span> <span class="pre">Access</span></code> at this stage.
|
||||
In that case, some users have reported that the workaround is to create a file
|
||||
<code class="docutils literal notranslate"><span class="pre">.netrc</span></code> under your home directory and add your github credentials there:</p>
|
||||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>machine github.com
|
||||
login <my_github_username>
|
||||
password <my_github_password>
|
||||
</pre></div>
|
||||
</div>
|
||||
</section>
|
||||
<section id="committing-fixes-to-evennia">
|
||||
<h2>Committing fixes to Evennia<a class="headerlink" href="#committing-fixes-to-evennia" title="Permalink to this headline">¶</a></h2>
|
||||
<p><em>Contributing</em> 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 <a class="reference external" href="https://github.com/evennia/evennia/issues">Issue
|
||||
Tracker</a>, 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.</p>
|
||||
<p>To contribute you need to have <a class="reference internal" href="#forking-evennia"><span class="std std-doc">forked Evennia</span></a> 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 <em>Pull request</em>, PR, see below). We can then merge your
|
||||
change into the upstream master and you then do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">pull</span></code> 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.</p>
|
||||
<p>First update the Evennia master branch to the latest Evennia version:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="n">master</span>
|
||||
<span class="n">git</span> <span class="n">pull</span> <span class="n">upstream</span> <span class="n">master</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Next, create a new branch to hold your contribution. Let’s call it the “fixing_strange_bug” branch:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">checkout</span> <span class="o">-</span><span class="n">b</span> <span class="n">fixing_strange_bug</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>It is wise to make separate branches for every fix or series of fixes you want to contribute. You
|
||||
are now in your new <code class="docutils literal notranslate"><span class="pre">fixing_strange_bug</span></code> branch. You can list all branches with <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">branch</span></code> and
|
||||
jump between branches with <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">checkout</span> <span class="pre"><branchname></span></code>. Code and test things in here, committing as
|
||||
you go:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">commit</span> <span class="o">--</span><span class="nb">all</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Fix strange bug in look command. Resolves #123."</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>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 <code class="docutils literal notranslate"><span class="pre">#123</span></code>, 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.</p>
|
||||
</section>
|
||||
<section id="making-an-evennia-pull-request">
|
||||
<h2>Making an Evennia Pull Request<a class="headerlink" href="#making-an-evennia-pull-request" title="Permalink to this headline">¶</a></h2>
|
||||
<p>If you think that the fixes you did in your <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> branch should be a
|
||||
part of the regular Evennia, you should create a <em>Pull Request</em> (PR). This is a
|
||||
call for the Evennia maintainer to pull your change into an upstream branch.</p>
|
||||
<blockquote>
|
||||
<div><p>If you refer to in-game commands that start with <code class="docutils literal notranslate"><span class="pre">@</span></code>(such as <code class="docutils literal notranslate"><span class="pre">@examine</span></code>), please put them in
|
||||
backticks `, for example `@examine`. The reason for this is that GitHub uses <code class="docutils literal notranslate"><span class="pre">@username</span></code> to refer
|
||||
to GitHub users, so if you forget the ticks, any user happening to be named <code class="docutils literal notranslate"><span class="pre">examine</span></code> will get a
|
||||
notification …</p>
|
||||
<div><p>It is wise to make separate branches for every fix or series of fixes you want
|
||||
to contribute.</p>
|
||||
</div></blockquote>
|
||||
<p>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 <a class="reference external" href="https://www.git-scm.com/book/en/v2/Git-Branching-Rebasing">git
|
||||
rebase</a> (this is not always necessary,
|
||||
and if it sounds too hard, say so and we’ll handle it on our end).</p>
|
||||
<p>Once you are ready, push your work to your online Evennia fork on github, in a new remote branch:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">push</span> <span class="o">-</span><span class="n">u</span> <span class="n">origin</span> <span class="n">fixing_strange_bug</span>
|
||||
<p>Assuming you have followed the instructions above and have pushed your changes
|
||||
online, <a class="reference external" href="https://github.com/evennia/evennia/pulls">create a pull request</a> and
|
||||
follow the instructions. Make sure to specifically select your <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code>
|
||||
branch to be the source of the merge and use the branch you based that branch
|
||||
off (<code class="docutils literal notranslate"><span class="pre">master</span></code> or <code class="docutils literal notranslate"><span class="pre">develop</span></code>) as the target.</p>
|
||||
<p>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.</p>
|
||||
<p>Once approved and merged, your change will now be available in the upstream
|
||||
branch:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git checkout master (or develope)
|
||||
git pull upstream master (or develop)
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The <code class="docutils literal notranslate"><span class="pre">-u</span></code> 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 <code class="docutils literal notranslate"><span class="pre">fixing_strange_bug</span></code> branch and do
|
||||
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">push</span></code>.</p>
|
||||
<p>Now you should tell the Evennia developers that they should consider merging your brilliant changes
|
||||
into Evennia proper. <a class="reference external" href="https://github.com/evennia/evennia/pulls">Create a pull request</a> and follow
|
||||
the instructions. Make sure to specifically select your <code class="docutils literal notranslate"><span class="pre">fixing_strange_bug</span></code> 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.</p>
|
||||
<p>Once your changes have been merged into Evennia your local <code class="docutils literal notranslate"><span class="pre">fixing_strange_bug</span></code> can be deleted
|
||||
(since your changes are now available in the “clean” Evennia repository). Do</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">branch</span> <span class="o">-</span><span class="n">D</span> <span class="n">fixing_strange_bug</span>
|
||||
<p>Since your changes are now in upstream, your local <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> branch is now
|
||||
superfluous and should be deleted:</p>
|
||||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git branch -D strange_bug
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>to delete your work branch. Update your master branch (<code class="docutils literal notranslate"><span class="pre">checkout</span> <span class="pre">master</span></code> and then <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">pull</span></code>) and
|
||||
you should get your fix back, now as a part of official Evennia!</p>
|
||||
<p>You can also safely delete your online <code class="docutils literal notranslate"><span class="pre">strange_bug</span></code> branch in your fork
|
||||
(you can do this from the PR page on github).</p>
|
||||
</section>
|
||||
<section id="git-tips-and-tricks">
|
||||
<h2>GIT tips and tricks<a class="headerlink" href="#git-tips-and-tricks" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Some of the GIT commands can feel a little long and clunky if you need to do them often. Luckily you
|
||||
can create aliases for those. Here are some useful commands to run:</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git st </span>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git st</span>
|
||||
<span class="c1"># - view brief status info</span>
|
||||
<span class="n">git</span> <span class="n">config</span> <span class="o">--</span><span class="k">global</span> <span class="n">alias</span><span class="o">.</span><span class="n">st</span> <span class="s1">'status -s'</span>
|
||||
</pre></div>
|
||||
|
|
@ -414,12 +440,12 @@ can create aliases for those. Here are some useful commands to run:</p>
|
|||
<p>Above, you only need to ever enter the <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">config</span> <span class="pre">...</span></code> command once - you have then added the new
|
||||
alias. Afterwards, just do <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">st</span></code> to get status info. All the examples below follow the same
|
||||
template.</p>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git cl </span>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git cl</span>
|
||||
<span class="c1"># - clone a repository</span>
|
||||
<span class="n">git</span> <span class="n">config</span> <span class="o">--</span><span class="k">global</span> <span class="n">alias</span><span class="o">.</span><span class="n">cl</span> <span class="n">clone</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git cma "commit message" </span>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git cma "commit message"</span>
|
||||
<span class="c1"># - commit all changes without opening editor for message</span>
|
||||
<span class="n">git</span> <span class="n">config</span> <span class="o">--</span><span class="k">global</span> <span class="n">alias</span><span class="o">.</span><span class="n">cma</span> <span class="s1">'commit -a -m'</span>
|
||||
</pre></div>
|
||||
|
|
@ -435,7 +461,7 @@ template.</p>
|
|||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># git co [branchname]</span>
|
||||
<span class="c1"># - checkout </span>
|
||||
<span class="c1"># - checkout</span>
|
||||
<span class="n">git</span> <span class="n">config</span> <span class="o">--</span><span class="k">global</span> <span class="n">alias</span><span class="o">.</span><span class="n">co</span> <span class="n">checkout</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
|
|
@ -460,9 +486,7 @@ template.</p>
|
|||
<span class="n">git</span> <span class="n">config</span> <span class="o">--</span><span class="k">global</span> <span class="n">alias</span><span class="o">.</span><span class="n">grep</span> <span class="s1">'grep -Ii'</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>To get a further feel for GIT there is also <a class="reference external" href="https://www.youtube.com/watch?v=1ffBJ4sVUb4#t=1m58s">a good YouTube talk about
|
||||
it</a> - it’s a bit long but it will help you
|
||||
understand the underlying ideas behind GIT
|
||||
<p>To get a further feel for GIT there is also <a class="reference external" href="https://www.youtube.com/watch?v=1ffBJ4sVUb4#t=1m58s">a good YouTube talk about it</a> - 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).</p>
|
||||
</section>
|
||||
</section>
|
||||
|
|
@ -497,7 +521,6 @@ understand the underlying ideas behind GIT
|
|||
</li>
|
||||
<li><a class="reference internal" href="#putting-your-game-folder-under-version-control">Putting your game folder under version control</a><ul>
|
||||
<li><a class="reference internal" href="#tracking-files">Tracking files</a></li>
|
||||
<li><a class="reference internal" href="#controlling-tracking">Controlling tracking</a></li>
|
||||
<li><a class="reference internal" href="#committing-your-code">Committing your Code</a></li>
|
||||
<li><a class="reference internal" href="#changing-your-mind">Changing your mind</a></li>
|
||||
<li><a class="reference internal" href="#pushing-your-code-online">Pushing your code online</a></li>
|
||||
|
|
@ -505,17 +528,20 @@ understand the underlying ideas behind GIT
|
|||
</li>
|
||||
<li><a class="reference internal" href="#forking-evennia">Forking Evennia</a><ul>
|
||||
<li><a class="reference internal" href="#step-1-fork-the-evennia-master-repository">Step 1: Fork the evennia/master repository</a></li>
|
||||
<li><a class="reference internal" href="#step-2-clone-your-fork">Step 2: Clone your fork</a></li>
|
||||
<li><a class="reference internal" href="#step-2-clone-your-online-fork-of-evennia">Step 2: Clone your online fork of Evennia</a></li>
|
||||
<li><a class="reference internal" href="#step-3-configure-remotes">Step 3: Configure remotes</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#working-with-your-fork">Working with your fork</a><ul>
|
||||
<li><a class="reference internal" href="#making-a-work-branch">Making a work branch</a></li>
|
||||
<li><a class="reference internal" href="#updating-with-upstream-changes">Updating with upstream changes</a></li>
|
||||
<li><a class="reference internal" href="#working-with-your-evennia-fork">Working with your Evennia fork</a><ul>
|
||||
<li><a class="reference internal" href="#updating-to-latest-evennia">Updating to latest Evennia</a></li>
|
||||
<li><a class="reference internal" href="#making-changes">Making changes</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#sharing-your-code-publicly">Sharing your Code Publicly</a></li>
|
||||
<li><a class="reference internal" href="#committing-fixes-to-evennia">Committing fixes to Evennia</a></li>
|
||||
<li><a class="reference internal" href="#sharing-your-evennia-fixes-on-github">Sharing your Evennia fixes on Github</a><ul>
|
||||
<li><a class="reference internal" href="#troubleshooting">Troubleshooting</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#making-an-evennia-pull-request">Making an Evennia Pull Request</a></li>
|
||||
<li><a class="reference internal" href="#git-tips-and-tricks">GIT tips and tricks</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue