Git 在工作中高频操作介绍

文摘   2024-07-09 18:25   广东  

关注+星号公众号,不容错过精彩

作者:HywelStar

Git 作为程序员的代码仓库工具,可以说每个程序员都需要去掌握它,查看本章节你将可以解决以下问题?

  • Git 是什么?

  • Git 在工作中常用的基本操作?

  • Git 提交代码后,如何修改已提交的commit msg?

  • 如何回退到某个版本或者分支?

  • 在git clone 项目时候,如何切换分支,如何克隆子仓库?

  • 在项目开发中,如何推送项目分支?

  • 如何规范写好git commit 内容?

  • 如何生成.pacth文件?

我是你们的老朋友,@hywelstar,别忘记点关注了《码思途远》!分享嵌入式的新鲜事,技术笔记相关。本文都已经经过笔者测试,采用仓库例子<关注公众号码思途远发送git, 查看本仓库地址>。

1. Git 基础介绍

Git是一个分布式版本控制系统,最初由Linus Torvalds为了管理Linux内核开发而设计和开发的。它允许多人协同工作,记录文件的历史变更,以及在多个开发者之间进行版本控制和协作。Git的设计目标包括速度快、数据完整性强、支持非线性开发(如分支和合并)等特性。

特点:分布式版本系统,快速,数据完整,开源等。

2. Git 场景操作

第一个问题解决科学网络问题【这里不解释过多】

# Git设置proxygit config --global http.proxy http://192.168.xx.xx:10809git config --global https.proxy https://192.168.xx.xx:10809

2.1 Git 克隆代码

克隆代码来说非常简单,但这里需要提的是,对于需要克隆某个版本代码方式:

git clone <repository-url>

在这里需要注意:

当遇到含有多个分支或者版本情况,一般都可以需要clone 指定版本,如果不知道将会克隆最新的主分支再切换:

git clone https://github.com/zalebool/git-frequent-commands.git

2.1.1 关于分支问题

方法一:先克隆,后checktout 版本分支

# 克隆最新,并切换分支git clone <repository-url>git checkout <branch-name>
# 举例子:git clone https://github.com/zalebool/git-frequent-commands.gitgit checkout feature/new-feature

方法二:克隆指定版本分支:

# 克隆指定分支git clone -b <branch-name> <repository-url>
# 举例子git clone -b feature/new-feature https://github.com/zalebool/git-frequent-commands.git

2.2.2 关于子模块克隆

# 方法一:一次性全部克隆git clone --recurse-submodules <repository-url>
# 举例子1git clone --recurse-submodules https://github.com/zalebool/git-frequent-commands.git# 举例子2git clone --recurse-submodules -b feature/new-feature https://github.com/zalebool/git-frequent-commands.git
#方法二:先克隆主要,再克隆子模块git clone <repository-url>git submodule update --init --recursive
# 举例子3git clone --recurse-submodules https://github.com/zalebool/git-frequent-commands.gitgit submodule update --init --recursive
#确定子模块是否初始化:git submodule

例子:最后一步把子模块也克隆出来

2.2 Git 第一个Commit

项目开始,第一个推送的Commit 写什么?根据Github来说默认是:

Initial commit

2.3 Git 分支操作

分支是一个比较重要的概念和工具,为什么会有分支存在:

一个团队对于很多并行的工作要进行,为了不要批次干扰而使用了分支。

一方面是为了不影响主线开发,而产生了分支进行开发工作,都是一个独立的副本。

分支的出现可以专注于某些特定的功能,让代码不冲突,避免混合。

分支具体操作:

# 查看本地分支git branch
# 查看远程分支git branch -r
# 查看本地和远程分支git branch -a
# 创建分支git branch <branch-name>
# 切换分支git checkout <branch-name>
# 合并分支# 先切主分支git switch maingit merge <branch-to-merge>
# 删除分支git branch -d <branch-name>
# 推送分支到远程仓库git push origin <branch-name>

推送例子:创建新分支,并推送到远程分支上。

查看远端情况:

关于分支的问题,其实大家最最关心的是关于分支的合并出现的冲突,因为由于代码差异,到底以哪个为准,后续将专门出一章节进行讲解相关,途中涉及一些工具使用。

2.4 Git 打tag

