1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
5 >The Git Repository</TITLE
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
10 TITLE="Privoxy Developer Manual"
11 HREF="index.html"><LINK
14 HREF="introduction.html"><LINK
16 TITLE="Documentation Guidelines"
17 HREF="documentation.html"><LINK
20 HREF="../p_doc.css"><META
21 HTTP-EQUIV="Content-Type"
23 charset=ISO-8859-1"></HEAD
34 SUMMARY="Header navigation table"
43 >Privoxy Developer Manual</TH
51 HREF="introduction.html"
65 HREF="documentation.html"
80 >2. The Git Repository</A
83 > If you become part of the active development team, you will eventually
84 need write access to our holy grail, the Git repository. One of the
85 team members will need to set this up for you. Please read
86 this chapter completely before accessing via Git.
94 >2.1. Access to Git</A
97 > The project's Git repository is hosted at the
99 HREF="https://privoxy.org/"
103 The Git repository URL is
106 >ssh://git@git.privoxy.org:23/git/privoxy.git</TT
108 the central repository is called <TT
112 source branch is called <TT
116 within the project for target-dependent build and packaging tools, each
117 including the name of the target operating system in their name (e.g.
118 Windows, OSXPackageBuilder, debian). There is a webview of the Git
121 HREF="https://www.privoxy.org/gitweb/?p=privoxy.git;a=tree"
123 > https://www.privoxy.org/gitweb/?p=privoxy.git;a=tree</A
125 which might help with visualizing how these pieces fit together.
137 > Whilst the central repository contains only the master branch, developers
138 are of course free to create branches in their local repositories as they
139 develop features, fixes, or update the target-dependent tools. Only once
140 such changes are fully tested ought they be pushed back to the central
141 repository master branch.
144 > At one time there were two distinct branches: stable and unstable. The
145 more drastic changes were to be in the unstable branch. These branches
146 have now been merged to minimize time and effort of maintaining two
156 >2.3. Git Commit Guidelines</A
159 > The source tree is the heart of every software project. Every effort must
160 be made to ensure that it is readable, compilable and consistent at all
161 times. We expect anyone with Git access to strictly
162 adhere to the following guidelines:
165 > Basic Guidelines, for all branches:
172 > Please don't commit even
173 a small change without testing it thoroughly first. When we're
174 close to a public release, ask a fellow developer to review your
180 > Your commit message should give a concise overview of <SPAN
187 > (no big details) and <SPAN
191 >why you changed it</I
194 Just check previous messages for good examples.
199 > Don't use the same message on multiple files, unless it equally applies to
205 > If your changes span multiple files, and the code won't recompile unless
206 all changes are committed (e.g. when changing the signature of a function),
207 then commit all files one after another, without long delays in between.
208 If necessary, prepare the commit messages in advance.
213 > Before changing things on Git, make sure that your changes are in line
214 with the team's general consensus on what should be done.
219 > Note that near a major public release, we get more cautious.
220 There is always the possibility to submit a patch to the <A
221 HREF="https://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
236 SUMMARY="Footer navigation table"
247 HREF="introduction.html"
265 HREF="documentation.html"
285 >Documentation Guidelines</TD