关于版本控制和 Git
版本控制系统(VCS)跟踪人员和团队在项目上进行协作时的更改历史记录。 当开发人员对项目进行更改时,可以随时恢复项目的任何早期版本。
开发人员可以查看项目历史记录以找出:
- 进行了哪些更改?
- 谁进行了更改?
- 何时进行了更改?
- 为什么需要更改?
VCS 为每个贡献者提供统一且一致的项目视图,显示已经在进行中的工作。 查看透明的更改历史记录、谁进行了更改,以及它们如何为项目开发做出贡献,可帮助团队成员在独立工作时保持一致。
在分布式版本控制系统中,每个开发人员都有项目和项目历史记录的完整副本。 与曾经流行的集中式版本控制系统不同,DVCS 不需要与中央存储库的持续连接。 Git 是最流行的分布式版本控制系统。 Git 通常用于开源和商业软件开发,对个人、团队和企业都有明显的好处。
-
Git 允许开发人员在一个地方查看任何项目的更改、决策和进度的整个时间线。 从他们访问项目历史记录的那一刻起,开发人员就拥有了理解它并开始参与所需的所有上下文。
-
开发人员在每个时区工作。 使用像 Git 这样的 DVCS,协作可以随时随地进行,同时保持源代码的完整性。 使用分支,开发人员可以安全地提出对生产代码的更改建议。
-
使用 Git 的企业可以打破团队之间的沟通障碍,让他们专注于做好最好的工作。 此外,Git 还可以让整个企业的专家协调一致,在重大项目上进行协作。
关于仓库
存储库或 Git 项目包含与项目关联的文件和文件夹的整个集合,以及每个文件的修订历史记录。 文件历史记录在时间上显示为快照,称为提交。 提交可以组织成多个开发行,称为分支。 由于 Git 是 DVCS,因此存储库是独立的单元,任何拥有存储库副本的人都可以访问整个代码库及其历史记录。 使用命令行或其他易用性接口,Git 存储库还允许:与历史记录交互、克隆存储库、创建分支、提交、合并、比较不同版本的代码更改等。
通过像 GitHub Enterprise Server 这样的平台,Git 也为项目的透明度和协作提供了更多的机会。 公共存储库可帮助团队协同工作,以构建最佳的最终产品。
GitHub Enterprise Server 的工作原理
GitHub Enterprise Server 托管 Git 存储库,并为开发人员提供工具,通过命令行功能、议题(线程讨论)、拉取请求、代码审查或使用 GitHub Marketplace 中的一组免费和可购应用程序来交付更好的代码。 通过 GitHub Enterprise Server 流程等协作层、拥有 1 亿开发人员的社区以及具有数百个集成的生态系统,GitHub Enterprise Server 改变了软件的构建方式。
GitHub Enterprise Server 将协作直接构建到开发过程中。 工作组织到存储库中,开发人员可以在其中概述要求或方向,并为团队成员设定期望。 然后,使用 GitHub Enterprise Server 流程,开发人员只需创建一个分支来处理更新,提交更改以保存它们,打开拉取请求以建议和讨论更改,并在每个人都在同一页面上时合并拉取请求。 有关详细信息,请参阅“GitHub 流”。
有关 GitHub 计划和成本,请参阅 GitHub Pricing。 有关 GitHub Enterprise 与其他选项的比较信息,请参阅比较 GitHub 与其他 DevOps 解决方案。
GitHub Enterprise Server 和命令行
基本 Git 命令
为使用 Git,开发人员使用特定命令来复制、创建、更改和合并代码。 这些命令可以直接从命令行执行,也可以使用 GitHub Desktop等应用程序执行。 以下是使用 Git 的一些常用命令:
-
git init
初始化一个全新的 Git 存储库并开始跟踪现有目录。 它在现有目录中添加一个隐藏的子文件夹,该子文件夹包含版本控制所需的内部数据结构。 -
git clone
创建远程已存在的项目的本地副本。 克隆包括项目的所有文件、历史记录和分支。 -
git add
暂存更改。 Git 跟踪对开发人员代码库的更改,但有必要暂存更改并拍摄更改的快照,以将其包含在项目的历史记录中。 此命令执行暂存,即该两步过程的第一部分。 暂存的任何更改都将成为下一个快照的一部分,并成为项目历史记录的一部分。 通过单独暂存和提交,开发人员可以完全控制其项目的历史记录,而无需更改其编码和工作方式。 -
git commit
将快照保存到项目历史记录中并完成更改跟踪过程。 简言之,提交就像拍照一样。 任何使用git add
暂存的内容都将成为使用git commit
的快照的一部分。 -
git status
将更改的状态显示为未跟踪、已修改或已暂存。 -
git branch
显示正在本地处理的分支。 -
git merge
将开发线合并在一起。 此命令通常用于合并在两个不同分支上所做的更改。 例如,当开发人员想要将功能分支中的更改合并到主分支以进行部署时,他们会合并。 -
git pull
使用远程对应项的更新来更新本地开发线。 如果队友已向远程上的分支进行了提交,并且他们希望将这些更改反映到其本地环境中,则开发人员将使用此命令。 -
git push
使用本地对分支所做的任何提交来更新远程存储库。
有关详细信息,请参阅 Git 命令的完整参考指南。
示例:参与现有存储库
# download a repository on GitHub Enterprise Server to our machine
# Replace `owner/repo` with the owner and name of the repository to clone
git clone https://github.com/owner/repo.git
# change into the `repo` directory
cd repo
# create a new branch to store any new changes
git branch my-branch
# switch to that branch (line of development)
git checkout my-branch
# make changes, for example, edit `file1.md` and `file2.md` using the text editor
# stage the changed files
git add file1.md file2.md
# take a snapshot of the staging area (anything that's been added)
git commit -m "my snapshot"
# push changes to github
git push --set-upstream origin my-branch
示例:启动新存储库并将其发布到 GitHub Enterprise Server
首先,您需要在 GitHub Enterprise Server 上创建一个新存储库。 有关详细信息,请参阅“Hello World”。 不要使用 README、.gitignore 或 License 文件初始化存储库。 这个空存储库将等待您的代码。
# create a new directory, and initialize it with git-specific functions
git init my-repo
# change into the `my-repo` directory
cd my-repo
# create the first file in the project
touch README.md
# git isn't aware of the file, stage it
git add README.md
# take a snapshot of the staging area
git commit -m "add README to initial commit"
# provide the path for the repository you created on github
git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git
# push changes to github
git push --set-upstream origin main
示例:为 GitHub Enterprise Server 的现有分支做出贡献
此示例假定计算机上已有一个名为 repo
的项目,并且自上次在本地进行更改以来,已将新分支推送到 GitHub Enterprise Server。
# change into the `repo` directory
cd repo
# update all remote tracking branches, and the currently checked out branch
git pull
# change into the existing branch called `feature-a`
git checkout feature-a
# make changes, for example, edit `file1.md` using the text editor
# stage the changed file
git add file1.md
# take a snapshot of the staging area
git commit -m "edit file1"
# push changes to github
git push
协作开发模型
人们在 GitHub Enterprise Server 上有两种主要协作方式:
- 共享存储库
- 复刻和拉取
使用共享存储库,个人和团队被显式指定为具有读取、写入或管理员访问权限的参与者。 这种简单的权限结构与受保护的分支等功能相结合,可帮助团队在采用 GitHub Enterprise Server 时快速取得进展。
对于开源项目,或者对于任何人都可以参与的项目,管理个人权限可能具有挑战性,但复刻和拉取模型允许任何可以查看项目的人做出贡献。 复刻是开发人员个人帐户下项目的副本。 每个开发人员都可以完全控制他们的分支,并可以自由地实现修复或新功能。 在复刻中完成的工作要么保持独立,要么通过拉取请求返回到原始项目。 在那里,维护者可以在合并之前查看建议的更改。 有关详细信息,请参阅“参与项目”。