关于tag 一般使用在到达某个节点,需要指定一个版本,这种使用率比较高。

# 查看标签git tag
# 查看标签信息 <有的可能没有,这里建议打标签时候附注标签 >git show <tagname>
# 打标签, 并注释git tag -a <tagname> -m "Tag message"
# 推送git push origin --tags

2.5 Git 提交代码

查询状态--> 添加暂存区--> 确定修改--> 提交本地添加commit --> 推送远程仓库

# 1.查询状态git status
# 2.添加暂存区git add <file1> <file2> ... # 添加指定文件git add . # 添加所有修改的文件
# 3.确定修改git status
# 4.提交本地添加commitgit commit -m "Your commit message"
# 5.推送远程仓库git push origin <branch>

例子:将文件推送远程仓库。

2.6 Git 查询相关操作

# 查询当前状态,比如修改了什么,添加了什么git status
# 比较指定文件的差异,可以是文件夹git diff
# 查看远程仓库信息git remote -v
# 撤销工作目录中文件的修改:git checkout -- <file>
# 撤销暂存区的文件:git reset HEAD <file>
# 恢复之前提交的版本:git revert <commit>
# 查看taggit tag

3. Git 其他常用操作

3.1 Git 修改某一个commit

在本地使用过程中,发现一个commit写错了或者写的不好,需要仅仅修改下commit

# 1. 查找所需要修改的commitgit rebase -i <commit_hash>^
# 2. 修改,commit 前部分修改为edit
# 3. 修改你要改成 commitgit commit --amend
# 4. rebasegit rebase --continue
# 5. 推送远程仓库<可能强制推送>git push --force

目标修改这句commit

实操步骤

结果:

3.2  Git 补丁path使用

为什么有path 出现,有可能是一些比较简单的改变,临时改变,其实就是不想改动仓库,很有可能在开发过程中仅仅用一下。
# 生成一次最近 commit 的补丁,保存到mypatch.patch 文件git diff HEAD^ > mypatch.patch
# 应用补丁文件git apply mypatch.patch
# 指定某个提交的diffgit diff <commit1> <commit2> -- <filename>

3.3 查看某个版本的某个文件

# 查看某个版本的文件git show <commit>:<file-path>
# 比如:git show 38a693a460d:README.md
# 还可以恢复某个版本的文件git checkout <commit> -- <file-path>

3.4 撤销暂存区状态

在执行了git add .,但是又要撤销这次的放入暂存区。

# 撤销所有文件的暂存区状态git reset HEAD .
# 撤销部分文件git reset HEAD <file1> <file2> <file3> <...>

4.  Git Commit 规范

关于commit都是根据修改提交内容而写,对于这个部分防止部分人各种乱造,commit不堪入目。

想起:“我讨厌写注释,我更讨厌看别人代码没注释”,和这个有相似之处。

这里简单提下规范,按照格式写基本都是OK了。

Commit message 三个部分:header,body 和 footer。

<type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>

Header【必写】

类型标签(Type Tag):指示提交的类型,

  • feat(新功能)
  • fix(修复 bug)、
  • docs(文档变更)、
  • style(代码样式调整)、
  • refactor(代码重构)、
  • test(新增测试)、
  • chore(构建过程或工具变动)
  • revert(撤销)等。

简短描述(Short Description):简洁明了地概括了本次提交的目的。长度通常不超过 50 个字符,以便在各种 Git 工具中清晰显示。

feat: Add authentication module

Body 【可选】:提供修改的详细内容

Footer【可选】:可选的,通常包含与提交相关的元数据

5. emoji表情有趣的提交

原本这章节没有,但是发现还挺有趣,:art:在写一个:

先看下效果:

对于emoji提交有专门的工具进行提交,这里以最普通方式展现:

# 举例子git commit -m ":white_check_mark: Add git-emoji.md document for emoji"

6. 总结

看到这里,在工作中遇到的git 相关问题基本都能够得到解决,文章开头提到的一些疑问都在本章节能够找到答案,也希望本章节对你有所帮助,对知识有一个理解或者巩固。具体的更详细帮助文件可以查看介绍:
<后台发送git, 查看本仓库地址已经相关md文档>


码思途远
一位码农的日常分享,专注嵌入式领域相关知识。
 最新文章