version_control:introduction_to_version_control_systems
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
version_control:introduction_to_version_control_systems [2016/04/20 21:30] – [Basic operations with git] mithat | version_control:introduction_to_version_control_systems [2016/11/27 23:46] – mithat | ||
---|---|---|---|
Line 11: | Line 11: | ||
===== Examples ===== | ===== Examples ===== | ||
- | * [[http:// | + | * [[http:// |
- | * [[http://mercurial.selenic.com/ | + | * [[https://www.mercurial-scm.org/ |
* [[http:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
Line 27: | Line 27: | ||
===== Backing up is not a core function! ===== | ===== Backing up is not a core function! ===== | ||
- | * The primary reason for using VCS is // | + | * //The primary reason for using VCS isn' |
* The VCS you use may suck as a backup system. | * The VCS you use may suck as a backup system. | ||
* Backing up is something you may or may not get "for free." | * Backing up is something you may or may not get "for free." | ||
Line 40: | Line 40: | ||
* Early systems were based on a centralized client-server architecture. | * Early systems were based on a centralized client-server architecture. | ||
* The server holds // | * The server holds // | ||
- | | + | |
* When a user is finished editing, it is " | * When a user is finished editing, it is " | ||
- | * Only one user at a time can check out a given file. | + | * Often, only one user at a time can check out a given file. |
* CVS, SVN | * CVS, SVN | ||
===== Distributed systems ===== | ===== Distributed systems ===== | ||
- | * Distributed systems use a peer-to-peer architecture. | ||
* Replacing centralized systems. | * Replacing centralized systems. | ||
- | * Individual users have complete, fully editable repositories. | + | |
- | * Users synchronize | + | |
+ | * Users synchronize repositories with each other as needed. | ||
* Managing can be more complicated for groups, but is more flexible. | * Managing can be more complicated for groups, but is more flexible. | ||
* Can be configured to work like to a centralized system. | * Can be configured to work like to a centralized system. | ||
Line 55: | Line 55: | ||
===== Revisions ===== | ===== Revisions ===== | ||
- | * A **revision** | + | * **revision**: a snapshot of the state of a project at a given moment. |
* When a meaningful change to the code of a project is completed, a **revision** incorporating that change is **committed** (placed) into the repository. | * When a meaningful change to the code of a project is completed, a **revision** incorporating that change is **committed** (placed) into the repository. | ||
- | * Revisions are also called **commits**, **snapshots**, and **changesets**. | + | * Also called |
* If needed, differences between the most recent state and older revisions can be determined. | * If needed, differences between the most recent state and older revisions can be determined. | ||
Line 65: | Line 65: | ||
===== Branching ===== | ===== Branching ===== | ||
- | * Many VCS's facilitate | + | * **branching**: |
* A branch to test ideas that develops in parallel with the main release. | * A branch to test ideas that develops in parallel with the main release. | ||
* A branch to develop a bugfix. | * A branch to develop a bugfix. | ||
+ | * Many VCS's facilitate branching. | ||
===== Merging ===== | ===== Merging ===== | ||
- | * Many VCS's facilitate | + | * **merging**: |
- | * Applying a bugfix to the current release. | + | * Applying a security update |
- | * Applying a security update developed for a 2.0 release to the 1.0 releases. | + | * Many VCS's facilitate merging. |
===== Single-user vs. multi-user ===== | ===== Single-user vs. multi-user ===== | ||
* How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one. | * How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one. | ||
- | ===== Getting started with git ===== | + | ===== Releases and versions |
- | * [[https:// | + | * A **release** or a **version** is a revision that has has been published for general use. |
- | | + | * An arbitrary determination made by the developers, not necessarily a VCS concept. |
- | * [[https:// | + | * Typically there are several revisions |
- | * You will need to know how to open an appropriate command line interface | + | |
- | ===== Basic operations with git ===== | + | ===== Revision and version numbering |
- | * Create a repository: <code bash>git init</ | + | * A VCS typically automatically assigns identifiers to revisions. |
- | * Add a new file or the changes to an existing file to the repository: <code bash>git add {filename}</ | + | * Identifiers for releases (i.e., |
- | * Add all new and changed files to the repository: <code bash>git add *</ | + | |
- | ===== Basic operations with git ===== | + | ===== Semantic versioning |
- | * Commit the staged (" | + | * [[http://semver.org/|Semantic versioning]] summarizes a commonly used version numbering scheme. |
- | * Get status of repository: <code bash>git status</ | + | * **{major}.{minor}.{patch}** |
- | * Get history of repository: <code bash>git log</ | + | * **major**: there are incompatible API changes, |
+ | * **minor**: added functionality in a backwards-compatible manner. | ||
+ | * **patch**: backwards-compatible bug fixes. | ||
+ | * Additional labels for pre-release and build metadata. | ||
+ | * alpha, beta, release candidate. | ||
- | ===== Basic operations with git ===== | + | ===== Microsoft |
- | * Delete a file: <code bash>git rm {filename}</ | + | |
- | * Rename or move a file: <code bash>git mv {source} {destination}</ | + | |
- | * Don't use Windows' | + | |
- | ===== GUI interface ===== | + | |
- | * '' | + | |
- | * '' | + | |
- | * Other third party git tools are available. | + | |
- | + | ||
- | ===== More git stuff ===== | + | |
- | * Roger Dudler' | + | |
- | + | ||
- | ===== Revisions vs. versions ===== | + | |
- | * A revision (i.e., commit or snapshot) that has has been published for general use is a //release// or a //version//. | + | |
- | * Often //not// a VCS concept but an arbitrary determination by the developers. | + | |
- | * Typically there are several revisions (commits) between releases/ | + | |
- | + | ||
- | ===== Version numbering ===== | + | |
- | * A VCS will typically automatically assign identifiers for revisions. | + | |
- | * Identifiers for releases (i.e., the " | + | |
- | + | ||
- | ===== Version | + | |
* The Microsoft system((Microsoft, | * The Microsoft system((Microsoft, | ||
* **{major}.{minor}.{build}.{revision}** | * **{major}.{minor}.{build}.{revision}** | ||
Line 121: | Line 103: | ||
* {revision} here does not have the same meaning as // | * {revision} here does not have the same meaning as // | ||
- | ===== Version | + | ===== Microsoft version |
* Microsoft defines these as((Ibid. Emphasis added.)): | * Microsoft defines these as((Ibid. Emphasis added.)): | ||
- | * **Major**: //... different major versions are not interchangeable.// A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed. | + | * **major**: different major versions are not interchangeable. |
- | * **Minor**: //... significant enhancement with the intention of backward compatibility.// This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product. | + | * **minor**: significant enhancement with the intention of backward compatibility. |
- | * **Build**: //... a recompilation of the same source.// Different build numbers might be used when the processor, platform, or compiler changes. | + | * **build**: a recompilation of the same source. |
- | * **Revision**: //... intended to be fully interchangeable.// A higher revision number might be used in a build that fixes a security hole in a previously released assembly. | + | * **revision**: intended to be fully interchangeable. |
- | ===== Version numbering | + | ===== Other versioning schemes |
- | * Another common system is **{major}.{minor}.{maintenance}**. | + | * Some projects use date-based versioning. |
- | * {maintenance} is essentially MS's {revision}. | + | * ''2015.06.23'' |
- | * The character | + | * '' |
- | * e.g.: '' | + | * Whatever you do, be consistent and meaningful. |
- | * The last alpha should become the first beta. | + | |
- | * The last beta should become the first release candidate. | + | |
- | * The last release candidate should become the first full release. | + | |
- | ===== Version numbering | + | ===== Getting started with git ===== |
- | * Some projects use date-based versioning, e.g.: '' | + | * See [[Git basics]]. |
- | * Whatever you do, be consistent and meaningful. | + | |
===== Endcruft ===== | ===== Endcruft ===== | ||
This content is Copyright © 2011-2016 Mithat Konar | This content is Copyright © 2011-2016 Mithat Konar |
version_control/introduction_to_version_control_systems.txt · Last modified: 2019/02/21 18:52 by mithat