dido:99_annexes:annex-b-terms-and-definitions:g:git

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

dido:99_annexes:annex-b-terms-and-definitions:g:git [2026/07/30 13:46] – created nick_didodido:99_annexes:annex-b-terms-and-definitions:g:git [2026/07/30 13:50] (current) – nick_dido
Line 5: Line 5:
 ===== Discussion ===== ===== Discussion =====
  
-Git is a distributed version control system used to record, organize, compare, and exchange changes to files and directories maintained in a repository.+Git is a distributed [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control_system|Version Control System]] used to record, organize, compare, and exchange changes to files and directories maintained in a repository.
  
-A Git repository contains the recorded history and associated metadata for a managed body of content. A complete clone normally includes the repository history rather than only the most recent version. This distributed model allows participants to perform many repository operations locally and exchange changes with other repositories. :contentReference[oaicite:1]{index=1}+A Git repository contains identifiable revisions of managed [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] and preserves relationships among those revisions.
  
 Git represents recorded repository states as commits. Git workflows commonly use: Git represents recorded repository states as commits. Git workflows commonly use:
Line 25: Line 25:
   * Cloning   * Cloning
  
-Git records content snapshots and the relationships among commits. This history enables users and automated processes to identify changes, compare repository states, trace the ancestry of a change, and reproduce an identified repository state. :contentReference[oaicite:2]{index=2}+Git records repository states and the relationships among commits. This history enables users and automated processes to: 
 + 
 +  * Identify changes 
 +  * Compare repository states 
 +  * Trace the ancestry of a change 
 +  * Retrieve an identified repository state 
 +  * Restore or reuse an identified repository state 
 +  * Reproduce managed content associated with an identified commit
  
 Within Crucible documentation, Git provides repository and change-history capabilities used by: Within Crucible documentation, Git provides repository and change-history capabilities used by:
Line 42: Line 49:
 ===== Definition ===== ===== Definition =====
  
-//distributed version control system that records repository states and the relationships among changes to managed content//+//distributed [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control_system|Version Control System]] that records identifiable repository states and preserves the relationships among those states//
  
 ===== Source ===== ===== Source =====
  
-Adapted from the Git Project documentation:+Adapted from:
  
-  * //Git// +  * Git Project documentation 
-  * //git Documentation// +  * [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control_system|Version Control System]]
-  * //Pro Git: About Version Control// +
-  * //Pro Git: What Is Git?//+
  
 ===== Note ===== ===== Note =====
  
 The name **Git** is not an acronym and should not be written as **GIT**. The name **Git** is not an acronym and should not be written as **GIT**.
 +
 +Git is a type of [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control_system|Version Control System]].
  
 Git is distinct from repository-hosting services such as GitHub, GitLab, and Bitbucket. Those services can host and manage Git repositories, but they are not Git itself. Git is distinct from repository-hosting services such as GitHub, GitLab, and Bitbucket. Those services can host and manage Git repositories, but they are not Git itself.
Line 61: Line 68:
 Git does not require a single permanent central repository. A project can designate one repository as an authoritative or shared repository through policy and workflow conventions. Git does not require a single permanent central repository. A project can designate one repository as an authoritative or shared repository through policy and workflow conventions.
  
-A Git-based workflow uses Git repository states and operations to coordinate change. The existence of a Git repository alone does not define the workflow, approval rules, branch strategy, automation, or deployment behavior.+A Git-based workflow uses Git repository states and operations to coordinate change. The existence of a Git repository alone does not define: 
 + 
 +  * The workflow 
 +  * Approval rules 
 +  * Branch strategy 
 +  * Merge strategy 
 +  * Automation 
 +  * Build behavior 
 +  * Deployment behavior
  
 ===== Example ===== ===== Example =====
  
-A contributor commits a Declarative Configuration change to a Git branch. A review process approves and merges the change into the designated branch. A CI/CD Pipeline identifies the resulting commit and initiates automated build, validation, and deployment operations associated with that repository state.+A contributor commits a [[dido:99_annexes:annex-b-terms-and-definitions:d:declarative_configuration|Declarative Configuration]] change to a Git branch. A review process approves and merges the change into a designated branch. A [[dido:99_annexes:annex-b-terms-and-definitions:c:ci_cd_pipeline|CI/CD Pipeline]] identifies the resulting commit and initiates automated build, validation, and deployment operations associated with that repository state.
  
 ---- ----
  • dido/99_annexes/annex-b-terms-and-definitions/g/git.1785444365.txt.gz
  • Last modified: 2026/07/30 13:46
  • by nick_dido