Introduction to git command

git 是一个较为流行的软件版本控制系统。如果你访问过 github↗ 你一定会发现某一个开源软件的历史 release 版本，或者 commit records。

它由 Linus Torvalds 于 2005 年创建，此后一直由 Junio Hamano 维护。

它用于：

跟踪代码更改
跟踪更改者
编码协作

How to configure git

因为 git 最主要的就是责任到位。换句话就是要知道是谁、什么时候、更改了什么。因此拿到 git 之后首先就要配置自己的名字和联系方式。

git config --global user.name "<your github name>"
git config --global user.email "<your email which can contact you by this way>"

当然，这样还不够。如果你开发过、参与过一些工具库开发。你会发现 github 并不是只支持公有存储库(public repository)，还支持私有存储库(private repository)。

此外，如果你仔细观察过 github。你会发现 git clone 不只有 https，还有 ssh 协议。一般情况下，我们其实更愿意使用 ssh protocol 去拉去私有库。因此我们简单提及一下如何为 git 配置 ssh。

对于这个问题，我们第一步要做的就是生成 ssh key。我们可以利用 ssh-keygen(ssh key generator) 指令生成。

ssh-keygen -t ed25519 -C "personal@example.com"

有的时候，我们可能会有一些工作账号(公司下发)。这个适合需要和个人账号区分，你可以使用如下指令来区别:

ssh-keygen -t ed25519 -C "work@example.com" -f ~/.ssh/id_ed25519_work

然后我们需要配置一个 ssh 协议的 configuration(~/.ssh/config)。

Host github.com-personal
    HostName ssh.github.com
    User git
    port 443
    IdentityFile /path/to/your/sshkey
    IdentitiesOnly yes # 强制只使用指定的密钥

还记得，我们之前执行的 ssh-keygen 指令嘛。实际上这个指令不知会生成私钥，这里我们简称这个密钥文件为 sshkey，其实它还会生成一个公钥文件 sshkey.pub。现在你需要做的就是将 sshkey.pub 的内容传递给 github 网页。在网页添加 sshkey.pub 很简单。你只需要点击 setting -> SSH and GPG keys -> New SSH key 即可。

当然你可以利用如下指令获取得到 sshkey.pub 的内容:

configure sshkey in github

cat /path/to/your/sshkey.pub

现在怎么就万事具备只欠东风。我们可以利用如下指令测试能否连接到 github :

如下指令中的 ssh-add 是每启动一起 shell 都要执行的。如果你不想手动输入，你可以在 .bashrc 或者 .zshrc 等 shell 配置文件中加入即可

ssh-add /path/to/your/sshkey
ssh -T git@github.com-personal

1.github.com-personal 是由 ~/.ssh/config 决定的。不要盲目复制粘贴。
2.如果你在执行 ssh-add 时报错，请先确定 sshkey 文件的权限是否是 0644。
其次如果该文件所属者是 root，或者文件权限没问题，请执行 eval $(ssh-agent -s).

What are the usage methods and scenarios of git

Submit the code to the remote repository

在 git 中三级存储结构，本地 -> 本地存储库 -> 远程存储库(github)。我们直接修改的是本地。那么我们该如何推送远程代码呢?

下述代码仅供示意，我们后续会说明下述提交代码存在的风险与问题。

git pull origin main  # 确保和远程一致
git add .
git commit -m "description about this commit"
git push origin main

但如果你是第一次提交你需要做多一点事情。

初始化 git 仓库

git init
git add .
git commit -m "Initial commit"

配置用户信息

git config --global user.name "<your github name>"
git config --global user.email "<your email which can contact you by this way>"

创建 .gitignore 文件在首次提交前，务必添加 .gitignore 来忽略不必要的文件（如 node_modules, pycache, .env 等）。

你可以使用 gitignore.io 快速生成模板。

添加 README.md 和 LICENSE 首次提交应包含基本文档：

README.md：介绍项目用途、安装步骤等。
LICENSE：说明开源协议（如 MIT、Apache）。

第一次推送需要关联远程仓库如果是第一次推送到远程仓库（GitHub）：

git remote add origin https://github.com/yourname/yourrepo.git
git remote -v
git branch -M main
git push -u origin main

How to submit more elegantly

事实上，此前提供的提交代码是不负责任的。因为他直接向主分支提交代码，这对团队协作极其不利。

一般我们会根据自身的在做的事情来创建开发分支、修复分支、实验性分支等:

创建一个长期支持的功能开发分支

git checkout -b feature/your-feature-name

创建一个修复分支

git checkout -b fix/your-fix-bug

创建一个实验性分支

git checkout -b experimental/your-experimental-function

同样第一次提交分支，也需要 git pull -u origin 去(自动创建远程分支并)关联一下远程分支。

当然我们在开发的过程中，主分支 main 一定也是动态变化的！因此有的时候，我们希望在合并我们的特性分支之前，先把这些更新纳入我们的工作成果中，以便于确保你的变更基于最新的代码基础。

git checkout featur
git rebase main

对于每个冲突文件，编辑以解决冲突，然后执行如下代码：

git add <file>
git rebase --continue

如果你是第一次变基:

git push --force-with-lease

通过正确地运用变基，我们可以有效地管理我们的 Git 项目，使其历史更易于理解和维护。不过需要注意的是，变基会改写提交历史，因此不应该对已经共享给其他人的提交进行变基。在团队合作中，务必谨慎使用变基，尤其是在多人协作的分支上。

Other case

有的时候，我们会先更改，后执行拉去分支最新状态。或者说，我们的开发进度会和远程更新进度不匹配。我们始终不能保证自己的更动一直基于最新的远程分支状态。而此时，我们因为一些原因不能执行rebase。此时我们需要 git stash 来暂存，然后在获取最新远程分支代码后，使用 git stash pop 或者 git stash apply恢复你的更改情况，以避免前功尽弃。当然你有 100% 的信心提交，你可以使用 git add 和 git commit 指令将你的更动更新到本地存储库。