运维个人技术栈
Blog Categories Tags About
运维个人技术栈

git教程

kentxxq  收录于  类别 Blog
     约 1217 字  预计阅读 3 分钟 

这里用来记录一些我可能用到的 git 命令. 每次去网上搜集都很麻烦, 还需要验证. 而这里的命令都经过了我的验证..

~/.ssh/config 文件可以处理多种问题。

  • 多个密钥，不同密钥服务于不同仓库/用户
  • github 的连接问题 ssh connect to host github.com port 22 connection timed out ，github官方也有对此说明

下面是一个示例

text

Host qs_codeup
HostName codeup.aliyun.com
IdentityFile ~/.ssh/2_rsa
PreferredAuthentications publickey
User kentxxq

Host github.com
HostName ssh.github.com
Port 443
IdentityFile ~/.ssh/id_rsa
PreferredAuthentications publickey
User kentxxq
  • 两个配置文件，对应你的 2 个账号
  • Port 参数可以让你从默认的 22 端口，改成连接 443 端口
  • 使用了不同的密钥
  • feat: 新功能 (feature)
  • update: 在 feat 内的修改
  • fix: 修补 bug
  • docs: 文档 (documentation)
  • style: 格式（不影响代码运行的变动)
  • refactor: 重构 (即不是新增功能，也不是修改 bug 的代码变动)
  • perf: 性能优化 (performance)
  • test: 增加测试
  • thore: 构建过程或辅助工具的变动

shell

# clone 特定tag或release
git clone -b v111 xxx.git
# 深度为1的clone
git clone --depth 1 xxx.git

# 代理克隆
git clone https://ghproxy.com/https://github.com/kentxxq/hugo.git
# 私有仓库配合token使用.
git clone https://user:your_token@ghproxy.com/https://ghproxy.com/https://github.com/kentxxq/hugo.git

# 克隆大文件失败
git config --global core.compression 0
git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M

shell

git clone git@codeup.aliyun.com:oiasjdoajsdo/仓库名.git --config core.sshCommand="ssh -i ~/.ssh/你的私有key"

shell

# 添加remote
git remote add gitea https://ken.kentxxq.com/admin1/learn-actions.git
# 修改origin地址
git remote set-url origin https://github.com/kentxxq/hugo.git
# 删除
git remote remove origin2

# 验证效果
git remote -v

shell

# 所有
git push

git tag 1.0.0
# 指定tag
git push origin <tag_name>

# 所有tag,不推荐
git push --tags

shell

# 新分支
git checkout --orphan  new_branch
# 添加到暂存区
git add -A
# 提交
git commit -am "init"
# 删除原有的main
git branch -D main
# 重命名分支
git branch -m main
# 强制推送
git push -f origin main

常见模式

  • github-flow：一个主分支。hotfix 和 feature 合并过来就 ok。主分支发布。问题是我合并特性到了 master，发布到开发环境测试。这时候生产有 bug，我要修复。我不能简单从 master 拉出分支来修复。
  • git-flow：dev 和 master 是主分支。存在一个分支发布多个环境的情况，或者说需要通过 tag 方式来发布。而我通常用不同分支发布到不同环境。因此不用这种。

我使用的，其实是在 github-flow 上加了环境分支：

  • dev 是主分支
  • 4 个环境的长期分支，每个环境对应流水线发布。dev=>test=>pre=>prod
  • feature：不一定立即合并，因为不一定上线。上线完成以后再删除。只会合并到 dev
  • 小步快跑，避免代码在某环境节点停留时间长的情况。中间存在功能删减的情况，也要遵循从 dev 开始的流程。
  • hotfix 可以从 prod 拉取。然后快速修复回到 prod。然后合并到 dev 后删除。

另外一种方式:

  • 在特性分支上开发新功能，同步机器之间的代码
  • 合并到 main 自动触发流水线，验证测试环境
  • 手动 tag，发版线上

github 工作流使用

更新于 2024-11-03
 Git, Blog
 | 主页