<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.wesnoth.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=8680</id>
	<title>The Battle for Wesnoth Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.wesnoth.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=8680"/>
	<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/Special:Contributions/8680"/>
	<updated>2026-04-06T00:50:36Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.31.16</generator>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56636</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56636"/>
		<updated>2015-08-02T19:14:31Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Browse the code */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;dfn&amp;gt;Git&amp;lt;/dfn&amp;gt; is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt;, the official Git command-line program is &amp;lt;em&amp;gt;by far&amp;lt;/em&amp;gt; the easiest Git program to get help with -- you may well have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56635</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56635"/>
		<updated>2015-08-02T19:12:37Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Browse the code */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;dfn&amp;gt;Git&amp;lt;/dfn&amp;gt; is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt;, the official Git command-line program is &amp;lt;em&amp;gt;by far&amp;lt;/em&amp;gt; the easiest Git program to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56625</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56625"/>
		<updated>2015-07-31T20:53:14Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;dfn&amp;gt;Git&amp;lt;/dfn&amp;gt; is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56624</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56624"/>
		<updated>2015-07-31T20:52:15Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's '''&amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt;''' to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;dfn&amp;gt;Git&amp;lt;/dfn&amp;gt; is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=DevelopersHome&amp;diff=56623</id>
		<title>DevelopersHome</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=DevelopersHome&amp;diff=56623"/>
		<updated>2015-07-30T21:50:35Z</updated>

		<summary type="html">&lt;p&gt;8680: /* General Information */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= General Information =&lt;br /&gt;
* Links&lt;br /&gt;
** [http://changelog.wesnoth.org Changelog] - the most recent changes made to the game&lt;br /&gt;
** [https://github.com/wesnoth/wesnoth/commits/master Latest commits] - Up-to-date commit messages&lt;br /&gt;
&lt;br /&gt;
* Coding Guidelines&lt;br /&gt;
** [[Git_for_Wesnoth_Crash_Course]] - guide for contributors who are new to git&lt;br /&gt;
** [[HackingWesnoth]] - guide for programmers&lt;br /&gt;
** [[CodingStandards]] - for programmers&lt;br /&gt;
** [[DeveloperGuide]] - for those who received repository commit rights&lt;br /&gt;
** [[SoftwareTesting]] - for programmers&lt;br /&gt;
&lt;br /&gt;
* Library documentation&lt;br /&gt;
** [http://cppreference.com C++ Reference]&lt;br /&gt;
** [http://www.boost.org/doc/ Boost documentation]&lt;br /&gt;
&lt;br /&gt;
* Debugging Tips&lt;br /&gt;
** [[DebuggingWesnoth]]&lt;br /&gt;
&lt;br /&gt;
= Tools and Packaging =&lt;br /&gt;
* Supporting Websites&lt;br /&gt;
** [[WesnothRepository]] - accessing the source code&lt;br /&gt;
** http://gettext.wesnoth.org/ - gettext status&lt;br /&gt;
* Compiling and Building&lt;br /&gt;
** [[CompilingWesnoth]] - how to compile Battle for Wesnoth (it's not hard)&lt;br /&gt;
** [[SCons]]&lt;br /&gt;
* Packaging and Releasing&lt;br /&gt;
** [[ReleasingWesnoth]] - steps to follow to release a new version&lt;br /&gt;
* Documentation&lt;br /&gt;
** [[Doxygen]] - Documentation generator&lt;br /&gt;
* More stuff&lt;br /&gt;
** [[ExternalUtilities]] (Wercator, CampGen, wmllint, etc.)&lt;br /&gt;
** [[MaintenanceTools]] WMLLint, WMLIndent and WMLScope&lt;br /&gt;
** [[UsingGooglePerformanceTools]] to profile Wesnoth CPU and memory usage.&lt;br /&gt;
&lt;br /&gt;
= I want to start coding, what can I do? =&lt;br /&gt;
* [[EasyCoding]] - Bugs and features that are easy to implement for new coders&lt;br /&gt;
* [[NotSoEasyCoding]] - Bugs and features which are doable but lacking someone working on them&lt;br /&gt;
* [[GettingStarted]]&lt;br /&gt;
* [[FrequentlyProposedIdeas]] - summary of past often-repeated forum discussions&lt;br /&gt;
* [[Glossary]]&lt;br /&gt;
&lt;br /&gt;
= Game - Create content =&lt;br /&gt;
* [[BuildingScenarios]] and related useful forum discussions: &lt;br /&gt;
** [http://www.wesnoth.org/forum/viewtopic.php?t=4188 Beginning Campaign Development]&lt;br /&gt;
** [http://www.wesnoth.org/forum/viewtopic.php?t=4301 A Balancing Act]&lt;br /&gt;
* [[ReferenceWML]]&lt;br /&gt;
&lt;br /&gt;
= Code documentation =&lt;br /&gt;
* http://devdocs.wesnoth.org - generated code documentation&lt;br /&gt;
* AI&lt;br /&gt;
** [[AI_Module]] - guide to AI module (src/ai)&lt;br /&gt;
** [[FormulaAI]] - Guide to the experimental formula AI branch&lt;br /&gt;
* Themes&lt;br /&gt;
** [[ThemeSystem]] - customizing the screen layout for the game and the editor&lt;br /&gt;
* Multiplayer&lt;br /&gt;
** [[WesnothdDesign]] - Guide to the design of wesnothd, the multiplayer server.&lt;br /&gt;
* Gui2 - The new Gui-Framework&lt;br /&gt;
** [[GUIToolkit]]&lt;br /&gt;
** [[GUILayout]]&lt;br /&gt;
** [[GUIVariable]]&lt;br /&gt;
** Gui2 WML&lt;br /&gt;
*** [[GUICanvasWML]]&lt;br /&gt;
*** [[GUIToolkitWML]]&lt;br /&gt;
*** [[GUIWidgetDefinitionWML]]&lt;br /&gt;
*** [[GUIWidgetInstanceWML]]&lt;br /&gt;
*** [[GUIWindowDefinitionWML]]&lt;br /&gt;
* Savegames&lt;br /&gt;
** [[SavegameClassHierarchy]]&lt;br /&gt;
&lt;br /&gt;
= Communication, Feedback, Events =&lt;br /&gt;
* Gna! links&lt;br /&gt;
** http://bugs.wesnoth.org/ - Gna! - bugs and feature requests&lt;br /&gt;
** http://patches.wesnoth.org/ - Gna! - patches&lt;br /&gt;
&lt;br /&gt;
* Mailing lists&lt;br /&gt;
** https://mail.gna.org/listinfo/wesnoth-dev/ - wesnoth-dev&lt;br /&gt;
** https://mail.gna.org/listinfo/wesnoth-commits/ - wesnoth-commits&lt;br /&gt;
&lt;br /&gt;
* IRC&lt;br /&gt;
** [irc://irc.wesnoth.org/#wesnoth-dev freenode/#wesnoth-dev] - IRC (alias to irc.freenode.net)&lt;br /&gt;
** http://irclog.wesnoth.org/ - IRC logs&lt;br /&gt;
&lt;br /&gt;
* Forum - http://forum.wesnoth.org&lt;br /&gt;
&lt;br /&gt;
* This wiki - http://www.wesnoth.org/wiki/Main_Page &lt;br /&gt;
&lt;br /&gt;
* FOSDEM&lt;br /&gt;
** [[Fosdem2008]]&lt;br /&gt;
** [[Fosdem2009]]&lt;br /&gt;
** [[Fosdem2010]]&lt;br /&gt;
** [[Fosdem2011]]&lt;br /&gt;
** [[Fosdem2012]]&lt;br /&gt;
&lt;br /&gt;
* Google Summer of Code&lt;br /&gt;
** [[SummerOfCodeIdeas]] - Ideas for GSoC&lt;br /&gt;
** [[SoC_Information_for_Google]] - Our organization profile for Google&lt;br /&gt;
** [[SoC_People_to_bug_on_IRC]] - Who GSoC students can ask for help&lt;br /&gt;
&lt;br /&gt;
= Miscellaneous =&lt;br /&gt;
* [[DebugMode]] and [[CommandMode]] - in game debugging commands&lt;br /&gt;
* [http://www.wesnoth.org/units/trunk/animations.html Missing unit animations] - what's available and what's missing&lt;br /&gt;
* http://units.wesnoth.org/ - Unit reference&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=DeveloperGuide&amp;diff=56622</id>
		<title>DeveloperGuide</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=DeveloperGuide&amp;diff=56622"/>
		<updated>2015-07-30T21:47:33Z</updated>

		<summary type="html">&lt;p&gt;8680: /* General */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes guidelines developers with push access to the Wesnoth repository should follow. Most items apply to prospective contributors as well, in addition to the [[PatchSubmissionGuidelines|patch submission guidelines]].&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
== General ==&lt;br /&gt;
&lt;br /&gt;
{{NewDevsGoHereSidebox}}&lt;br /&gt;
&lt;br /&gt;
* [[WesnothRepository#Push_access|Set up developer access to the repository]], if applicable.&lt;br /&gt;
* Subscribe to the [https://mail.gna.org/listinfo/wesnoth-dev wesnoth-dev mailing list], wherein major announcements are made and project-changing discussions take place.&lt;br /&gt;
* Participate in the #wesnoth-dev IRC channel on irc.freenode.net to coordinate with other developers. Bots report commits and regression testing status, and other developers may ask you questions or provide feedback.&lt;br /&gt;
&lt;br /&gt;
== Commits ==&lt;br /&gt;
&lt;br /&gt;
* Any given branch should &amp;lt;b&amp;gt;compile without warnings&amp;lt;/b&amp;gt; and run after every commit -- we use [https://travis-ci.org/wesnoth/wesnoth Travis CI], which will report any build failures on master and maintenance branches (1.12, 1.14, etc.) to the #wesnoth-dev IRC channel.&lt;br /&gt;
* All &amp;lt;b&amp;gt;unit tests&amp;lt;/b&amp;gt; should pass after commit -- Travis will also test this. To run the C++ unit tests on your own machine, compile the &amp;quot;test&amp;quot; executable and run it. To run the WML unit tests, run &amp;lt;code&amp;gt;run_wml_tests -u&amp;lt;/code&amp;gt; in the checkout root. If a test times out spuriously on Travis, you can restart the build by &lt;br /&gt;
*# Clicking on the link posted to IRC by the Travis bot:&lt;br /&gt;
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has joined #wesnoth-dev&lt;br /&gt;
*#: 20141009 20:40:27&amp;lt; travis-ci&amp;gt; wesnoth/wesnoth#4154 (master - c91604a : Ignacio R. Morelle): The build was broken.&lt;br /&gt;
*#: 20141009 20:40:27&amp;lt; travis-ci&amp;gt; Build details : http://travis-ci.org/wesnoth/wesnoth/builds/37536345&lt;br /&gt;
*#: 20141009 20:40:27-!- travis-ci [~travis-ci@ec2-184-73-55-78.compute-1.amazonaws.com] has left #wesnoth-dev []&lt;br /&gt;
*# Clicking on the [http://i.imgur.com/mxwVKJP.png restart button] on the Travis website.&lt;br /&gt;
* Do &amp;lt;b&amp;gt;not&amp;lt;/b&amp;gt; disable or ignore unit tests without a very good reason!&lt;br /&gt;
* A few small commits are better than a single large commit (which is hard to review), so when possible split it in working parts with info about where you are going&lt;br /&gt;
* &amp;lt;b&amp;gt;Always&amp;lt;/b&amp;gt; review your changes, both before committing locally and before pushing upstream (see [[WesnothRepository#Reviewing your changes]]).&lt;br /&gt;
* &amp;lt;b&amp;gt;Never&amp;lt;/b&amp;gt; use the &amp;quot;force&amp;quot; option when pushing to the upstream Wesnoth repositories (see [[WesnothRepository#Force-pushing_policy]]).&lt;br /&gt;
&lt;br /&gt;
=== Changelogs and release notes ===&lt;br /&gt;
&lt;br /&gt;
We provide two separate changelogs at the root of the Wesnoth distribution and Git checkouts. The &amp;lt;b&amp;gt;players_changelog&amp;lt;/b&amp;gt; file only contains entries for changes deemed relevant for players (not content creators), while the main &amp;lt;b&amp;gt;changelog&amp;lt;/b&amp;gt; contains all changes, except for those that are only relevant to mainline developers and which are not expected to impact players or creators in any way.&lt;br /&gt;
&lt;br /&gt;
It is your responsibility to update both changelogs as you see fit for every commit. For large changes spread over long series of commits, you will probably prefer to commit your changelog additions in a separate last commit to avoid or mitigate conflicts when merging upstream.&lt;br /&gt;
&lt;br /&gt;
Important changes that might be expected to inconvenience or confuse players (including those building from source) or content creators, major bug fixes, and noteworthy feature additions for a future release should be mentioned and explained in &amp;lt;b&amp;gt;RELEASE_NOTES&amp;lt;/b&amp;gt; as well, so that the release team can include this information in official announcements. See the contents of the file for instructions.&lt;br /&gt;
&lt;br /&gt;
=== Commit messages ===&lt;br /&gt;
&lt;br /&gt;
A good commit should not only contain good changes, but also include a helpful description of them for other developers, people tracking regressions, project maintainers, and even yourself in the future. There are many style guides on the Web describing best practices for documenting your Git commits.&lt;br /&gt;
&lt;br /&gt;
For Wesnoth in particular, the general consensus is that contributors should adhere to the following rules:&lt;br /&gt;
&lt;br /&gt;
* Every commit message should begin with a self-contained &amp;lt;b&amp;gt;summary/subject line&amp;lt;/b&amp;gt; no more than 72 characters long. This is the first (and often the only) line someone using browsing tools will see.&lt;br /&gt;
* If your message needs more than a leading summary line, separate it from the rest with a blank line.&lt;br /&gt;
* Subsequent lines should also be no more than 72 characters long. Use blank lines to separate paragraphs and list items.&lt;br /&gt;
* When working on a mainline campaign/scenario, start the commit message with its acronym. For example &amp;lt;code&amp;gt;HttT: &amp;lt;/code&amp;gt; when working on HttT in general and &amp;lt;code&amp;gt;HttT S3: &amp;lt;/code&amp;gt; if the commit only applies to the third scenario of HttT (see below).&lt;br /&gt;
* Likewise, if you work on the code of a specific component, you may want to use it as a prefix. That is e.g., &amp;lt;code&amp;gt;gui2: &amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;wesnothd: &amp;lt;/code&amp;gt;.&lt;br /&gt;
* If you are performing branch merges, Git may include a list of conflicted paths in the commit message template. Edit this out; it ceases to be interesting after the conflicts have been resolved.&lt;br /&gt;
* If you need to mention commit SHA1 hashes (e.g. in revert messages), make sure to use hashes from the upstream repository that are unlikely to change due to a future local or remote merge or rebase operation.&lt;br /&gt;
&lt;br /&gt;
There are a few additional points to keep in mind for the wording of the contents:&lt;br /&gt;
&lt;br /&gt;
* Include &amp;quot;bug #1234&amp;quot; somewhere in your commit message if it addresses a bug or feature request from the Wesnoth bug tracker.&lt;br /&gt;
* Use the project's [[Glossary#Wesnothian_Acronyms|standard abbreviations]] for campaigns and gameplay concepts, like HttT for &amp;lt;cite&amp;gt;Heir to the Throne&amp;lt;/cite&amp;gt;, ZoC for &amp;quot;Zone of Control&amp;quot;, etc. If referring to a particular campaign or scenario in your commit subject, you should use this convention: &amp;quot;HttT S1: Made Galdrad less suicidal&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== Dependencies ==&lt;br /&gt;
* Any changes to Wesnoth's build and run-time dependencies must be discussed on the developers mailing list first.&lt;br /&gt;
* Update the CMake and SCons recipes accordingly.&lt;br /&gt;
* Changes must be mentioned in the RELEASE_NOTES file, so they can be included in the forum announcement for the next release, and in the emails to packagers.&lt;br /&gt;
&lt;br /&gt;
== Bugs management ==&lt;br /&gt;
* Change Status field of fixed bugs to &amp;quot;Fixed&amp;quot; after pushing upstream&lt;br /&gt;
* Change Open/Closed field of fixed bugs to &amp;quot;Closed&amp;quot; after a release including the relevant commits has been published. See [[ReportingBugs#Bug_protocol]] for details.&lt;br /&gt;
* Check regularly if there are new bugs relevant to your code and, if any, assign them to you.&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[WesnothRepository]]&lt;br /&gt;
* [[PatchSubmissionGuidelines]]&lt;br /&gt;
* [[SoftwareTesting]]&lt;br /&gt;
* [[Project]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=PatchSubmissionGuidelines&amp;diff=56621</id>
		<title>PatchSubmissionGuidelines</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=PatchSubmissionGuidelines&amp;diff=56621"/>
		<updated>2015-07-30T21:46:19Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Technical requirements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Submitting a patch for a large and mature project like Wesnoth can be an even more daunting task than writing the code it delivers.'''&lt;br /&gt;
