1 <?xml version="1.0" encoding="UTF-8"?>
\r
2 <!DOCTYPE glossary SYSTEM "../dtd/dblite.dtd">
\r
4 Enter Glossary definitions in alphabetical Order!
\r
5 DocBook doesn't sort them automatically.
\r
7 <glossary id="tsvn-glossary">
\r
8 <title>Glossary</title>
\r
10 <glossterm>Add</glossterm>
\r
13 A Git command that is used to add a
\r
14 file or directory to your working tree.
\r
15 The new items are added to the repository when you commit.
\r
20 <glossterm>BASE revision</glossterm>
\r
23 The current base revision of a file or folder in your <emphasis>working tree</emphasis>.
\r
24 This is the revision the file or folder was in, when the last checkout,
\r
25 update or commit was run. The BASE revision is normally not equal to the
\r
31 <glossterm>Blame</glossterm>
\r
34 This command is for text files only, and it annotates every line to
\r
35 show the repository revision in which it was last changed, and the
\r
36 author who made that change. Our GUI implementation is called
\r
37 TortoiseGitBlame and it also shows the commit date/time and the
\r
38 log message when you hover the mouse of the revision number.
\r
43 <glossterm>Branch</glossterm>
\r
46 A term frequently used in revision control systems to describe
\r
47 what happens when development forks at a particular point and
\r
48 follows 2 separate paths. You can create a branch off the main
\r
49 development line so as to develop a new feature without rendering
\r
50 the main line unstable. Or you can branch a stable release to which
\r
51 you make only bug fixes, while new developments take place on the
\r
52 unstable trunk. In Git a branch is implemented as a
\r
53 <quote>pointer to a revision</quote>.
\r
58 <glossterm>Clone</glossterm>
\r
61 A Git command which creates a local working tree in an empty
\r
62 directory by downloading a remote repository.
\r
67 <glossterm>Cleanup</glossterm>
\r
70 Remove untracked files from the working tree.
\r
73 <emphasis>This is different to TortoiseSVN cleanup</emphasis>
\r
78 <glossterm>Commit</glossterm>
\r
81 This Git command is used to pass the changes in your local
\r
82 working tree back into the repository, creating a new repository
\r
88 <glossterm>Conflict</glossterm>
\r
91 When changes from the repository are merged with local changes,
\r
92 sometimes those changes occur on the same lines. In this case
\r
93 Git cannot automatically decide which version to use and
\r
94 the file is said to be in conflict. You have to edit the file manually
\r
95 and resolve the conflict before you can commit any further changes.
\r
100 <glossterm>Copy</glossterm>
\r
103 In a Git repository you can create a copy of a single file
\r
109 <glossterm>Delete</glossterm>
\r
112 When you delete a versioned item (and commit the change) the item
\r
113 no longer exists in the repository after the committed revision.
\r
114 But of course it still exists in earlier repository revisions,
\r
115 so you can still access it. If necessary, you can copy a deleted
\r
116 item and <quote>resurrect</quote> it complete with history.
\r
121 <glossterm>Diff</glossterm>
\r
124 Shorthand for <quote>Show Differences</quote>. Very useful when
\r
125 you want to see exactly what changes have been made.
\r
130 <glossterm>Export</glossterm>
\r
133 This command produces an compressed archive of all versioned files (of a specific revision).
\r
138 <glossterm>GPO</glossterm>
\r
141 Group policy object
\r
146 <glossterm>HEAD revision</glossterm>
\r
149 The latest revision of a file or folder in the <emphasis>repository</emphasis>.
\r
154 <glossterm>Log</glossterm>
\r
157 Show the revision history of a file or folder.
\r
158 Also known as <quote>History</quote>.
\r
163 <glossterm>History</glossterm>
\r
166 Show the revision history of a file or folder.
\r
167 Also known as <quote>Log</quote>.
\r
172 <glossterm>Merge</glossterm>
\r
175 The process by which changes from the repository are added to your
\r
176 working tree without disrupting any changes you have already made
\r
177 locally. Sometimes these changes cannot be reconciled automatically
\r
178 and the working tree is said to be in conflict.
\r
181 Merging happens automatically when you update your working tree.
\r
182 You can also merge specific changes from another branch using
\r
183 TortoiseGit's Merge command.
\r
188 <glossterm>Patch</glossterm>
\r
191 If a working tree has changes to text files only, it is possible
\r
192 to use Git's Diff command to generate a single file summary
\r
193 of those changes in Unified Diff format. A file of this type is often
\r
194 referred to as a <quote>Patch</quote>, and it can be emailed to someone
\r
195 else (or to a mailing list) and applied to another working tree.
\r
196 Someone without commit access can make changes and submit a patch
\r
197 file for an authorized committer to apply. Or if you are unsure about
\r
198 a change you can submit a patch for others to review.
\r
203 <glossterm>Repository</glossterm>
\r
206 A repository is a place where data is stored and maintained.
\r
207 A repository can be a place where multiple databases or files are located for
\r
208 distribution over a network, or a repository can be a location that is
\r
209 directly accessible to the user without having to travel across a network.
\r
210 Git is a distributed version control system.
\r
211 A Git repository does not require network to work with most operations.
\r
212 Network is required only when you need to synchronize changes with remote repositories.
\r
217 <glossterm>Resolve</glossterm>
\r
220 When files in a working tree are left in a conflicted state following
\r
221 a merge, those conflicts must be sorted out by a human using an editor
\r
222 (or perhaps TortoiseGitMerge). This process is referred to as
\r
223 <quote>Resolving Conflicts</quote>. When this is complete you can mark
\r
224 the conflicted files as being resolved, which allows them to be committed.
\r
229 <glossterm>Revert</glossterm>
\r
232 If you have made changes
\r
233 and decide you want to undo them, you can use the <quote>revert</quote>
\r
234 command to go back to the version from HEAD.
\r
239 <glossterm>Revision</glossterm>
\r
242 Every time you commit a set of changes, you create one new
\r
243 <quote>revision</quote> in the repository. Each revision represents
\r
244 the state of the repository tree at a certain point in its history.
\r
245 If you want to go back in time you can examine the repository as
\r
246 it was at revision N.
\r
249 In another sense, a revision can refer to the set of changes that
\r
250 were made when that revision was created.
\r
255 <glossterm>SVN</glossterm>
\r
258 A frequently-used abbreviation for Subversion.
\r
261 TortoiseGit provides git-svn interoperability.
\r
262 You can fetch partial or whole history from an SVN remote and store as a local git repository.
\r
263 This allows you to browse the history and create commits locally.
\r
264 You can finally commit your changes to an SVN remote.
\r
269 <glossterm>Switch/Checkout</glossterm>
\r
272 Just as <quote>Update-to-revision</quote> changes the time
\r
273 window of a working tree to look at a different point in history,
\r
274 so <quote>Switch</quote> changes the space window of a working tree
\r
275 so that it points to a different part of the repository.
\r
276 It is particularly useful when working on master and branches where
\r
277 only a few files differ. You can switch your working tree between
\r
278 the two and only the changed files will be updated.
\r
283 <glossterm>Update</glossterm>
\r
286 This Git command pulls down the latest changes from the
\r
287 repository into your working tree, merging any changes made by
\r
288 others with local changes in the working tree.
\r
293 <glossterm>Working Copy</glossterm>
\r
296 See <quote>Working Tree</quote>.
\r
301 <glossterm>Working Tree</glossterm>
\r
304 This is your local <quote>sandbox</quote>, the area where you
\r
305 work on the versioned files, and it normally resides on your
\r
306 local hard disk. You create a working tree by doing a
\r
307 <quote>Clone</quote> of a repository, and you feed your
\r
308 changes back into the repository using <quote>Commit</quote>.
\r
315 sgml-parent-document: ("book.xml" "glossary")
\r