关于 Git

关于版本控制和 Git

版本控制系统（VCS）会在人员和团队共同协作项目时，追踪更改历史。当开发者对项目进行更改时，任何早期的项目版本都可以随时恢复。

开发者可以查看项目历史，以了解

哪些更改已被做出？
谁做了这些更改？
更改是什么时候进行的？
为什么需要更改？

VCS 为每位贡献者提供统一且一致的项目视图，展现已经在进行的工作。通过透明的更改历史、作者以及这些更改对项目开发的贡献，团队成员在独立工作时也能保持一致。

在分布式版本控制系统（DVCS）中，每个开发者都有项目及其历史的完整副本。不同于曾经流行的集中式版本控制系统，DVCS 不需要始终连接到中心仓库。Git 是最流行的分布式版本控制系统。Git 常被用于开源和商业软件开发，对个人、团队和企业都有显著优势。

Git 让开发者可以在同一地点查看他们的所有更改、决策和项目进展的完整时间线。从他们访问项目历史的那一刻起，开发者就拥有了理解项目并开始贡献所需的全部上下文。
开发者遍布各个时区。使用像 Git 这样的 DVCS，协作可以随时进行，同时保持源代码的完整性。通过分支，开发者可以安全地对生产代码提出更改。
使用 Git 的企业可以打破团队之间的沟通壁垒，使他们专注于做好自己的工作。此外，Git 还可以让企业内部的专家在大型项目上协同合作。

仓库（也称为 Git 项目）包含与项目相关的所有文件和文件夹，以及每个文件的修订历史。文件历史以称为提交（commit）的时间快照形式出现。提交可以组织成多个称为分支（branch）的开发线。由于 Git 是 DVCS，仓库是自包含的单元，任何拥有仓库副本的人都可以访问整个代码库及其历史。通过命令行或其他易用界面，Git 仓库还支持：与历史交互、克隆仓库、创建分支、提交、更改合并、比较不同版本的代码等。

通过 GitHub 等平台，Git 还能提供更多项目透明度和协作的机会。公共仓库帮助团队共同构建尽可能最佳的最终产品。

GitHub 的工作原理

GitHub 托管 Git 仓库，并为开发者提供通过命令行功能、议题（线程讨论）、拉取请求、代码审查，或使用 GitHub Marketplace 中的免费和付费应用来交付更好代码的工具。借助 GitHub flow 等协作层、拥有一亿开发者的社区以及数百个集成生态系统，GitHub 正在改变软件的构建方式。

GitHub 将协作直接嵌入到开发流程中。工作被组织在仓库里，开发者可以在其中概述需求或方向并设定团队成员的期望。然后，使用 GitHub flow，开发者只需创建一个分支来进行更新，将更改提交保存，打开拉取请求以提出和讨论更改，并在所有人达成一致后合并拉取请求。更多信息，请参阅 GitHub flow。

关于 GitHub 的方案和费用，请参阅 GitHub 定价。有关 GitHub Enterprise 与其他选项的比较信息，请参阅 GitHub 与其他 DevOps 解决方案的比较。

GitHub 与命令行

基本 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 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

首先，需要在 GitHub 上创建一个新仓库。更多信息，请参阅 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 上的已有分支做贡献

此示例假设你已经在机器上有一个名为 repo 的项目，并且自上次在本地进行更改以来，已有新分支被推送到 GitHub。

# 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 上协作的主要方式有两种

共享仓库
Fork 与 Pull

在共享仓库模式下，个人和团队被明确指定为具有读取、写入或管理员权限的贡献者。这种简单的权限结构，加上受保护分支等功能，使得团队在采用 GitHub 时能够快速推进。

对于开源项目，或任何人都可以贡献的项目，管理单个权限可能会很困难，但 Fork 与 Pull 模型允许任何能够查看项目的人进行贡献。Fork 是在开发者个人账户下的项目副本。每个开发者对自己的 Fork 拥有完整控制权，可自由实现修复或新功能。Fork 中完成的工作要么保持独立，要么通过拉取请求（Pull Request）返回原项目。在那里，维护者可以在合并之前审查建议的更改。更多信息，请参阅向项目贡献。

本文内容