&lt;br /&gt;
This page provides some '''advice and requirements for prospective code contributors''' seeking the best chance of acceptance for their patches.&lt;br /&gt;
&lt;br /&gt;
== Technical requirements ==&lt;br /&gt;
&lt;br /&gt;
{{NewDevsGoHereSidebox}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;All patches should be submitted as GitHub pull requests&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;You may post them in the [http://forums.wesnoth.org/viewtopic.php?f=10 Coder's Corner] forum for discussion too, but we need to '''track their status''', and GitHub is better suited for that. '''See the &amp;lt;cite&amp;gt;[[WesnothRepository]]&amp;lt;/cite&amp;gt; page for help with Git and GitHub.'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Your commits should follow our existing commit contents and message conventions&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;This is explained in greater detail in the '''[[DeveloperGuide#Commits|&amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; section]]''' about commits and commit formatting.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Add entries to the changelogs summarizing your changes, if necessary&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The '''&amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;''' file contains a list of outstanding changes that is published with every release. If you are fixing a bug or adding a feature that is '''particularly visible or important for players''', you should also add an entry to the '''&amp;lt;code&amp;gt;players_changelog&amp;lt;/code&amp;gt;''' file. See the relevant '''[[DeveloperGuide#Changelogs_and_release_notes|&amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; section]]''' as well.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;When adding new C++ source code files, make sure to update the most commonly used project files&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The development team primarily uses '''CMake''' and '''SCons'''. The relevant files are '''&amp;lt;code&amp;gt;src/CMakeLists.txt&amp;lt;/code&amp;gt;''' and '''&amp;lt;code&amp;gt;src/SConscript&amp;lt;/code&amp;gt;'''. You might look at how existing source code files are handled in each build script to get an idea of the best way to add your own.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Please consider updating the '''other build environments''' under '''&amp;lt;code&amp;gt;projectfiles/&amp;lt;/code&amp;gt;''', e.g. Visual C++, as well.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;C++ source code patches must not generate new warnings&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Wesnoth has a large number of '''compiler warnings''' enabled, and all of them are useful. If your code causes '''new warnings''' during build, you will be required to fix them.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Add yourself to the game credits&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;'''Including your name and/or username(s)''' makes it easier for the development team and the community at large to recognize your contributions. '''New contributors''' (i.e., those without commit access) should add themselves to the ''Miscellaneous Contributors'' section of the credits file ('''&amp;lt;code&amp;gt;data/core/about.cfg&amp;lt;/code&amp;gt;'''), making sure to follow alphabetical order with respect to the first character that will be displayed.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;When changing or adding WML features, provide directions for updating the wiki along with your submission in the tracker&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;This allows us to provide content creators with '''up-to-date information about WML features''', even if you cannot be around in time for the commit or the next release.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== After submission ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Be patient, sometimes we are not very responsive&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The Wesnoth developers live on different locations across the globe and have other matters to attend to, most of the time. It may happen that your patch is assigned to a developer who is currently unable to dedicate much time to reviewing it. '''If you feel that it takes much too long for us to respond, contact us in #wesnoth-dev on irc.freenode.net.'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Don't be surprised if we discuss the patch a lot&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Thus, you should '''leave us a way to contact you''', by noting your forums username or email address. We recommend that you join the '''&amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;''' channel on '''&amp;lt;code&amp;gt;irc.freenode.net&amp;lt;/code&amp;gt;''' regularly so we can contact you in real time if needed.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Sometimes patches are rejected, please don't be surprised or offended if this happens&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;If your patch introduces '''new errors or bugs''', if the feature you implemented '''isn't considered an improvement''', or if '''we couldn't contact you''' with our questions and recommendations, the pull request will be denied. &amp;lt;strong&amp;gt;This can usually be averted&amp;lt;/strong&amp;gt; if you discuss your idea on #wesnoth-dev, where the developers will point out these issues. If your pull request is denied, &amp;lt;strong&amp;gt;don't let that discourage you&amp;lt;/strong&amp;gt;, though!&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Obtaining help ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If you encounter any issues or need additional guidance when preparing your patch...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...the easiest way is to ask the developers on the aforementioned IRC channel, '''&amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;'''. You can join &amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt; in your Web browser via this link: {{FeaturedURL|https://webchat.freenode.net/?channels{{=}}wesnoth-dev}}&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If you know who is responsible for the code that your patch changes...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...please prefix their IRC nick in front of your question -- else your message could be overlooked.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If your patch has a major impact on Wesnoth...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...the developer mailing list might be more appropriate, because all subscribed developers will be notified: {{FeaturedURL|https://gna.org/mail/?group{{=}}wesnoth}}&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
&lt;br /&gt;
* [[WesnothRepository]]&lt;br /&gt;
* [[DeveloperGuide]]&lt;br /&gt;
* [[HackingWesnoth]]&lt;br /&gt;
* [[CodingStandards]]&lt;br /&gt;
* [[EasyCoding]]&lt;br /&gt;
* [[DeveloperResources]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:NewDevsGoHereSidebox&amp;diff=56620</id>
		<title>Template:NewDevsGoHereSidebox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:NewDevsGoHereSidebox&amp;diff=56620"/>
		<updated>2015-07-30T21:46:05Z</updated>

		<summary type="html">&lt;p&gt;8680: Created page with &amp;quot;{{SideBox|heading=Are you a newcomer to Git or GitHub, or to the &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; project?|headingtag=b|If so, please see &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt;.}}&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{SideBox|heading=Are you a newcomer to Git or GitHub, or to the &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; project?|headingtag=b|If so, please see &amp;lt;cite&amp;gt;[[WesnothRepository]]&amp;lt;/cite&amp;gt;.}}&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56619</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56619"/>
		<updated>2015-07-30T21:41:05Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;{{{headingtag|h{{{headinglvl|6}}}}}} style=&amp;quot;font-size: 1.03125rem; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/{{{headingtag|h{{{headinglvl|6}}}}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=PatchSubmissionGuidelines&amp;diff=56618</id>
		<title>PatchSubmissionGuidelines</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=PatchSubmissionGuidelines&amp;diff=56618"/>
		<updated>2015-07-30T21:37:50Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Submitting a patch for a large and mature project like Wesnoth can be an even more daunting task than writing the code it delivers.'''&lt;br /&gt;
&lt;br /&gt;
This page provides some '''advice and requirements for prospective code contributors''' seeking the best chance of acceptance for their patches.&lt;br /&gt;
&lt;br /&gt;
== Technical requirements ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|'''Are you a newcomer to Git or GitHub, or to the &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; project?''' If so, please see &amp;lt;cite&amp;gt;[[WesnothRepository]]&amp;lt;/cite&amp;gt;.}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;All patches should be submitted as GitHub pull requests&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;You may post them in the [http://forums.wesnoth.org/viewtopic.php?f=10 Coder's Corner] forum for discussion too, but we need to '''track their status''', and GitHub is better suited for that. '''See the &amp;lt;cite&amp;gt;[[WesnothRepository]]&amp;lt;/cite&amp;gt; page for help with Git and GitHub.'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Your commits should follow our existing commit contents and message conventions&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;This is explained in greater detail in the '''[[DeveloperGuide#Commits|&amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; section]]''' about commits and commit formatting.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Add entries to the changelogs summarizing your changes, if necessary&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The '''&amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;''' file contains a list of outstanding changes that is published with every release. If you are fixing a bug or adding a feature that is '''particularly visible or important for players''', you should also add an entry to the '''&amp;lt;code&amp;gt;players_changelog&amp;lt;/code&amp;gt;''' file. See the relevant '''[[DeveloperGuide#Changelogs_and_release_notes|&amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; section]]''' as well.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;When adding new C++ source code files, make sure to update the most commonly used project files&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The development team primarily uses '''CMake''' and '''SCons'''. The relevant files are '''&amp;lt;code&amp;gt;src/CMakeLists.txt&amp;lt;/code&amp;gt;''' and '''&amp;lt;code&amp;gt;src/SConscript&amp;lt;/code&amp;gt;'''. You might look at how existing source code files are handled in each build script to get an idea of the best way to add your own.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Please consider updating the '''other build environments''' under '''&amp;lt;code&amp;gt;projectfiles/&amp;lt;/code&amp;gt;''', e.g. Visual C++, as well.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;C++ source code patches must not generate new warnings&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Wesnoth has a large number of '''compiler warnings''' enabled, and all of them are useful. If your code causes '''new warnings''' during build, you will be required to fix them.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Add yourself to the game credits&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;'''Including your name and/or username(s)''' makes it easier for the development team and the community at large to recognize your contributions. '''New contributors''' (i.e., those without commit access) should add themselves to the ''Miscellaneous Contributors'' section of the credits file ('''&amp;lt;code&amp;gt;data/core/about.cfg&amp;lt;/code&amp;gt;'''), making sure to follow alphabetical order with respect to the first character that will be displayed.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;When changing or adding WML features, provide directions for updating the wiki along with your submission in the tracker&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;This allows us to provide content creators with '''up-to-date information about WML features''', even if you cannot be around in time for the commit or the next release.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== After submission ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Be patient, sometimes we are not very responsive&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;The Wesnoth developers live on different locations across the globe and have other matters to attend to, most of the time. It may happen that your patch is assigned to a developer who is currently unable to dedicate much time to reviewing it. '''If you feel that it takes much too long for us to respond, contact us in #wesnoth-dev on irc.freenode.net.'''&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Don't be surprised if we discuss the patch a lot&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;Thus, you should '''leave us a way to contact you''', by noting your forums username or email address. We recommend that you join the '''&amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;''' channel on '''&amp;lt;code&amp;gt;irc.freenode.net&amp;lt;/code&amp;gt;''' regularly so we can contact you in real time if needed.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;Sometimes patches are rejected, please don't be surprised or offended if this happens&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;If your patch introduces '''new errors or bugs''', if the feature you implemented '''isn't considered an improvement''', or if '''we couldn't contact you''' with our questions and recommendations, the pull request will be denied. &amp;lt;strong&amp;gt;This can usually be averted&amp;lt;/strong&amp;gt; if you discuss your idea on #wesnoth-dev, where the developers will point out these issues. If your pull request is denied, &amp;lt;strong&amp;gt;don't let that discourage you&amp;lt;/strong&amp;gt;, though!&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Obtaining help ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If you encounter any issues or need additional guidance when preparing your patch...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...the easiest way is to ask the developers on the aforementioned IRC channel, '''&amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;'''. You can join &amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt; in your Web browser via this link: {{FeaturedURL|https://webchat.freenode.net/?channels{{=}}wesnoth-dev}}&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If you know who is responsible for the code that your patch changes...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...please prefix their IRC nick in front of your question -- else your message could be overlooked.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h3&amp;gt;If your patch has a major impact on Wesnoth...&amp;lt;/h3&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;...the developer mailing list might be more appropriate, because all subscribed developers will be notified: {{FeaturedURL|https://gna.org/mail/?group{{=}}wesnoth}}&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/ul&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
&lt;br /&gt;
* [[WesnothRepository]]&lt;br /&gt;
* [[DeveloperGuide]]&lt;br /&gt;
* [[HackingWesnoth]]&lt;br /&gt;
* [[CodingStandards]]&lt;br /&gt;
* [[EasyCoding]]&lt;br /&gt;
* [[DeveloperResources]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:%3D&amp;diff=56617</id>
		<title>Template:=</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:%3D&amp;diff=56617"/>
		<updated>2015-07-30T21:16:24Z</updated>

		<summary type="html">&lt;p&gt;8680: Created page with &amp;quot;=&amp;lt;noinclude&amp;gt;  See [https://en.wikipedia.org/wiki/Template:%3D &amp;lt;https://en.wikipedia.org/wiki/Template:%3D&amp;gt;]. &amp;lt;/noinclude&amp;gt;&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=&amp;lt;noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
See [https://en.wikipedia.org/wiki/Template:%3D &amp;lt;https://en.wikipedia.org/wiki/Template:%3D&amp;gt;].&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56616</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56616"/>
		<updated>2015-07-30T20:50:16Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git or GitHub who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;dfn&amp;gt;Git&amp;lt;/dfn&amp;gt; is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Git_for_Wesnoth_Crash_Course&amp;diff=56600</id>
		<title>Git for Wesnoth Crash Course</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Git_for_Wesnoth_Crash_Course&amp;diff=56600"/>
		<updated>2015-07-27T17:08:30Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Filing a pull request */ Actually fix link&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Foreword ==&lt;br /&gt;
&lt;br /&gt;
'''''(An essay by, mainly, iceiceice.)'''''&lt;br /&gt;
&lt;br /&gt;
This page is intended for new &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;]''' before. I'm hoping that it will be written &amp;lt;em&amp;gt;mainly&amp;lt;/em&amp;gt; by newbies like myself who have just figured out enough about &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;, and I hope you will be able to do the same after reading this.&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
The most effective '''&amp;quot;absolute beginner&amp;quot; introduction to &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;''' that I found when I started is here: '''[http://gitref.org &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt;]'''.&lt;br /&gt;
&lt;br /&gt;
I suggest that you &amp;lt;strong&amp;gt;read this through&amp;lt;/strong&amp;gt;, beginning to end, navigating through the pages by using the red arrows at the bottom of each page. You can skip the part about ''&amp;quot;stashing&amp;quot;'', but you should carefully read and understand the parts about:&lt;br /&gt;
&lt;br /&gt;
* '''''cloning''''' a ''repository'';&lt;br /&gt;
* '''''checking out''''' a ''branch'', creating a '''new branch''', and '''merging branches''';&lt;br /&gt;
* '''''adding''''' and '''''committing changes''''';&lt;br /&gt;
* viewing '''''diffs''''' to make sure you understand exactly what you are committing;&lt;br /&gt;
* '''''resetting''''' your repository state in case you make a mistake and need to undo some steps, and using &amp;quot;'''&amp;lt;kbd&amp;gt;git log&amp;lt;/kbd&amp;gt;'''&amp;quot; and &amp;quot;'''&amp;lt;kbd&amp;gt;git reflog&amp;lt;/kbd&amp;gt;'''&amp;quot; to assist with this; and&lt;br /&gt;
* moving content between local and remote repositories, with &amp;quot;'''&amp;lt;kbd&amp;gt;push&amp;lt;/kbd&amp;gt;'''&amp;quot; and &amp;quot;'''&amp;lt;kbd&amp;gt;pull&amp;lt;/kbd&amp;gt;'''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Setting up our workflow for &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; in &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; ==&lt;br /&gt;
&lt;br /&gt;
It is common when reading about &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to see the terms '''''&amp;quot;upstream&amp;quot;''''' and '''''&amp;quot;downstream&amp;quot;'''''. This is often confusing at the beginning -- after all, information is usually flowing in both directions; sometimes, you are getting code from the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, and sometimes you are sending code to it. Which way is up and which is down?&lt;br /&gt;
&lt;br /&gt;
Analogously to a river, ''downstream'' is the direction toward which most information flows. Any user that simply wants to build &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; from source, and not make any changes to it, will generally do so by cloning or pulling from &amp;lt;https://github.com/wesnoth/wesnoth&amp;gt;. So [https://github.com/wesnoth/wesnoth &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt;] (the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository) is the &amp;lt;dfn&amp;gt;upstream&amp;lt;/dfn&amp;gt; repository, and the users are &amp;lt;dfn&amp;gt;downstream&amp;lt;/dfn&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
If you are a developer, you will '''''fork''''' the upstream repository and edit the source code, and -- hopefully, with work, eventually -- get your edits pulled into the upstream repository. That is the '''&amp;lt;dfn&amp;gt;development cycle&amp;lt;/dfn&amp;gt;''', and contributing changes back to upstream is what makes you a developer. &lt;br /&gt;
&lt;br /&gt;
In this guide, we are going to assume that you will use GitHub in addition to the official &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; command-line program, because GitHub has many useful tools to offer and makes some things nicely easy, especially when comparing a topic branch to the master branch and seeing diffs in a somewhat more advanced interface, and when making ''pull requests''. Technically, this means that you will have '''&amp;lt;em&amp;gt;two&amp;lt;/em&amp;gt; repositories''' -- your &amp;lt;dfn&amp;gt;local repository&amp;lt;/dfn&amp;gt; on your computer, and a ''fork'' of the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository, on GitHub.&lt;br /&gt;
&lt;br /&gt;
The first step of becoming a &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; developer is to set up these two repositories. Follow the instructions in [https://help.github.com/articles/fork-a-repo/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Fork A Repo&amp;lt;/cite&amp;gt;&amp;quot; help article], which may be summarized as follows:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;'''''Fork''''' the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository, using the GitHub website.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;'''''Clone''''' the fork onto your computer, with the command &amp;quot;&amp;lt;kbd&amp;gt;git clone&amp;lt;/kbd&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;Configure '''&amp;lt;dfn&amp;gt;remotes&amp;lt;/dfn&amp;gt;''' (''remote'' repositories that are essentially bookmarked).&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;GitHub's &amp;lt;cite&amp;gt;Fork A Repo&amp;lt;/cite&amp;gt; article describes how to set the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository as a remote with the name &amp;quot;&amp;lt;code&amp;gt;upstream&amp;lt;/code&amp;gt;&amp;quot;. Because you cloned from your fork, the fork is automatically set as a remote with the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot;. You can see your remotes with the command &amp;quot;&amp;lt;kbd&amp;gt;git remote -v&amp;lt;/kbd&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;You might find this naming scheme confusing, given that the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot; might also aptly describe the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository. So it might be good to rename that remote to &amp;quot;&amp;lt;code&amp;gt;fork&amp;lt;/code&amp;gt;&amp;quot; (with the command &amp;quot;&amp;lt;kbd&amp;gt;git remote rename origin fork&amp;lt;/kbd&amp;gt;&amp;quot;). But if you do that, note that much of the GitHub help pages will assume the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Additionally, we ask that you configure &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to use your full real name, per the instructions in [https://help.github.com/articles/setting-your-username-in-git/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Setting your username in Git&amp;lt;/cite&amp;gt;&amp;quot; help article], so that we can associate a concrete person with every commit merged into &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;. Your GitHub profile should also display your real name.&lt;br /&gt;
&lt;br /&gt;
== The basic workflow ==&lt;br /&gt;
&lt;br /&gt;
Here's the picture we now have, with 3 repositories:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
                     origin (fork)&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are four basic steps in the development cycle, which are as follows:&lt;br /&gt;
&lt;br /&gt;
# ensuring that your local repository is '''up-to-date''' with the upstream repository;&lt;br /&gt;
# creating a '''topic branch''' for your changes;&lt;br /&gt;
# '''committing''' your changes to the topic branch and '''pushing''' them to your fork; and&lt;br /&gt;
# filing a GitHub '''pull request''', having that request granted, then finally cleaning up.&lt;br /&gt;
&lt;br /&gt;
=== Keeping your local repository up-to-date ===&lt;br /&gt;
&lt;br /&gt;
In this step, you will make sure your local &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch is up-to-date with the most recent development changes before beginning work. &lt;br /&gt;
&lt;br /&gt;
First make sure you are on your &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch:&lt;br /&gt;
&lt;br /&gt;
  git checkout master&lt;br /&gt;
  git status&lt;br /&gt;
&lt;br /&gt;
Now, pull the upstream &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch to your local repository:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |&lt;br /&gt;
       |&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |          &lt;br /&gt;
       v      &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git pull upstream master&lt;br /&gt;
&lt;br /&gt;
At this point your local master is up to date. While you are at it, you might as well update your fork as well:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
         &lt;br /&gt;
        &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /  &lt;br /&gt;
              /    &lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin master&lt;br /&gt;
&lt;br /&gt;
At this point, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch should be the same in all three repositories.&lt;br /&gt;
&lt;br /&gt;
=== Creating a topic branch ===&lt;br /&gt;
&lt;br /&gt;
In this guide, we will &amp;lt;strong&amp;gt;&amp;lt;em&amp;gt;never&amp;lt;/em&amp;gt; make any changes directly on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch&amp;lt;/strong&amp;gt;, and will &amp;lt;strong&amp;gt;&amp;lt;em&amp;gt;only&amp;lt;/em&amp;gt; make code changes on a topic branch&amp;lt;/strong&amp;gt;, so regardless of which repository you look at, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch should be the same, and &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; will be comparing your work against the upstream &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch.&lt;br /&gt;
&lt;br /&gt;
Now you are ready to create a new '''[https://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches &amp;lt;dfn&amp;gt;topic branch&amp;lt;/dfn&amp;gt;]''', which will hold your work for this patch. We are on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch, as running &amp;quot;&amp;lt;kbd&amp;gt;git status&amp;lt;/kbd&amp;gt;&amp;quot; will confirm. Create your new topic branch -- named, in this example, &amp;quot;&amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt;&amp;quot; -- by running the following command:&lt;br /&gt;
&lt;br /&gt;
  git checkout -b new-feature&lt;br /&gt;
&lt;br /&gt;
As shown in the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide, you could also have done this with the following commands:&lt;br /&gt;
&lt;br /&gt;
  git branch new-feature&lt;br /&gt;
  git checkout new-feature&lt;br /&gt;
&lt;br /&gt;
Given that you were on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch when you created the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; topic branch, the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch will branch off from the ''tip'' of your current &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch, which is best, to avoid conflicts when the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch is eventually merged upstream.&lt;br /&gt;
&lt;br /&gt;
=== Committing your changes and pushing to your fork ===&lt;br /&gt;
&lt;br /&gt;
Now, you will make your changes to &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;, test them, and commit them to your local repository, with the commands &amp;quot;&amp;lt;kbd&amp;gt;git add&amp;lt;/kbd&amp;gt;&amp;quot; and &amp;quot;&amp;lt;kbd&amp;gt;git commit&amp;lt;/kbd&amp;gt;&amp;quot;, as shown in the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide.&lt;br /&gt;
&lt;br /&gt;
==== Committing guidelines ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Write good commit messages&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;A commit message should fully explain what changes were made in the commit, and &amp;lt;em&amp;gt;why&amp;lt;/em&amp;gt; those changes were made&amp;lt;/strong&amp;gt;. A good commit message is structured like an email message.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;The first line, which &amp;lt;strong&amp;gt;summarizes&amp;lt;/strong&amp;gt; the commit, has special importance -- to quote the &amp;lt;cite&amp;gt;[[DeveloperGuide]]&amp;lt;/cite&amp;gt; page, &amp;lt;q cite=&amp;quot;http://wiki.wesnoth.org/DeveloperGuide#Commit_messages&amp;quot;&amp;gt;This is the first (and often the only) line someone using browsing tools will see&amp;lt;/q&amp;gt;. It should ideally be at most 80 characters (TODO: inconsistent with current policy), and is like the subject line of an email message. Commit message summary lines should be written in the imperative present tense, e.g., &amp;quot;Add field to &amp;lt;var&amp;gt;some_class&amp;lt;/var&amp;gt;, with accessor methods&amp;quot;, &amp;quot;Fix &amp;lt;var&amp;gt;other_class&amp;lt;/var&amp;gt;'s constructor&amp;quot;, &amp;quot;Delete unnecessary #include&amp;quot;, etc.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;After the summary line, there must be a blank line, after which comes the '''commit message body''', which is analogous to the body of an email message.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;'''Optimally''', a commit's message would be so clearly and comprehensively explanatory that it would answer any questions that anyone might have about the commit, now, the next day, or years into the future -- which is especially important because the author of the commit likely won't always be around to answer those questions.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Commit_messages the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Commit messages&amp;quot; section] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines the official Git book's &amp;quot;Commit Guidelines&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Make appropriately sized commits&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;Each commit should correspond to a &amp;lt;strong&amp;gt;single logical step&amp;lt;/strong&amp;gt; in your programming task. The commits constitute the project's development history; people will look at your commits to try to figure out how we got to where we are today, and may at some point need to undo the changes made in some of your commits to fix a future issue.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;If you find it difficult to write a succinct commit message that fully explain what changes were made in the commit, and why those changes were made, then the commit is insufficiently fine-grained -- too large and too complicated.&amp;lt;/strong&amp;gt; Another guideline is, you should at least think about committing almost every time you compile (depending on your habits).&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;On the other hand, you shouldn't make a commit for every line of code typed. &amp;lt;strong&amp;gt;If it would never make sense to revert the repository's code to its current state from a future state, you probably shouldn't commit.&amp;lt;/strong&amp;gt; For example, if you define a field of an object, but it has no accessors and no way to be used in code, it would never make sense to revert to that time in the repository's history, so those changes should be saved together in a single commit. If you have a commit that merely adjusts whitespace in a file, that should be squashed in with another commit, according to current (2015-07-25) policy.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;It is better to commit more often than less often&amp;lt;/strong&amp;gt;, because, before you submit your changes to upstream, you will have the opportunity to edit your commit history, and &amp;lt;strong&amp;gt;it is much easier to ''squash'' commits together than to split up an overly-large commit&amp;lt;/strong&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Commits the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Commits&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Keep the change-logs, release notes, and credits up-to-date&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;After committing your changes, add an entry in the '''&amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;''' document, and commit it with the message &amp;quot;Update changelog&amp;quot;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;We also have a '''&amp;lt;code&amp;gt;players_changelog&amp;lt;/code&amp;gt;''' document, which should contain only changes that most players are likely to notice, and be less technical than the main, technical &amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;There is also a '''&amp;lt;code&amp;gt;RELEASE_NOTES&amp;lt;/code&amp;gt;''' document, which basically is copied into the next &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; release's release announcement post in the forums, so if there is a new feature or bug fix that should be advertised, add that to &amp;lt;code&amp;gt;RELEASE_NOTES&amp;lt;/code&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;If this is your first commit, the development team will ask you to add an appropriate note about yourself in the '''credits document''', '''&amp;lt;code&amp;gt;data/about.cfg&amp;lt;/code&amp;gt;'''.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Changelogs_and_release_notes the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Changelogs and release notes&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, when your branch is ready, push it to your fork.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
        &lt;br /&gt;
        &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /&lt;br /&gt;
              /&lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin new-feature&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Now, if you navigate to your fork's page on GitHub, you should see a message such as &amp;quot;recently pushed branch new-feature (3 minutes ago)&amp;quot;. Click &amp;quot;Compare&amp;quot; to compare it against the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch. You should now see a list of the commits you made on the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch, and color-highlighted diffs of the files you changed. You can click through the commits in order to see each of the changes you made and understand how your project progressed -- this is exactly what the development team will do when they review your pull request.&lt;br /&gt;
&lt;br /&gt;
In the GitHub interface, you can always see a list of branches by clicking on &amp;quot;branches&amp;quot; in the line near the middle of the page that looks like the following:&lt;br /&gt;
&lt;br /&gt;
 10,000+ commits     27 branches     248 releases     85 contributors&lt;br /&gt;
&lt;br /&gt;
You can also look at a specific branch using the &amp;quot;Branch&amp;quot; menu below that line, and you can compare branches using the green &amp;quot;Compare&amp;quot; button to the left of the &amp;quot;Branch&amp;quot; menu.&lt;br /&gt;
&lt;br /&gt;
=== Cleaning up your branch ===&lt;br /&gt;
&lt;br /&gt;
Before filing your pull request, if, looking at the diffs and the history (the list of commits) for your topic branch, you saw anything confusing or not quite right, now is your opportunity to change it.&lt;br /&gt;
&lt;br /&gt;
From the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide, you should know how to add more commits, and you should know that you can use &amp;quot;&amp;lt;kbd&amp;gt;reset&amp;lt;/kbd&amp;gt;&amp;quot; to go back in time and redo things.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;'''&amp;lt;kbd&amp;gt;reset&amp;lt;/kbd&amp;gt;'''&amp;quot; is especially good if your last commit was too big and you want to break it up into a series of smaller commits -- the command &amp;quot;&amp;lt;kbd&amp;gt;git reset &amp;quot;@~&amp;quot;&amp;lt;/kbd&amp;gt;&amp;quot; will leave your working directory the same, but jump back in time one commit and unstage all of those changes, so you can add a smaller subset of the files, commit those, then add the others, etc.&lt;br /&gt;
&lt;br /&gt;
More generally, you can use &amp;quot;'''&amp;lt;kbd&amp;gt;git reflog&amp;lt;/kbd&amp;gt;'''&amp;quot; to see how to reset back over any number of commits or other &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; operations. &lt;br /&gt;
&lt;br /&gt;
You can also use &amp;quot;'''&amp;lt;kbd&amp;gt;git commit --amend&amp;lt;/kbd&amp;gt;'''&amp;quot; to edit the commit message of the most recent commit.&lt;br /&gt;
&lt;br /&gt;
There are several more advanced cleanup features available with &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;, but we'll defer any further discussion of them.&lt;br /&gt;
&lt;br /&gt;
Every time you make changes, you should to push them to your fork to keep it up-to-date. If you rewrote your commit history, then the push would be rejected, because the commit histories won't match. Therefore, to push a rewritten history, you must '''''&amp;lt;strong&amp;gt;force push&amp;lt;/strong&amp;gt;''''', which will -- &amp;lt;strong&amp;gt;this is a potentially dangerous operation!&amp;lt;/strong&amp;gt; -- discard the old commit history and replace it with the new history:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
          &lt;br /&gt;
         &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /&lt;br /&gt;
              /&lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push --force origin new-feature&lt;br /&gt;
&lt;br /&gt;
You can and should do this throughout your development if you want to look at the diffs of your changes as you work -- after all, the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; code-base is vast and it is easy to forget exactly where you are in your project. You can and should keep cleaning up in this way until you are satisfied with the result. Doing this, your GitHub fork ends up being rather like a personal Web-based IDE plug-in or extension to help you with development.&lt;br /&gt;
&lt;br /&gt;
=== Filing a pull request ===&lt;br /&gt;
&lt;br /&gt;
When you finish working on your feature or bug fix, select your topic branch on your fork (with the &amp;quot;Branch&amp;quot; menu), and click the green button to file a pull request. By default, the target of the pull request -- the repository and branch into which it is requesting that your changes be pulled -- will be &amp;quot;&amp;lt;samp&amp;gt;wesnoth:master&amp;lt;/samp&amp;gt;&amp;quot;, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch of the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository.&lt;br /&gt;
&lt;br /&gt;
The message that you enter for the pull request should become the commit message of the merge operation performed in the upstream repository if the pull request is granted. (Note: if you are granting someone's PR through the GitHub Web interface, please ensure that this happens.)&lt;br /&gt;
&lt;br /&gt;
If you fixed a bug, you should say, e.g., &amp;quot;Fixed bug #5678&amp;quot; in the pull-request message, which should automatically link to [https://gna.org/bugs/index.php?group=wesnoth&amp;amp;set=custom&amp;amp;report_id=101&amp;amp;status_id=1&amp;amp;chunksz=150&amp;amp;boxoptionwanted=1 our Gna! bug tracker].&lt;br /&gt;
&lt;br /&gt;
If you want more information, you could read [https://help.github.com/articles/creating-a-pull-request/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Creating a pull request&amp;lt;/cite&amp;gt;&amp;quot; help article].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream &amp;lt;-.&lt;br /&gt;
                \&lt;br /&gt;
                 \&lt;br /&gt;
                  '- origin (fork)&lt;br /&gt;
  &lt;br /&gt;
  &lt;br /&gt;
     local     &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
You should then see your pull request in [https://github.com/wesnoth/wesnoth/pulls the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository's &amp;quot;pull requests&amp;quot; page].&lt;br /&gt;
&lt;br /&gt;
At the time of writing this, we also have configured [https://travis-ci.org Travis CI], a [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] system, to automatically try to compile &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; with your changes, to make sure that it still works before your pull request is granted. However, it is not mandatory for the Travis build to complete successfully for the pull request to be granted. Additionally, you may still make changes to your pull request by pushing more changes to your topic branch in your fork, after which Travis &amp;lt;em&amp;gt;should&amp;lt;/em&amp;gt; try to compile the updated topic branch. You can even still force push to erase the content of the topic branch (on which the pull request is based) and replace it with new content -- however, you shouldn't file a pull request for a topic branch until you are ready for it to be merged.&lt;br /&gt;
&lt;br /&gt;
Now, wait for a member of the development team to review your pull request. You can often find someone on the development [//wiki.wesnoth.org/Support#IRC IRC] channel, &amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.&lt;br /&gt;
&lt;br /&gt;
=== Cleaning up at the end ===&lt;br /&gt;
&lt;br /&gt;
Congratulations, a developer granted your pull request! Now it's time to clean up and update your local repository.&lt;br /&gt;
&lt;br /&gt;
On the GitHub page for your pull request, you should now see a button with the option &amp;quot;delete this branch&amp;quot;. Since the content of new-feature is now merged into master, this branch no longer needs to exist as you won't work on it anymore, and future work will go onto a different branch. So you should delete it, which will delete the branch on *origin*, your github-associated repo.&lt;br /&gt;
&lt;br /&gt;
Since master has now changed and we want master to be synced up, you should now do step 1 again:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |&lt;br /&gt;
       |&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |          &lt;br /&gt;
       v      &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git checkout master&lt;br /&gt;
  git pull upstream master&lt;br /&gt;
&lt;br /&gt;
At this point git will understand that new-feature has been merged into master, so when you ask to delete this branch from local as well, it will do it:&lt;br /&gt;
&lt;br /&gt;
  git branch -d new-feature&lt;br /&gt;
&lt;br /&gt;
If you do these steps out of order, i.e. try to delete the branch before before syncing master, it will make a warning &amp;quot;Are you sure? You have unmerged changes on this branch...&amp;quot; etc.&lt;br /&gt;
&lt;br /&gt;
Finally, sync master on the origin as well:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
          &lt;br /&gt;
          &lt;br /&gt;
                     origin (fork)&lt;br /&gt;
               /--&amp;gt;  &lt;br /&gt;
            --/    &lt;br /&gt;
     local     &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin master&lt;br /&gt;
&lt;br /&gt;
That's the end of the development cycle, and now you can begin on your next patch. Note that throughout the cycle, information only flowed counter-clockwise:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |     &amp;lt;--\&lt;br /&gt;
       |         \--&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |       /--&amp;gt;  &lt;br /&gt;
       v    --/    &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If for some reason you find yourself doing something where information is flowing the other way, that is a good sign that something is going wrong, at least as far as this guide is concerned! (The exception is the steps in which we set up our repos -- don't overthink this.)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Advanced / Alternative workflows ==&lt;br /&gt;
&lt;br /&gt;
You can use pull requests as described above whether you have commit access or not -- if you have commit access, then you can click to accept your own pull requests.&lt;br /&gt;
&lt;br /&gt;
However, if you have commit access, you may prefer not to use github / pull requests at all, and instead to push directly to wesnoth:master. You can still use topic branches to hold your work, and merge them to your local master using git merge, then use 'git push upstream master' to push them to the main wesnoth repo. &lt;br /&gt;
&lt;br /&gt;
If you are lazy, you might even skip making a topic branch and just commit to local master, although IMO this can make things more confusing if you get a merge conflict later.&lt;br /&gt;
&lt;br /&gt;
Either way, afaik the vast majority of wesnoth developers prefer to push directly to wesnoth:master.&lt;br /&gt;
&lt;br /&gt;
An extreme option appropriate for small changes is to skip the local repo as well, and simply commit changes directly from the github web interface. This might be appropriate for example if you forgot to commit a changelog entry in an earlier patch, or are simply changing some numbers used as parameters somewhere. Obviously if you change source code this way, you should make certain that everything still compiles immediately after! (Note: Don't actually do that.)&lt;br /&gt;
&lt;br /&gt;
== The ultimate cleanup power tool: git rebase ==&lt;br /&gt;
&lt;br /&gt;
Using things in the gitref guide, you can see how to use reset to undo mistakes you made by backing up and trying again, and for small commits that is probably fine. However, if you have a large and complicated series of changes, the better way to do this is using git rebase. Using git rebase in interactive mode, you can rewrite history by&lt;br /&gt;
&lt;br /&gt;
* reordering your commits&lt;br /&gt;
* discarding unwanted commits&lt;br /&gt;
* squashing commits together&lt;br /&gt;
* editing the content changes represented by an individual commit&lt;br /&gt;
* editing the commit message&lt;br /&gt;
&lt;br /&gt;
For our purposes, we assume you are working on a topic branch, and then you will only need to use the form&lt;br /&gt;
&lt;br /&gt;
  git rebase -i master&lt;br /&gt;
&lt;br /&gt;
You can see some documentation for using this command here: https://help.github.com/articles/interactive-rebase&lt;br /&gt;
&lt;br /&gt;
Using 'git rebase', you can make your commit history very *clean* -- instead of the history saying &amp;quot;I tried a bunch of things, undid some of them, tried some other things, and found something I liked&amp;quot;, your commit history can basically be &amp;quot;I took the simplest and most logical route to the solution that was finally the best&amp;quot;. When you review your commits, instead of feeling like a nasty blood-and-elbow-grease engineering project, it should feel like folding a perfect origami crane, to the extent possible ;)&lt;br /&gt;
&lt;br /&gt;
But to reiterate, this has a purpose. &lt;br /&gt;
# Other devs need to be able to understand the history.&lt;br /&gt;
# It should be possible to jump back in time by checking out one of your commits and find ourselves in a sensible state when we do so.&lt;br /&gt;
# If something breaks or some feature become incompatible, it should be possible to roll back only a piece of the implementation of your feature without removing the whole thing.&lt;br /&gt;
&lt;br /&gt;
If you want to use rebase to cleanup your history, it is important to do it *before* it is pulled into wesnoth, as once that happens it is basically no longer possible. If we rewrite history in the main wesnoth repo, then afterwards whenever any dev tries to 'git pull upstream master', their git will give them strange merge errors, stemming from the incompatible history, and then they will become nervous, jump on irc and exclaim some variation of &amp;quot;omg wtf bbq&amp;quot;. So except in extreme circumstances, we will never rebase the main wesnoth master, and for the same reason, we will never use &amp;quot;git push --force upstream master&amp;quot;. That's why if you want to do these things, it is important to do them on your *fork* before it makes it onto master.&lt;br /&gt;
&lt;br /&gt;
If you feel like it, you might read this, which is a historical email between early users / developers of git, in which Linus Torvalds explains about shared history of repos and when it is appropriate to use git rebase. &lt;br /&gt;
&lt;br /&gt;
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html&lt;br /&gt;
&lt;br /&gt;
When you become comfortable with git rebase -i, it will greatly improve your workflow, as you will know that you can easily review and revise commit messages later, and easily reorder and squash commits. Typically I will now commit every single time I compile, and even if it is a commit which e.g. fixes a compile time error, or for some other reason I know it will be squashed in somewhere else, I give it the commit message &amp;quot;fixup&amp;quot;, as a note to myself to mark it thusly in the first git rebase pass. (Actually, while writing this I have just learned about the --autosquash feature of git rebase which takes this idea further, good stuff there.)&lt;br /&gt;
&lt;br /&gt;
Note that unlike Linus and github, in this guide we aren't thinking about your github fork repo as public -- we prefer to think of it as your personal private IDE/tool as I described earlier. If other wesnoth devs are cloning it or pulling your topic branches, we assume you will work it out with them. With that caveat the philosophies expressed on github and by Linus should generally apply to the wesnoth project as well.&lt;br /&gt;
&lt;br /&gt;
=== Solving merge conflicts with git rebase ===&lt;br /&gt;
&lt;br /&gt;
Github version: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request&lt;br /&gt;
&lt;br /&gt;
Suppose that you modify a file in the same place as someone else, and their change gets merged before yours. If git can't figure out how to merge, then someone will have to fix it. This could be done by whoever is merging the new content into master, but if you don't have commit access then that person is not you. One way that *you* could fix it is to resync your master to get the new changes locally, and then rebase your topic branch so that your changes are applied *after* the most recent changes.&lt;br /&gt;
&lt;br /&gt;
  git rebase master&lt;br /&gt;
&lt;br /&gt;
To understand what is happening, we should understand a bit more about how git works. Intuitively, git is all about &amp;quot;snapshots&amp;quot; of the project content. Every commit represents a snapshot, and you can look at this snapshot by checking out the commit. However git does not store each snapshot separately -- instead git defines the snapshots in terms of one another, and stores only the diffs. When you rebase your topic branch onto master, this will also update the &amp;quot;point of departure&amp;quot; where your branch was created, so that in the history, it will depart from the current head of master with the most recent changes. (Obviously, if you don't sync master until you are done working, then this subtlety to 'git rebase' is irrelevant.) &lt;br /&gt;
&lt;br /&gt;
If merging your branch with the current master would create a conflict, then when git rebase gets to the commit that creates the conflict, it will get confused when it tries to apply that diff, stop, tell you about the problem, and ask you to resolve it -- you can open up the offending file and go to the point where the conflict is happening, and git will leave a note for you of the content it is having trouble with. The note will look similar to what happens in the gitref guide here, under &amp;quot;merge conflicts&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
http://gitref.org/branching/#merge&lt;br /&gt;
&lt;br /&gt;
You just have to remove the note, make the file look like it should to make everything compatible, and type&lt;br /&gt;
&lt;br /&gt;
  git add .&lt;br /&gt;
  git rebase --continue&lt;br /&gt;
&lt;br /&gt;
Then the rebasing process will continue, and at the end your branch should be compatible with master and ready to be merged in.&lt;br /&gt;
&lt;br /&gt;
You can read more about this aspect of git rebase here if you like, although most likely you won't actually need more than we just talked about for wesnoth development. &lt;br /&gt;
&lt;br /&gt;
http://git-scm.com/book/en/Git-Branching-Rebasing&lt;br /&gt;
&lt;br /&gt;
That's all for this guide, have fun hacking on wesnoth!&lt;br /&gt;
&lt;br /&gt;
== Addendum ==&lt;br /&gt;
The following section contains commands with the -f / --force options. Those are usually used to rewrite history, which is fine for your own fork but disallowed for upstream. Do not use them on the main repository.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
control with which repo you interact&lt;br /&gt;
        git remote -v&lt;br /&gt;
 &lt;br /&gt;
  upstream should be      git@github.com:wesnoth/wesnoth.git&lt;br /&gt;
  origin should be        git@github.com:your_name/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
if a command goes awry, you can go to &amp;quot;git reflog&amp;quot;, find the point just before you typed it, and reset --hard to that commit, and it should be like the bad thing never happened&lt;br /&gt;
 &lt;br /&gt;
revert every file in the repo to look like it did at the HEAD commit (last successful sync)&lt;br /&gt;
        git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
get a clean slate by syncing with upstream&lt;br /&gt;
        git fetch upstream&lt;br /&gt;
        git checkout -B master upstream/master&lt;br /&gt;
        git push --force origin master&lt;br /&gt;
if this errors, try again after&lt;br /&gt;
        git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
undo n commits, split/squash and apply again&lt;br /&gt;
        git reset HEAD~n&lt;br /&gt;
        git add -p&lt;br /&gt;
        git commit&lt;br /&gt;
        git push -f&lt;br /&gt;
&lt;br /&gt;
You can also push from one ‘ref’ to a different one: &lt;br /&gt;
        $ git push &amp;lt;remote&amp;gt; &amp;lt;from&amp;gt;:&amp;lt;to&amp;gt;&lt;br /&gt;
&lt;br /&gt;
completely overwrite branch b with a (from a to b)&lt;br /&gt;
        git push -f origin a:b&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
before any commit:&lt;br /&gt;
&lt;br /&gt;
* if the diff shows an invisible change in the first line - stop! Fix the file encoding back to UTF8 without BOM.&lt;br /&gt;
 &lt;br /&gt;
* don't forget the changelog (and, for visible changes, the players_changelog)&lt;br /&gt;
 &lt;br /&gt;
* try to keep the summary at 50 characters or less, maximum 72&amp;lt;br&amp;gt;commit meter in units of 10 chars:&lt;br /&gt;
 '         |         |         |         |         | 50 character summary limit&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[Project#Developers]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Git_for_Wesnoth_Crash_Course&amp;diff=56599</id>
		<title>Git for Wesnoth Crash Course</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Git_for_Wesnoth_Crash_Course&amp;diff=56599"/>
		<updated>2015-07-27T17:08:06Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Filing a pull request */ Fix link&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Foreword ==&lt;br /&gt;
&lt;br /&gt;
'''''(An essay by, mainly, iceiceice.)'''''&lt;br /&gt;
&lt;br /&gt;
This page is intended for new &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; developers and contributors who have never used '''[//wiki.wesnoth.org/WesnothRepository &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;]''' before. I'm hoping that it will be written &amp;lt;em&amp;gt;mainly&amp;lt;/em&amp;gt; by newbies like myself who have just figured out enough about &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to use it successfully, and therefore not include a bunch of information superfluous for that purpose. At the time that I am writing this, I have managed to write about eight GitHub pull requests and get them merged into &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;, and I hope you will be able to do the same after reading this.&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
The most effective '''&amp;quot;absolute beginner&amp;quot; introduction to &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;''' that I found when I started is here: '''[http://gitref.org &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt;]'''.&lt;br /&gt;
&lt;br /&gt;
I suggest that you &amp;lt;strong&amp;gt;read this through&amp;lt;/strong&amp;gt;, beginning to end, navigating through the pages by using the red arrows at the bottom of each page. You can skip the part about ''&amp;quot;stashing&amp;quot;'', but you should carefully read and understand the parts about:&lt;br /&gt;
&lt;br /&gt;
* '''''cloning''''' a ''repository'';&lt;br /&gt;
* '''''checking out''''' a ''branch'', creating a '''new branch''', and '''merging branches''';&lt;br /&gt;
* '''''adding''''' and '''''committing changes''''';&lt;br /&gt;
* viewing '''''diffs''''' to make sure you understand exactly what you are committing;&lt;br /&gt;
* '''''resetting''''' your repository state in case you make a mistake and need to undo some steps, and using &amp;quot;'''&amp;lt;kbd&amp;gt;git log&amp;lt;/kbd&amp;gt;'''&amp;quot; and &amp;quot;'''&amp;lt;kbd&amp;gt;git reflog&amp;lt;/kbd&amp;gt;'''&amp;quot; to assist with this; and&lt;br /&gt;
* moving content between local and remote repositories, with &amp;quot;'''&amp;lt;kbd&amp;gt;push&amp;lt;/kbd&amp;gt;'''&amp;quot; and &amp;quot;'''&amp;lt;kbd&amp;gt;pull&amp;lt;/kbd&amp;gt;'''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Setting up our workflow for &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; in &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; ==&lt;br /&gt;
&lt;br /&gt;
It is common when reading about &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to see the terms '''''&amp;quot;upstream&amp;quot;''''' and '''''&amp;quot;downstream&amp;quot;'''''. This is often confusing at the beginning -- after all, information is usually flowing in both directions; sometimes, you are getting code from the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, and sometimes you are sending code to it. Which way is up and which is down?&lt;br /&gt;
&lt;br /&gt;
Analogously to a river, ''downstream'' is the direction toward which most information flows. Any user that simply wants to build &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; from source, and not make any changes to it, will generally do so by cloning or pulling from &amp;lt;https://github.com/wesnoth/wesnoth&amp;gt;. So [https://github.com/wesnoth/wesnoth &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt;] (the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository) is the &amp;lt;dfn&amp;gt;upstream&amp;lt;/dfn&amp;gt; repository, and the users are &amp;lt;dfn&amp;gt;downstream&amp;lt;/dfn&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
If you are a developer, you will '''''fork''''' the upstream repository and edit the source code, and -- hopefully, with work, eventually -- get your edits pulled into the upstream repository. That is the '''&amp;lt;dfn&amp;gt;development cycle&amp;lt;/dfn&amp;gt;''', and contributing changes back to upstream is what makes you a developer. &lt;br /&gt;
&lt;br /&gt;
In this guide, we are going to assume that you will use GitHub in addition to the official &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; command-line program, because GitHub has many useful tools to offer and makes some things nicely easy, especially when comparing a topic branch to the master branch and seeing diffs in a somewhat more advanced interface, and when making ''pull requests''. Technically, this means that you will have '''&amp;lt;em&amp;gt;two&amp;lt;/em&amp;gt; repositories''' -- your &amp;lt;dfn&amp;gt;local repository&amp;lt;/dfn&amp;gt; on your computer, and a ''fork'' of the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository, on GitHub.&lt;br /&gt;
&lt;br /&gt;
The first step of becoming a &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; developer is to set up these two repositories. Follow the instructions in [https://help.github.com/articles/fork-a-repo/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Fork A Repo&amp;lt;/cite&amp;gt;&amp;quot; help article], which may be summarized as follows:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;'''''Fork''''' the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository, using the GitHub website.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;'''''Clone''''' the fork onto your computer, with the command &amp;quot;&amp;lt;kbd&amp;gt;git clone&amp;lt;/kbd&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&amp;lt;p&amp;gt;Configure '''&amp;lt;dfn&amp;gt;remotes&amp;lt;/dfn&amp;gt;''' (''remote'' repositories that are essentially bookmarked).&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;GitHub's &amp;lt;cite&amp;gt;Fork A Repo&amp;lt;/cite&amp;gt; article describes how to set the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository as a remote with the name &amp;quot;&amp;lt;code&amp;gt;upstream&amp;lt;/code&amp;gt;&amp;quot;. Because you cloned from your fork, the fork is automatically set as a remote with the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot;. You can see your remotes with the command &amp;quot;&amp;lt;kbd&amp;gt;git remote -v&amp;lt;/kbd&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;p&amp;gt;You might find this naming scheme confusing, given that the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot; might also aptly describe the &amp;lt;code&amp;gt;wesnoth/wesnoth&amp;lt;/code&amp;gt; repository. So it might be good to rename that remote to &amp;quot;&amp;lt;code&amp;gt;fork&amp;lt;/code&amp;gt;&amp;quot; (with the command &amp;quot;&amp;lt;kbd&amp;gt;git remote rename origin fork&amp;lt;/kbd&amp;gt;&amp;quot;). But if you do that, note that much of the GitHub help pages will assume the name &amp;quot;&amp;lt;code&amp;gt;origin&amp;lt;/code&amp;gt;&amp;quot;.&amp;lt;/p&amp;gt;&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Additionally, we ask that you configure &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; to use your full real name, per the instructions in [https://help.github.com/articles/setting-your-username-in-git/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Setting your username in Git&amp;lt;/cite&amp;gt;&amp;quot; help article], so that we can associate a concrete person with every commit merged into &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;. Your GitHub profile should also display your real name.&lt;br /&gt;
&lt;br /&gt;
== The basic workflow ==&lt;br /&gt;
&lt;br /&gt;
Here's the picture we now have, with 3 repositories:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
                     origin (fork)&lt;br /&gt;
 &lt;br /&gt;
 &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
There are four basic steps in the development cycle, which are as follows:&lt;br /&gt;
&lt;br /&gt;
# ensuring that your local repository is '''up-to-date''' with the upstream repository;&lt;br /&gt;
# creating a '''topic branch''' for your changes;&lt;br /&gt;
# '''committing''' your changes to the topic branch and '''pushing''' them to your fork; and&lt;br /&gt;
# filing a GitHub '''pull request''', having that request granted, then finally cleaning up.&lt;br /&gt;
&lt;br /&gt;
=== Keeping your local repository up-to-date ===&lt;br /&gt;
&lt;br /&gt;
In this step, you will make sure your local &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch is up-to-date with the most recent development changes before beginning work. &lt;br /&gt;
&lt;br /&gt;
First make sure you are on your &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch:&lt;br /&gt;
&lt;br /&gt;
  git checkout master&lt;br /&gt;
  git status&lt;br /&gt;
&lt;br /&gt;
Now, pull the upstream &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch to your local repository:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |&lt;br /&gt;
       |&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |          &lt;br /&gt;
       v      &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git pull upstream master&lt;br /&gt;
&lt;br /&gt;
At this point your local master is up to date. While you are at it, you might as well update your fork as well:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
         &lt;br /&gt;
        &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /  &lt;br /&gt;
              /    &lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin master&lt;br /&gt;
&lt;br /&gt;
At this point, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch should be the same in all three repositories.&lt;br /&gt;
&lt;br /&gt;
=== Creating a topic branch ===&lt;br /&gt;
&lt;br /&gt;
In this guide, we will &amp;lt;strong&amp;gt;&amp;lt;em&amp;gt;never&amp;lt;/em&amp;gt; make any changes directly on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch&amp;lt;/strong&amp;gt;, and will &amp;lt;strong&amp;gt;&amp;lt;em&amp;gt;only&amp;lt;/em&amp;gt; make code changes on a topic branch&amp;lt;/strong&amp;gt;, so regardless of which repository you look at, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch should be the same, and &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; will be comparing your work against the upstream &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch.&lt;br /&gt;
&lt;br /&gt;
Now you are ready to create a new '''[https://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches &amp;lt;dfn&amp;gt;topic branch&amp;lt;/dfn&amp;gt;]''', which will hold your work for this patch. We are on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch, as running &amp;quot;&amp;lt;kbd&amp;gt;git status&amp;lt;/kbd&amp;gt;&amp;quot; will confirm. Create your new topic branch -- named, in this example, &amp;quot;&amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt;&amp;quot; -- by running the following command:&lt;br /&gt;
&lt;br /&gt;
  git checkout -b new-feature&lt;br /&gt;
&lt;br /&gt;
As shown in the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide, you could also have done this with the following commands:&lt;br /&gt;
&lt;br /&gt;
  git branch new-feature&lt;br /&gt;
  git checkout new-feature&lt;br /&gt;
&lt;br /&gt;
Given that you were on the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch when you created the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; topic branch, the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch will branch off from the ''tip'' of your current &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch, which is best, to avoid conflicts when the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch is eventually merged upstream.&lt;br /&gt;
&lt;br /&gt;
=== Committing your changes and pushing to your fork ===&lt;br /&gt;
&lt;br /&gt;
Now, you will make your changes to &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;, test them, and commit them to your local repository, with the commands &amp;quot;&amp;lt;kbd&amp;gt;git add&amp;lt;/kbd&amp;gt;&amp;quot; and &amp;quot;&amp;lt;kbd&amp;gt;git commit&amp;lt;/kbd&amp;gt;&amp;quot;, as shown in the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide.&lt;br /&gt;
&lt;br /&gt;
==== Committing guidelines ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;ol&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Write good commit messages&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;A commit message should fully explain what changes were made in the commit, and &amp;lt;em&amp;gt;why&amp;lt;/em&amp;gt; those changes were made&amp;lt;/strong&amp;gt;. A good commit message is structured like an email message.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;The first line, which &amp;lt;strong&amp;gt;summarizes&amp;lt;/strong&amp;gt; the commit, has special importance -- to quote the &amp;lt;cite&amp;gt;[[DeveloperGuide]]&amp;lt;/cite&amp;gt; page, &amp;lt;q cite=&amp;quot;http://wiki.wesnoth.org/DeveloperGuide#Commit_messages&amp;quot;&amp;gt;This is the first (and often the only) line someone using browsing tools will see&amp;lt;/q&amp;gt;. It should ideally be at most 80 characters (TODO: inconsistent with current policy), and is like the subject line of an email message. Commit message summary lines should be written in the imperative present tense, e.g., &amp;quot;Add field to &amp;lt;var&amp;gt;some_class&amp;lt;/var&amp;gt;, with accessor methods&amp;quot;, &amp;quot;Fix &amp;lt;var&amp;gt;other_class&amp;lt;/var&amp;gt;'s constructor&amp;quot;, &amp;quot;Delete unnecessary #include&amp;quot;, etc.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;After the summary line, there must be a blank line, after which comes the '''commit message body''', which is analogous to the body of an email message.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;'''Optimally''', a commit's message would be so clearly and comprehensively explanatory that it would answer any questions that anyone might have about the commit, now, the next day, or years into the future -- which is especially important because the author of the commit likely won't always be around to answer those questions.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Commit_messages the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Commit messages&amp;quot; section] and [https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines the official Git book's &amp;quot;Commit Guidelines&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Make appropriately sized commits&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;Each commit should correspond to a &amp;lt;strong&amp;gt;single logical step&amp;lt;/strong&amp;gt; in your programming task. The commits constitute the project's development history; people will look at your commits to try to figure out how we got to where we are today, and may at some point need to undo the changes made in some of your commits to fix a future issue.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;If you find it difficult to write a succinct commit message that fully explain what changes were made in the commit, and why those changes were made, then the commit is insufficiently fine-grained -- too large and too complicated.&amp;lt;/strong&amp;gt; Another guideline is, you should at least think about committing almost every time you compile (depending on your habits).&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;On the other hand, you shouldn't make a commit for every line of code typed. &amp;lt;strong&amp;gt;If it would never make sense to revert the repository's code to its current state from a future state, you probably shouldn't commit.&amp;lt;/strong&amp;gt; For example, if you define a field of an object, but it has no accessors and no way to be used in code, it would never make sense to revert to that time in the repository's history, so those changes should be saved together in a single commit. If you have a commit that merely adjusts whitespace in a file, that should be squashed in with another commit, according to current (2015-07-25) policy.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;&amp;lt;strong&amp;gt;It is better to commit more often than less often&amp;lt;/strong&amp;gt;, because, before you submit your changes to upstream, you will have the opportunity to edit your commit history, and &amp;lt;strong&amp;gt;it is much easier to ''squash'' commits together than to split up an overly-large commit&amp;lt;/strong&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Commits the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Commits&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;li&amp;gt;&lt;br /&gt;
&amp;lt;h5 style=&amp;quot;font-size: larger&amp;quot;&amp;gt;&amp;lt;strong&amp;gt;Keep the change-logs, release notes, and credits up-to-date&amp;lt;/strong&amp;gt;&amp;lt;/h5&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;After committing your changes, add an entry in the '''&amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;''' document, and commit it with the message &amp;quot;Update changelog&amp;quot;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;We also have a '''&amp;lt;code&amp;gt;players_changelog&amp;lt;/code&amp;gt;''' document, which should contain only changes that most players are likely to notice, and be less technical than the main, technical &amp;lt;code&amp;gt;changelog&amp;lt;/code&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;There is also a '''&amp;lt;code&amp;gt;RELEASE_NOTES&amp;lt;/code&amp;gt;''' document, which basically is copied into the next &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; release's release announcement post in the forums, so if there is a new feature or bug fix that should be advertised, add that to &amp;lt;code&amp;gt;RELEASE_NOTES&amp;lt;/code&amp;gt;.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;If this is your first commit, the development team will ask you to add an appropriate note about yourself in the '''credits document''', '''&amp;lt;code&amp;gt;data/about.cfg&amp;lt;/code&amp;gt;'''.&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p&amp;gt;See also [//wiki.wesnoth.org/DeveloperGuide#Changelogs_and_release_notes the &amp;lt;cite&amp;gt;DeveloperGuide&amp;lt;/cite&amp;gt; page's &amp;quot;Changelogs and release notes&amp;quot; section].&amp;lt;/p&amp;gt;&lt;br /&gt;
&amp;lt;/li&amp;gt;&lt;br /&gt;
&amp;lt;/ol&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Finally, when your branch is ready, push it to your fork.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
        &lt;br /&gt;
        &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /&lt;br /&gt;
              /&lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin new-feature&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Now, if you navigate to your fork's page on GitHub, you should see a message such as &amp;quot;recently pushed branch new-feature (3 minutes ago)&amp;quot;. Click &amp;quot;Compare&amp;quot; to compare it against the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch. You should now see a list of the commits you made on the &amp;lt;code&amp;gt;new-feature&amp;lt;/code&amp;gt; branch, and color-highlighted diffs of the files you changed. You can click through the commits in order to see each of the changes you made and understand how your project progressed -- this is exactly what the development team will do when they review your pull request.&lt;br /&gt;
&lt;br /&gt;
In the GitHub interface, you can always see a list of branches by clicking on &amp;quot;branches&amp;quot; in the line near the middle of the page that looks like the following:&lt;br /&gt;
&lt;br /&gt;
 10,000+ commits     27 branches     248 releases     85 contributors&lt;br /&gt;
&lt;br /&gt;
You can also look at a specific branch using the &amp;quot;Branch&amp;quot; menu below that line, and you can compare branches using the green &amp;quot;Compare&amp;quot; button to the left of the &amp;quot;Branch&amp;quot; menu.&lt;br /&gt;
&lt;br /&gt;
=== Cleaning up your branch ===&lt;br /&gt;
&lt;br /&gt;
Before filing your pull request, if, looking at the diffs and the history (the list of commits) for your topic branch, you saw anything confusing or not quite right, now is your opportunity to change it.&lt;br /&gt;
&lt;br /&gt;
From the &amp;lt;cite&amp;gt;gitref.org&amp;lt;/cite&amp;gt; guide, you should know how to add more commits, and you should know that you can use &amp;quot;&amp;lt;kbd&amp;gt;reset&amp;lt;/kbd&amp;gt;&amp;quot; to go back in time and redo things.&lt;br /&gt;
&lt;br /&gt;
&amp;quot;'''&amp;lt;kbd&amp;gt;reset&amp;lt;/kbd&amp;gt;'''&amp;quot; is especially good if your last commit was too big and you want to break it up into a series of smaller commits -- the command &amp;quot;&amp;lt;kbd&amp;gt;git reset &amp;quot;@~&amp;quot;&amp;lt;/kbd&amp;gt;&amp;quot; will leave your working directory the same, but jump back in time one commit and unstage all of those changes, so you can add a smaller subset of the files, commit those, then add the others, etc.&lt;br /&gt;
&lt;br /&gt;
More generally, you can use &amp;quot;'''&amp;lt;kbd&amp;gt;git reflog&amp;lt;/kbd&amp;gt;'''&amp;quot; to see how to reset back over any number of commits or other &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt; operations. &lt;br /&gt;
&lt;br /&gt;
You can also use &amp;quot;'''&amp;lt;kbd&amp;gt;git commit --amend&amp;lt;/kbd&amp;gt;'''&amp;quot; to edit the commit message of the most recent commit.&lt;br /&gt;
&lt;br /&gt;
There are several more advanced cleanup features available with &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;, but we'll defer any further discussion of them.&lt;br /&gt;
&lt;br /&gt;
Every time you make changes, you should to push them to your fork to keep it up-to-date. If you rewrote your commit history, then the push would be rejected, because the commit histories won't match. Therefore, to push a rewritten history, you must '''''&amp;lt;strong&amp;gt;force push&amp;lt;/strong&amp;gt;''''', which will -- &amp;lt;strong&amp;gt;this is a potentially dangerous operation!&amp;lt;/strong&amp;gt; -- discard the old commit history and replace it with the new history:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
          &lt;br /&gt;
         &lt;br /&gt;
                .--&amp;gt; origin (fork)&lt;br /&gt;
               /&lt;br /&gt;
              /&lt;br /&gt;
     local --'&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push --force origin new-feature&lt;br /&gt;
&lt;br /&gt;
You can and should do this throughout your development if you want to look at the diffs of your changes as you work -- after all, the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; code-base is vast and it is easy to forget exactly where you are in your project. You can and should keep cleaning up in this way until you are satisfied with the result. Doing this, your GitHub fork ends up being rather like a personal Web-based IDE plug-in or extension to help you with development.&lt;br /&gt;
&lt;br /&gt;
=== Filing a pull request ===&lt;br /&gt;
&lt;br /&gt;
When you finish working on your feature or bug fix, select your topic branch on your fork (with the &amp;quot;Branch&amp;quot; menu), and click the green button to file a pull request. By default, the target of the pull request -- the repository and branch into which it is requesting that your changes be pulled -- will be &amp;quot;&amp;lt;samp&amp;gt;wesnoth:master&amp;lt;/samp&amp;gt;&amp;quot;, the &amp;lt;code&amp;gt;master&amp;lt;/code&amp;gt; branch of the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository.&lt;br /&gt;
&lt;br /&gt;
The message that you enter for the pull request should become the commit message of the merge operation performed in the upstream repository if the pull request is granted. (Note: if you are granting someone's PR through the GitHub Web interface, please ensure that this happens.)&lt;br /&gt;
&lt;br /&gt;
If you fixed a bug, you should say, e.g., &amp;quot;Fixed bug #5678&amp;quot; in the pull-request message, which should automatically link to [https://gna.org/bugs/index.php?group=wesnoth&amp;amp;set=custom&amp;amp;report_id=101&amp;amp;status_id=1&amp;amp;chunksz=150&amp;amp;boxoptionwanted=1 our Gna! bug tracker].&lt;br /&gt;
&lt;br /&gt;
If you want more information, you could read [https://help.github.com/articles/creating-a-pull-request/ GitHub's &amp;quot;&amp;lt;cite&amp;gt;Creating a pull request&amp;lt;/cite&amp;gt;&amp;quot; help article].&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream &amp;lt;-.&lt;br /&gt;
                \&lt;br /&gt;
                 \&lt;br /&gt;
                  '- origin (fork)&lt;br /&gt;
  &lt;br /&gt;
  &lt;br /&gt;
     local     &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
You should then see your pull request in [https://github.com/wesnoth/wesnoth/pulls the main &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository's &amp;quot;pull requests&amp;quot; page].&lt;br /&gt;
&lt;br /&gt;
At the time of writing this, we also have configured [https://travis-ci.org Travis CI], a [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] system, to automatically try to compile &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; with your changes, to make sure that it still works before your pull request is granted. However, it is not mandatory for the Travis build to complete successfully for the pull request to be granted. Additionally, you may still make changes to your pull request by pushing more changes to your topic branch in your fork, after which Travis &amp;lt;em&amp;gt;should&amp;lt;/em&amp;gt; try to compile the updated topic branch. You can even still force push to erase the content of the topic branch (on which the pull request is based) and replace it with new content -- however, you shouldn't file a pull request for a topic branch until you are ready for it to be merged.&lt;br /&gt;
&lt;br /&gt;
Now, wait for a member of the development team to review your pull request. You can often find someone on the development [/Support#IRC IRC] channel, &amp;lt;code&amp;gt;#wesnoth-dev&amp;lt;/code&amp;gt;. Additionally, developers may comment directly on your pull request with questions, so you should check it periodically.&lt;br /&gt;
&lt;br /&gt;
=== Cleaning up at the end ===&lt;br /&gt;
&lt;br /&gt;
Congratulations, a developer granted your pull request! Now it's time to clean up and update your local repository.&lt;br /&gt;
&lt;br /&gt;
On the GitHub page for your pull request, you should now see a button with the option &amp;quot;delete this branch&amp;quot;. Since the content of new-feature is now merged into master, this branch no longer needs to exist as you won't work on it anymore, and future work will go onto a different branch. So you should delete it, which will delete the branch on *origin*, your github-associated repo.&lt;br /&gt;
&lt;br /&gt;
Since master has now changed and we want master to be synced up, you should now do step 1 again:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |&lt;br /&gt;
       |&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |          &lt;br /&gt;
       v      &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git checkout master&lt;br /&gt;
  git pull upstream master&lt;br /&gt;
&lt;br /&gt;
At this point git will understand that new-feature has been merged into master, so when you ask to delete this branch from local as well, it will do it:&lt;br /&gt;
&lt;br /&gt;
  git branch -d new-feature&lt;br /&gt;
&lt;br /&gt;
If you do these steps out of order, i.e. try to delete the branch before before syncing master, it will make a warning &amp;quot;Are you sure? You have unmerged changes on this branch...&amp;quot; etc.&lt;br /&gt;
&lt;br /&gt;
Finally, sync master on the origin as well:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
          &lt;br /&gt;
          &lt;br /&gt;
                     origin (fork)&lt;br /&gt;
               /--&amp;gt;  &lt;br /&gt;
            --/    &lt;br /&gt;
     local     &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  git push origin master&lt;br /&gt;
&lt;br /&gt;
That's the end of the development cycle, and now you can begin on your next patch. Note that throughout the cycle, information only flowed counter-clockwise:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
    upstream&lt;br /&gt;
       |     &amp;lt;--\&lt;br /&gt;
       |         \--&lt;br /&gt;
       |             origin (fork)&lt;br /&gt;
       |       /--&amp;gt;  &lt;br /&gt;
       v    --/    &lt;br /&gt;
     local&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If for some reason you find yourself doing something where information is flowing the other way, that is a good sign that something is going wrong, at least as far as this guide is concerned! (The exception is the steps in which we set up our repos -- don't overthink this.)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Advanced / Alternative workflows ==&lt;br /&gt;
&lt;br /&gt;
You can use pull requests as described above whether you have commit access or not -- if you have commit access, then you can click to accept your own pull requests.&lt;br /&gt;
&lt;br /&gt;
However, if you have commit access, you may prefer not to use github / pull requests at all, and instead to push directly to wesnoth:master. You can still use topic branches to hold your work, and merge them to your local master using git merge, then use 'git push upstream master' to push them to the main wesnoth repo. &lt;br /&gt;
&lt;br /&gt;
If you are lazy, you might even skip making a topic branch and just commit to local master, although IMO this can make things more confusing if you get a merge conflict later.&lt;br /&gt;
&lt;br /&gt;
Either way, afaik the vast majority of wesnoth developers prefer to push directly to wesnoth:master.&lt;br /&gt;
&lt;br /&gt;
An extreme option appropriate for small changes is to skip the local repo as well, and simply commit changes directly from the github web interface. This might be appropriate for example if you forgot to commit a changelog entry in an earlier patch, or are simply changing some numbers used as parameters somewhere. Obviously if you change source code this way, you should make certain that everything still compiles immediately after! (Note: Don't actually do that.)&lt;br /&gt;
&lt;br /&gt;
== The ultimate cleanup power tool: git rebase ==&lt;br /&gt;
&lt;br /&gt;
Using things in the gitref guide, you can see how to use reset to undo mistakes you made by backing up and trying again, and for small commits that is probably fine. However, if you have a large and complicated series of changes, the better way to do this is using git rebase. Using git rebase in interactive mode, you can rewrite history by&lt;br /&gt;
&lt;br /&gt;
* reordering your commits&lt;br /&gt;
* discarding unwanted commits&lt;br /&gt;
* squashing commits together&lt;br /&gt;
* editing the content changes represented by an individual commit&lt;br /&gt;
* editing the commit message&lt;br /&gt;
&lt;br /&gt;
For our purposes, we assume you are working on a topic branch, and then you will only need to use the form&lt;br /&gt;
&lt;br /&gt;
  git rebase -i master&lt;br /&gt;
&lt;br /&gt;
You can see some documentation for using this command here: https://help.github.com/articles/interactive-rebase&lt;br /&gt;
&lt;br /&gt;
Using 'git rebase', you can make your commit history very *clean* -- instead of the history saying &amp;quot;I tried a bunch of things, undid some of them, tried some other things, and found something I liked&amp;quot;, your commit history can basically be &amp;quot;I took the simplest and most logical route to the solution that was finally the best&amp;quot;. When you review your commits, instead of feeling like a nasty blood-and-elbow-grease engineering project, it should feel like folding a perfect origami crane, to the extent possible ;)&lt;br /&gt;
&lt;br /&gt;
But to reiterate, this has a purpose. &lt;br /&gt;
# Other devs need to be able to understand the history.&lt;br /&gt;
# It should be possible to jump back in time by checking out one of your commits and find ourselves in a sensible state when we do so.&lt;br /&gt;
# If something breaks or some feature become incompatible, it should be possible to roll back only a piece of the implementation of your feature without removing the whole thing.&lt;br /&gt;
&lt;br /&gt;
If you want to use rebase to cleanup your history, it is important to do it *before* it is pulled into wesnoth, as once that happens it is basically no longer possible. If we rewrite history in the main wesnoth repo, then afterwards whenever any dev tries to 'git pull upstream master', their git will give them strange merge errors, stemming from the incompatible history, and then they will become nervous, jump on irc and exclaim some variation of &amp;quot;omg wtf bbq&amp;quot;. So except in extreme circumstances, we will never rebase the main wesnoth master, and for the same reason, we will never use &amp;quot;git push --force upstream master&amp;quot;. That's why if you want to do these things, it is important to do them on your *fork* before it makes it onto master.&lt;br /&gt;
&lt;br /&gt;
If you feel like it, you might read this, which is a historical email between early users / developers of git, in which Linus Torvalds explains about shared history of repos and when it is appropriate to use git rebase. &lt;br /&gt;
&lt;br /&gt;
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html&lt;br /&gt;
&lt;br /&gt;
When you become comfortable with git rebase -i, it will greatly improve your workflow, as you will know that you can easily review and revise commit messages later, and easily reorder and squash commits. Typically I will now commit every single time I compile, and even if it is a commit which e.g. fixes a compile time error, or for some other reason I know it will be squashed in somewhere else, I give it the commit message &amp;quot;fixup&amp;quot;, as a note to myself to mark it thusly in the first git rebase pass. (Actually, while writing this I have just learned about the --autosquash feature of git rebase which takes this idea further, good stuff there.)&lt;br /&gt;
&lt;br /&gt;
Note that unlike Linus and github, in this guide we aren't thinking about your github fork repo as public -- we prefer to think of it as your personal private IDE/tool as I described earlier. If other wesnoth devs are cloning it or pulling your topic branches, we assume you will work it out with them. With that caveat the philosophies expressed on github and by Linus should generally apply to the wesnoth project as well.&lt;br /&gt;
&lt;br /&gt;
=== Solving merge conflicts with git rebase ===&lt;br /&gt;
&lt;br /&gt;
Github version: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request&lt;br /&gt;
&lt;br /&gt;
Suppose that you modify a file in the same place as someone else, and their change gets merged before yours. If git can't figure out how to merge, then someone will have to fix it. This could be done by whoever is merging the new content into master, but if you don't have commit access then that person is not you. One way that *you* could fix it is to resync your master to get the new changes locally, and then rebase your topic branch so that your changes are applied *after* the most recent changes.&lt;br /&gt;
&lt;br /&gt;
  git rebase master&lt;br /&gt;
&lt;br /&gt;
To understand what is happening, we should understand a bit more about how git works. Intuitively, git is all about &amp;quot;snapshots&amp;quot; of the project content. Every commit represents a snapshot, and you can look at this snapshot by checking out the commit. However git does not store each snapshot separately -- instead git defines the snapshots in terms of one another, and stores only the diffs. When you rebase your topic branch onto master, this will also update the &amp;quot;point of departure&amp;quot; where your branch was created, so that in the history, it will depart from the current head of master with the most recent changes. (Obviously, if you don't sync master until you are done working, then this subtlety to 'git rebase' is irrelevant.) &lt;br /&gt;
&lt;br /&gt;
If merging your branch with the current master would create a conflict, then when git rebase gets to the commit that creates the conflict, it will get confused when it tries to apply that diff, stop, tell you about the problem, and ask you to resolve it -- you can open up the offending file and go to the point where the conflict is happening, and git will leave a note for you of the content it is having trouble with. The note will look similar to what happens in the gitref guide here, under &amp;quot;merge conflicts&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
http://gitref.org/branching/#merge&lt;br /&gt;
&lt;br /&gt;
You just have to remove the note, make the file look like it should to make everything compatible, and type&lt;br /&gt;
&lt;br /&gt;
  git add .&lt;br /&gt;
  git rebase --continue&lt;br /&gt;
&lt;br /&gt;
Then the rebasing process will continue, and at the end your branch should be compatible with master and ready to be merged in.&lt;br /&gt;
&lt;br /&gt;
You can read more about this aspect of git rebase here if you like, although most likely you won't actually need more than we just talked about for wesnoth development. &lt;br /&gt;
&lt;br /&gt;
http://git-scm.com/book/en/Git-Branching-Rebasing&lt;br /&gt;
&lt;br /&gt;
That's all for this guide, have fun hacking on wesnoth!&lt;br /&gt;
&lt;br /&gt;
== Addendum ==&lt;br /&gt;
The following section contains commands with the -f / --force options. Those are usually used to rewrite history, which is fine for your own fork but disallowed for upstream. Do not use them on the main repository.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
control with which repo you interact&lt;br /&gt;
        git remote -v&lt;br /&gt;
 &lt;br /&gt;
  upstream should be      git@github.com:wesnoth/wesnoth.git&lt;br /&gt;
  origin should be        git@github.com:your_name/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
if a command goes awry, you can go to &amp;quot;git reflog&amp;quot;, find the point just before you typed it, and reset --hard to that commit, and it should be like the bad thing never happened&lt;br /&gt;
 &lt;br /&gt;
revert every file in the repo to look like it did at the HEAD commit (last successful sync)&lt;br /&gt;
        git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
get a clean slate by syncing with upstream&lt;br /&gt;
        git fetch upstream&lt;br /&gt;
        git checkout -B master upstream/master&lt;br /&gt;
        git push --force origin master&lt;br /&gt;
if this errors, try again after&lt;br /&gt;
        git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
undo n commits, split/squash and apply again&lt;br /&gt;
        git reset HEAD~n&lt;br /&gt;
        git add -p&lt;br /&gt;
        git commit&lt;br /&gt;
        git push -f&lt;br /&gt;
&lt;br /&gt;
You can also push from one ‘ref’ to a different one: &lt;br /&gt;
        $ git push &amp;lt;remote&amp;gt; &amp;lt;from&amp;gt;:&amp;lt;to&amp;gt;&lt;br /&gt;
&lt;br /&gt;
completely overwrite branch b with a (from a to b)&lt;br /&gt;
        git push -f origin a:b&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
before any commit:&lt;br /&gt;
&lt;br /&gt;
* if the diff shows an invisible change in the first line - stop! Fix the file encoding back to UTF8 without BOM.&lt;br /&gt;
 &lt;br /&gt;
* don't forget the changelog (and, for visible changes, the players_changelog)&lt;br /&gt;
 &lt;br /&gt;
* try to keep the summary at 50 characters or less, maximum 72&amp;lt;br&amp;gt;commit meter in units of 10 chars:&lt;br /&gt;
 '         |         |         |         |         | 50 character summary limit&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[Project#Developers]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56595</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56595"/>
		<updated>2015-07-25T21:33:15Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Download */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Technical aside: Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56594</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56594"/>
		<updated>2015-07-25T21:31:22Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Are you a newcomer to Git who would like to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;?|If so, you may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read -- while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
{{SideBox|heading=Want a {{abbr|GUI|Graphical User Interface}} for Git?|[https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|heading=Git transport protocols|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;em&amp;gt;&amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt;&amp;lt;/em&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (&amp;lt;em&amp;gt;check the commit hashes!&amp;lt;/em&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56593</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56593"/>
		<updated>2015-07-25T21:29:46Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: 1.03125rem; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56592</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56592"/>
		<updated>2015-07-25T21:27:24Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|3}}} style=&amp;quot;font-size: large; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|3}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56591</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56591"/>
		<updated>2015-07-25T21:27:11Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|4}}} style=&amp;quot;font-size: large; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|4}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56590</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56590"/>
		<updated>2015-07-25T21:24:00Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: large; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56589</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56589"/>
		<updated>2015-07-25T21:22:45Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: 1.25em; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56588</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56588"/>
		<updated>2015-07-25T21:22:37Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: 1.25rem; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56587</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56587"/>
		<updated>2015-07-25T21:22:30Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: 1.5rem; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56586</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56586"/>
		<updated>2015-07-25T21:22:21Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: 1.5em; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56585</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56585"/>
		<updated>2015-07-25T21:17:43Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: larger; padding: 0; color: #212121;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56584</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56584"/>
		<updated>2015-07-25T21:17:28Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: larger; padding: 0; color: #263238;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56583</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56583"/>
		<updated>2015-07-25T21:16:33Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;h{{{headinglvl|6}}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/h{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56582</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56582"/>
		<updated>2015-07-25T21:16:14Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;{{{headinglvl|6}}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/{{{headinglvl|6}}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56581</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56581"/>
		<updated>2015-07-25T21:15:04Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56580</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56580"/>
		<updated>2015-07-25T21:14:17Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|! &amp;lt;{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;foo&amp;lt;/{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}}&amp;gt;&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56579</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56579"/>
		<updated>2015-07-25T21:14:00Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|{{!}} foo&lt;br /&gt;
{{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56578</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56578"/>
		<updated>2015-07-25T21:13:17Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|{{!}} foo|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56577</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56577"/>
		<updated>2015-07-25T21:13:07Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}}|{{!}} foo {{!}}|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Examples:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56576</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56576"/>
		<updated>2015-07-25T21:12:10Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}} | {{!}} foo {{!}}- |}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&lt;br /&gt;
Example side-box:&lt;br /&gt;
{{SideBox|Lorem ipsum dolor sit amet.}}&lt;br /&gt;
&lt;br /&gt;
Example side-box with a heading:&lt;br /&gt;
{{SideBox|heading=Lorem ipsum|Dolor sit amet.}}&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56575</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56575"/>
		<updated>2015-07-25T21:09:55Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}} | {{!}} foo {{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56574</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56574"/>
		<updated>2015-07-25T21:07:30Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}} | ! &amp;lt;{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;foo&amp;lt;/{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}}&amp;gt; {{!}}-|}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56573</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56573"/>
		<updated>2015-07-25T21:05:12Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}} | ! &amp;lt;{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}} style=&amp;quot;font-size: larger; padding: 0;&amp;quot;&amp;gt;{{{heading}}}&amp;lt;/{{#if:{{{headinglvl|}}}|h{{{headinglvl|6}}}|b}}&amp;gt; {{!}}- |}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56572</id>
		<title>Template:SideBox</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:SideBox&amp;diff=56572"/>
		<updated>2015-07-25T21:02:34Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{| style=&amp;quot;float: {{{side|right}}}; max-width: {{{width|43.75%}}}; margin: 0 {{#ifeq: {{{side|right}}} | right | 0 1em 1em | 1em 1em 0}}; padding: .5em; border: 1px solid #AAA; background-color: #FAF3E9; {{{style|}}}&amp;quot;&lt;br /&gt;
{{#if: {{{heading|}}} | {{!}} foo |}}&lt;br /&gt;
| {{{1}}}&lt;br /&gt;
|}&amp;lt;noinclude&amp;gt;&lt;br /&gt;
This template is intended to provide standardization and consistency in the appearance of side-boxes.&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56571</id>
		<title>Template:FeaturedURL</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56571"/>
		<updated>2015-07-25T20:52:55Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;div style=&amp;quot;text-align: center; margin: 1.25em 0 2em;&amp;quot;&amp;gt;'''[{{{1}}} &amp;lt;{{{1}}}&amp;gt;]'''&amp;lt;/div&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56570</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56570"/>
		<updated>2015-07-25T20:52:43Z</updated>

		<summary type="html">&lt;p&gt;8680: Undo revision 56569 by 8680 (talk)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56569</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56569"/>
		<updated>2015-07-25T20:52:18Z</updated>

		<summary type="html">&lt;p&gt;8680: Undo revision 56568 by 8680 (talk)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56568</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56568"/>
		<updated>2015-07-25T20:51:56Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56567</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56567"/>
		<updated>2015-07-25T20:51:24Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56566</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56566"/>
		<updated>2015-07-25T20:50:56Z</updated>

		<summary type="html">&lt;p&gt;8680: /* Browse the code */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56565</id>
		<title>Template:FeaturedURL</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56565"/>
		<updated>2015-07-25T20:50:45Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;div style=&amp;quot;text-align: center; margin: 1.25em 0 1.75em;&amp;quot;&amp;gt;'''[{{{1}}} &amp;lt;{{{1}}}&amp;gt;]'''&amp;lt;/div&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56564</id>
		<title>Template:FeaturedURL</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56564"/>
		<updated>2015-07-25T20:50:30Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;div style=&amp;quot;text-align: center; margin: 1.25em 0 1.5em;&amp;quot;&amp;gt;'''[{{{1}}} &amp;lt;{{{1}}}&amp;gt;]'''&amp;lt;/div&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56563</id>
		<title>Template:FeaturedURL</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56563"/>
		<updated>2015-07-25T20:49:40Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;div style=&amp;quot;text-align: center; margin: .5em 0 1.5em;&amp;quot;&amp;gt;'''[{{{1}}} &amp;lt;{{{1}}}&amp;gt;]'''&amp;lt;/div&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56562</id>
		<title>Template:FeaturedURL</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=Template:FeaturedURL&amp;diff=56562"/>
		<updated>2015-07-25T20:49:22Z</updated>

		<summary type="html">&lt;p&gt;8680: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;div style=&amp;quot;text-align: center; margin: .5em 0 1em;&amp;quot;&amp;gt;'''[{{{1}}} &amp;lt;{{{1}}}&amp;gt;]'''&amp;lt;/div&amp;gt;&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56561</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56561"/>
		<updated>2015-07-25T20:47:20Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;] is cross-platform and supposedly powerful, and the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56560</id>
		<title>WesnothRepository</title>
		<link rel="alternate" type="text/html" href="https://wiki.wesnoth.org/index.php?title=WesnothRepository&amp;diff=56560"/>
		<updated>2015-07-25T20:39:30Z</updated>

		<summary type="html">&lt;p&gt;8680: /* What is Git? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Compiling Wesnoth}}&lt;br /&gt;
&lt;br /&gt;
'''The &amp;lt;cite&amp;gt;Battle for Wesnoth&amp;lt;/cite&amp;gt; code-base''' is stored in a '''&amp;lt;dfn&amp;gt;version control repository&amp;lt;/dfn&amp;gt;'''. Version control allows the entire development team to edit files concurrently. The version control software tracks revisions, stores a record of all edits, and prevents simultaneous editing from causing clashes. All changes are stored in the version control repository.&lt;br /&gt;
&lt;br /&gt;
When a release is planned, the current set of the files in the repository is ''&amp;quot;frozen&amp;quot;'', given a version number, and shipped out to the world at large. Then, as files continue to be edited by the developers, the repository code advances past that point. The repository (or &amp;quot;'''&amp;lt;dfn&amp;gt;repo&amp;lt;/dfn&amp;gt;'''&amp;quot;) version is by definition the most up-to-date version of the code.&lt;br /&gt;
&lt;br /&gt;
The &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository is a '''Git''' repository and is hosted on '''GitHub''':&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== What is &amp;lt;cite&amp;gt;Git&amp;lt;/cite&amp;gt;? ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div style=&amp;quot;float:right; max-width: 43.75%;&amp;quot;&amp;gt;&lt;br /&gt;
{{SideBox|width=100%|'''Newcomers to Git who want to work on &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;''' may find iceiceice's &amp;lt;cite&amp;gt;[[Git for Wesnoth Crash Course]]&amp;lt;/cite&amp;gt; to be a useful read (while &amp;lt;cite&amp;gt;WesnothRepository&amp;lt;/cite&amp;gt; is also beginner-focused, it's not as extensive as iceiceice's &amp;lt;cite&amp;gt;Crash Course&amp;lt;/cite&amp;gt;).}}&lt;br /&gt;
&lt;br /&gt;
{{SideBox|width=100%|'''Want a {{abbr|GUI|Graphical User Interface}} for Git?''' You can try the official Git programs &amp;lt;cite&amp;gt;git-gui&amp;lt;/cite&amp;gt; and &amp;lt;cite&amp;gt;gitk&amp;lt;/cite&amp;gt;, or the third-party [https://www.syntevo.com/smartgit/ &amp;lt;cite&amp;gt;SmartGit&amp;lt;/cite&amp;gt;]; also, the {{abbr|IDEs|Integrated Development Environments}} [https://www.qt.io/download-open-source/ &amp;lt;cite&amp;gt;Qt Creator&amp;lt;/cite&amp;gt;] and &amp;lt;cite&amp;gt;Microsoft Visual Studio&amp;lt;/cite&amp;gt; provide Git GUIs. &amp;lt;strong&amp;gt;However&amp;lt;/strong&amp;gt;, the official Git command-line program is by far the easiest to get help with -- you may have trouble finding people who can help you with a Git GUI.}}&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Git is the most widely used open-source version-control system. You can learn more about it at its website:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://git-scm.com}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Git replaced '''Subversion (&amp;lt;dfn&amp;gt;SVN&amp;lt;/dfn&amp;gt;)''' as &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt;'s version-control system in March 2013. Subversion had, itself, previously replaced an older program, '''Concurrent Versioning System (&amp;lt;dfn&amp;gt;CVS&amp;lt;/dfn&amp;gt;)''', in 2005. These earlier systems have left a few traces in the version history which you might encounter; some older documentation and a few files refer to them.&lt;br /&gt;
&lt;br /&gt;
== Browse the code ==&lt;br /&gt;
&lt;br /&gt;
There are currently two main streams of development (&amp;quot;&amp;lt;dfn&amp;gt;branches&amp;lt;/dfn&amp;gt;&amp;quot;): the '''master''' branch (1.13.x), and the '''stable''' branch (1.12.x). (1.10.x is now '''oldstable'''.) Most other branches are only used for a short time to do some testing without disturbing the main development.&lt;br /&gt;
&lt;br /&gt;
You can use a Web browser to view the source code at the following Web address:&lt;br /&gt;
&lt;br /&gt;
{{FeaturedURL|https://github.com/wesnoth/wesnoth}}&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
&lt;br /&gt;
To '''''clone''''' a copy of the repository into a directory named &amp;quot;''wesnoth''&amp;quot;, run this command:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
{{SideBox|style=font-size:.75em;line-height:1.6|There are other '''&amp;lt;dfn&amp;gt;transport protocols&amp;lt;/dfn&amp;gt;''', in addition to '''Hypertext Transfer Protocol Secure (&amp;lt;dfn&amp;gt;HTTPS&amp;lt;/dfn&amp;gt;)''', over which one can clone a Git repository from GitHub, including:&lt;br /&gt;
&lt;br /&gt;
* '''Secure Shell (&amp;lt;dfn&amp;gt;SSH&amp;lt;/dfn&amp;gt;)''' (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;, or &amp;quot;&amp;lt;code&amp;gt;git@github.com:wesnoth/wesnoth.git&amp;lt;/code&amp;gt;&amp;quot;), which provides a bit more security, and can be more convenient for developers, but needs to be set up first (see the &amp;quot;Push access&amp;quot; section, below).&lt;br /&gt;
* Git's '''native transport''' protocol (&amp;quot;&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;git://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&amp;quot;), which &amp;lt;em&amp;gt;may&amp;lt;/em&amp;gt; be somewhat faster than HTTPS (though GitHub uses a faster '''&amp;quot;smart&amp;quot; HTTPS''' transport), but is &amp;lt;strong&amp;gt;insecure&amp;lt;/strong&amp;gt; and should be used (if one &amp;lt;em&amp;gt;must&amp;lt;/em&amp;gt; use it) with caution (check the commit hashes!).&lt;br /&gt;
&lt;br /&gt;
'''A more detailed explanation''' is available [https://gist.github.com/grawity/4392747 here].}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;small style=&amp;quot;font-size: 95%&amp;quot;&amp;gt;('''Note:''' the &amp;quot;'''&amp;gt;'''&amp;quot; sigil represents a command prompt; '''don't type it in'''.)&amp;lt;/small&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== FAQ ===&lt;br /&gt;
&lt;br /&gt;
'''Q: The repository is about three gigabytes large, and my Internet connection is not stable enough to reliably download it. What should I do?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' https://stackoverflow.com/questions/9268378/how-do-i-clone-a-large-git-repository-on-an-unreliable-connection&lt;br /&gt;
&lt;br /&gt;
# Use a download manager to download the directory &amp;quot;https://github.com/wesnoth/wesnoth.git&amp;quot;, in one or more sessions.&lt;br /&gt;
# Put this &amp;quot;''wesnoth.git''&amp;quot; directory, which is the internals of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repository, in a new, empty directory.&lt;br /&gt;
# Rename the &amp;quot;''wesnoth.git''&amp;quot; directory to &amp;quot;''.git''&amp;quot;.&lt;br /&gt;
# Finally, run these commands in the directory that contains the &amp;quot;''.git''&amp;quot; directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add remote &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
 '''&amp;gt;''' git reset --hard HEAD&lt;br /&gt;
&lt;br /&gt;
The first command links your local repository to the upstream repository; the second &amp;lt;dfn&amp;gt;checks out&amp;lt;/dfn&amp;gt; a &amp;lt;dfn&amp;gt;working tree&amp;lt;/dfn&amp;gt; (i.e., copies the files out of the &amp;quot;''.git''&amp;quot; directory into a form that you can use).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Q: I don't want any alternate branches or repository history. How could I avoid downloading that?'''&lt;br /&gt;
&lt;br /&gt;
'''A:''' This simply requires a more elaborate command. For example, to only download the last revision of the 1.12 branch, and store it in a directory named &amp;quot;''wesnoth-1.12-single-branch-test''&amp;quot;:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
Example results:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone --branch 1.12 --single-branch --depth 1 &amp;quot;&amp;lt;nowiki&amp;gt;https://github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth-1.12-single-branch-test&lt;br /&gt;
 Cloning into 'wesnoth-1.12-single-branch-test'...&lt;br /&gt;
 remote: Counting objects: 18725, done.&lt;br /&gt;
 remote: Compressing objects: 100% (17541/17541), done.&lt;br /&gt;
 remote: Total 18725 (delta 1571), reused 7397 (delta 1004)&lt;br /&gt;
 Receiving objects: 100% (18725/18725), 376.17 MiB | 171.00 KiB/s, done.&lt;br /&gt;
 Resolving deltas: 100% (1571/1571), done.&lt;br /&gt;
 Checking connectivity... done.&lt;br /&gt;
 Checking out files: 100% (18593/18593), done.&lt;br /&gt;
 '''&amp;gt;''' du -sh wesnoth-1.12-single-branch-test ''# &amp;quot;du&amp;quot; means &amp;quot;disk usage&amp;quot;.''&lt;br /&gt;
 1.1G	wesnoth-1.12-single-branch-test&lt;br /&gt;
&lt;br /&gt;
However, for development and testing, it is often better to have some of the repository history, so that you can quickly check out older versions of the repository to pin down a bug.&lt;br /&gt;
&lt;br /&gt;
== Push access ==&lt;br /&gt;
&lt;br /&gt;
For '''&amp;lt;dfn&amp;gt;push access&amp;lt;/dfn&amp;gt;''' (the capability to ''push'' changes from your local repository) to our ''upstream'' repository on GitHub, you must have an account on GitHub, which must be registered as part of the [https://github.com/wesnoth ''Battle for Wesnoth''] organization.&lt;br /&gt;
&lt;br /&gt;
It may be convenient to use Git's '''Secure Shell (SSH) transport protocol''', so that you needn't either enter your username and password each time you push commits, or insecurely store those credentials in an unencrypted configuration file. To use the SSH transport, you will need to generate an SSH '''''key pair''''' with a command like (on Unix descendent operating systems, including Linux distributions and Apple OS X, at least) this:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' ssh-keygen -t rsa -b 15360 -f &amp;quot;&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&amp;quot; -C &amp;quot;&amp;lt;var&amp;gt;&amp;lt;your name&amp;gt;&amp;lt;/var&amp;gt;'s SSH key for GitHub&amp;quot;&lt;br /&gt;
&lt;br /&gt;
On a typical Linux distribution or on Apple OS X, &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt; would be, e.g., &amp;quot;''~/.ssh/id-key-for-github''&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;strong&amp;gt;Note&amp;lt;/strong&amp;gt; that generating an SSH key pair can potentially take a while and be fairly CPU-intensive.&lt;br /&gt;
&lt;br /&gt;
Once you have generated an SSH key pair, put the following into your SSH configuration file (on Unix descendent systems, this is generally &amp;quot;''~/.ssh/config''&amp;quot;):&lt;br /&gt;
&lt;br /&gt;
 Host github.com&lt;br /&gt;
 	IdentityFile &amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then register the key with GitHub, by going to [https://github.com/settings/ssh &amp;lt;https://github.com/settings/ssh&amp;gt;], selecting &amp;quot;Add SSH key&amp;quot;, and pasting the contents of the '''''public key''''' file (&amp;lt;var&amp;gt;&amp;lt;file&amp;gt;&amp;lt;/var&amp;gt;, but with a &amp;quot;''.pub''&amp;quot; extension) into the &amp;quot;Key&amp;quot; field.&lt;br /&gt;
&lt;br /&gt;
Then, if you have not yet cloned the repository, clone it via SSH:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git clone &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot; wesnoth&lt;br /&gt;
&lt;br /&gt;
If you have already cloned the repository, you can set it to use SSH transfer:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote set-url origin &amp;quot;&amp;lt;nowiki&amp;gt;ssh://git@github.com/wesnoth/wesnoth.git&amp;lt;/nowiki&amp;gt;&amp;quot;&lt;br /&gt;
&lt;br /&gt;
=== Force-pushing policy ===&lt;br /&gt;
&lt;br /&gt;
A '''&amp;lt;dfn&amp;gt;forced push&amp;lt;/dfn&amp;gt;''' rewrites a branch tip to point to a new commit without checking first whether the new commit is a descendant of the current tip. This effectively allows you to rewrite the commit history of a branch, which may be useful when working with pull requests from your own [[#Push_to_your_own_fork|personal fork]].&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push --force fork &amp;lt;var&amp;gt;&amp;lt;branch name&amp;gt;&amp;lt;/var&amp;gt;&lt;br /&gt;
&lt;br /&gt;
However, for a public repository depended upon by more than a handful people like any of the &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories at [https://github.com/wesnoth &amp;lt;https://github.com/wesnoth&amp;gt;], force-pushing becomes a serious inconvenience that may have negative consequences in some cases, if history is lost in the process. For this reason, &amp;lt;strong&amp;gt;force-pushing to the upstream &amp;lt;cite&amp;gt;Wesnoth&amp;lt;/cite&amp;gt; repositories is &amp;lt;em&amp;gt;NOT allowed&amp;lt;/em&amp;gt; unless specifically authorized by the repository administrators in order to resolve an urgent issue&amp;lt;/strong&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Update ==&lt;br /&gt;
&lt;br /&gt;
Do this from inside the ''wesnoth'' directory:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git pull&lt;br /&gt;
&lt;br /&gt;
== Reviewing your changes ==&lt;br /&gt;
&lt;br /&gt;
Before committing, it's always wise to run:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git diff&lt;br /&gt;
&lt;br /&gt;
and look at the output. Some kinds of mistakes that are hard to see embedded in all the code you have modified are more easily spotted in the isolated diff lines.&lt;br /&gt;
&lt;br /&gt;
== Generating patches ==&lt;br /&gt;
&lt;br /&gt;
Under Git on a Unix-like operating system, you'll typically do&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git format-patch HEAD~1..HEAD&lt;br /&gt;
&lt;br /&gt;
or something similar; &amp;quot;HEAD~1&amp;quot; may be replaced by a hash or symbolic reference to any earlier revision. This will produce one or more patch files, numbered and ending with the extension &amp;quot;.patch&amp;quot;.  See [[PatchSubmissionGuidelines]] for more on how to get these merged into the public repository.&lt;br /&gt;
&lt;br /&gt;
== Push to your own fork ==&lt;br /&gt;
&lt;br /&gt;
If you have an account on GitHub, you can fork the repository and add your fork as a remote of your clone.&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git remote add fork git@github.com:YOUR_USERNAME/wesnoth.git&lt;br /&gt;
&lt;br /&gt;
You can then push your branches to your fork:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork branch_name&lt;br /&gt;
&lt;br /&gt;
Or, if you want to push one branch in your local repository to another in the remote repository:&lt;br /&gt;
&lt;br /&gt;
 '''&amp;gt;''' git push fork local_branch_name:remote_branch_name&lt;br /&gt;
&lt;br /&gt;
You can then create pull requests from your branches in GitHub’s Web interface.&lt;br /&gt;
&lt;br /&gt;
== See Also ==&lt;br /&gt;
&lt;br /&gt;
* [[CompilingWesnoth]]&lt;br /&gt;
* [[Git for Wesnoth Crash Course]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>8680</name></author>
		
	</entry>
</feed>