前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >玩不转的 GitHub (一)

玩不转的 GitHub (一)

作者头像
双鬼带单
发布于 2021-07-20 06:57:32
发布于 2021-07-20 06:57:32
49300
代码可运行
举报
文章被收录于专栏:CodingToDieCodingToDie
运行总次数:0
代码可运行

玩不转的 GitHub

写这篇并不是详细的去写一下关于版本控制和 Git 使用的详细教程,而是整理一下 Git 入门、GitHub 常规使用、Gitee 常规使用以及在工作中常见的一些操作。

现在网上关于 Git 和 GitHub 的资源很多,高质量的也很多,比如

  • https://www.imooc.com/learn/1278 【慕课网视频 2 小时】
  • https://git-scm.com/book/zh/v2 【官网文档 中文版】
  • https://gitee.com/help/categories/43 【码云文档 中文版】
  • https://www.liaoxuefeng.com/wiki/896043488029600 【廖雪峰文档 中文版】

如果再从头开始写相关的文档,不过是狗尾续貂或者搬运加工罢了,那这里只介绍一下 Git的一些基本功能以及工作中遇到的问题,不在详细赘述。

正文开始:

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的分布式版本控制系统

自诞生于 2005 年以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。它的速度飞快,极其适合管理大项目,它还有着令人难以置信的非线性分支管理系统,可以应付各种复杂的项目开发需求。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。对于大部分公司 Git 已经变成了代码管理的首选方案,所以学习 Git 是很重要的。

如果你对 Git 一无所知,建议先通过上面的四种方式的任意一种来学习如何使用 Git 进行文件的管理。

一、安装和配置

Git 的安装相当简单,直接在 https://git-scm.com/downloads 下载安装即可,具体的安装过程中,可以观看具体的教程。

配置

Git 的配置分为系统配置、全局配置、当前仓库配置以及 worktree 配置,其中直接使用 git config 会将设置保存在当前仓库的 .git/config 文件中,只对当前仓库有效,使用 git config --global 进行配置则对当前用户下的所有仓库有效,使用 git config --system 则对当前系统下的所有用户有效。其中个人开发中,常用的为 git configgit config --global

用户信息配置

第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要,每次 Git 提交时都会引用这两条信息,说明是谁提交了更新,所以会随更新内容一起被永久纳入历史记录(后期即使再修改,也不能改变原来的记录):

比如要设置一个全局有效的配置:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config --global user.name "zhangyunan"
$ git config --global user.email "zyndev@gmail.com"

如果你想不同的仓库采用不同的用户信息,可以分别在不同的仓库下面进行不同的配置,比如在 A 公司你可能使用 zhangyunan@a.com 则可以在对应的 A 公司的仓库下设置用户名

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config user.name "zhangyunan"
$ git config user.email "zhangyunan@a.com"

在别的仓库上就可以再设置其他的用户信息

如果用了 --global 选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的仓库都会默认使用这里配置的用户信息。如果要在某个特定的仓库中使用其他名字或者邮箱,只要去掉 --global 选项重新配置即可,新的设定保存在当前仓库的 .git/config 文件里。在 Windows 上是隐藏文件夹,可以通过展示隐藏文件来查看;在 Linux/Mac 上可以使用 ls -a 查看。

总结

  • git config --system:操作 /etc/gitconfig 文件,全局的,对所有用户都生效
  • git config --global:操作 用户目录/.gitconfig 文件,仅仅对自己生效
  • git config:操作仓库 .git/config 文件,只对当前仓库有效
  • 通过上面的示例也可以推测出 git 配置的优先级为 local > global > system

查看配置

要查看已有的配置信息,可以使用 git config --list 命令:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config --list
user.email=zyndev@gmail.com
user.name=zhangyunan
core.autocrlf=input
core.excludesfile=/Users/zhangyunan/.gitignore_global
core.quotepath=false
core.ignorecase=false

也可以使用 git config --global --list 来查看一些全局的配置,如果想单独查看指定的配置可以使用 git config 配置名称

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config user.name
zhangyunan

更多示例

  • git config --system --list 系统级别
  • git config --global --list 用户级别
  • git config --list 当前仓库级别

一些常见配置项说明

配置名称

值示例

配置说明

user.name

个人姓名,如 zhangyunan

代码提交时用来展示谁提交的

user.email

个人邮箱或者公司邮箱,如 zyndev@gmail.com

代码提交时用来展示谁提交的

core.quotepath

false

是否转移路径,如果开启,会碰到有一些中文文件名或者路径被转义成\xx\xx\xx

core.ignorecase

false

是否对文件名大小写敏感,建议 false,因为在开发中出现修改文件名大小写的情况还是很常见的,如果为 true 则不跟踪文件名大小写改动。

pull.rebase

false

在使用 pull 时,是使用 rebase 进行合并还是使用 merge 进行合并,建议 false,不要在默认情况下破坏提交记录,除非你知道在干什么。关于 merge 和 rebase 的区别,在后面的时候会讲一下

init.defaultbranch

master

仓库创建时,默认的分支名称,默认是 master, 也可以改成其他名称

commit.template

文件路径

提交代码时提供一个message 的模板信息,默认是一个空文件

core.excludesfile

文件路径(默认是在用户目录下)

git 的全局的忽略文件配置,对所有的仓库有效

配置还有一些,具体的可以看 官网

一些建议配置

git 修改文件夹/文件名大小写
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config --global core.ignorecase false

给配置默认是 true,也就是 Git 会忽略掉关于文件夹和文件名的大小写修改,比如我们将文件夹从 ABC 改为 abc 时,Git 不会认为发生了变化了,这在日常的开发中还是有问题,比如你把一些大小写字母拼错了,导致不符合某些命名规范,这时你想改正过来,发现 Git 并没有跟踪这个变化,你是不是很崩溃,这里建议提前进行设置

pull 代码使用 merge

最新的 Git 中增加 pull.rebase 配置,让你来决定默认 pull 时是使用 rebase 还是 merge,当你不进行手动设置的时候会使用 merge 进行合并,但是会每次都提示进行配置,这里建议你设置成 false

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
git config --global pull.rebase false

清除指定的配置

对于不想进行配置或者需要清除的配置的可以使用 unset 命令

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git config --unset --local user.name 
$ git config --unset --global user.name 
$ git config --unset --system user.name

这样就可以清除对应级别的配置项

别名的配置

有个=一些 git 命令很长,可以通过起别名来缩短命令。 例如:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
给 commit 起个别名为 ci 则使用 git ci 等同于 git commit
git config --global alias.ci commit
给 status 起个别名为 ci 则使用 git st 等同于 git status
git config --global alias.st status
给 branch 起个别名为 ci 则使用 git br 等同于 git branch
git config --global alias.br branch

这种方式对于组合长命令来说很有帮助,例如:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
git config --global alias.graph "log --online --graph"

命令如果出现空格需要用引号引起来

查看帮助

若你使用 Git 时需要获取帮助,有三种方法可以找到 Git 命令的使用手册:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git help <verb>
$ git <verb> --help
$ man git-<verb>

例如,要想获得 config 命令的手册,执行

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git help config

常见问题

为了演示方便,这里新建了一个名为 git-demo 的仓库,对应的 github 为 https://github.com/useless-project/git-demo

使用 git commit --amend 来修改最后一次提交

情景:最近产品又改需求了,这已经是今天的第 3 次了,小明在已经千疮百孔的代码上又加上一个大坑,终于完成了这次的改动,心中怨气横生,顺手提交了代码并写到 "再 TMD 改,老子不干了"

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git commit -am "再 TMD 改,老子不干了"

此时使用 git log 可以看到

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git log --oneline
3130f04 (HEAD -> main)TMD 改,老子不干了
bbcc6ee (origin/main, origin/HEAD) Initial commit

吐槽归吐槽,生活还得继续呀!这时就需要修改掉提交信息,再重新提交一下 git commit --amend 的用途就来了

The git commit –amend command lets you modify your last commit. You can change your log message and the files that appear in the commit.

修改你最近一次提交可能是所有修改历史提交的操作中最常见的一个。对于你的最近一次提交,你往往想做两件事情:简单地修改提交信息, 或者通过添加、移除或修改文件来更改提交实际的内容。

如果,你只是想修改最近一次提交的提交信息,那么很简单:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git commit --amend

上面这条命令会将最后一次的提交信息载入到编辑器中供你修改。当保存并关闭编辑器后,编辑器会将更新后的提交信息写入新提交中,它会成为新的最后一次提交。

另一方面,如果你想要修改最后一次提交的实际内容,那么流程很相似:首先作出你想要补上的修改, 暂存它们,然后用 git commit --amend 以新的改进后的提交来 替换 掉旧有的最后一次提交,

我们使用 git commit -amend 来修改下最后一次提交

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git commit --amend -m  "这次的改动很符合实际应用情况,果然还是产品了解需求"

此时使用 git log 可以看到

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git log --oneline
4be98a7 (HEAD -> main) 这次的改动很符合实际应用情况,果然还是产品了解需求
bbcc6ee (origin/main, origin/HEAD) Initial commit

这一次你好像遭受到了社会的毒打

使用 git rebase -i 来修改多次提交历史

小明吐槽的太多了,导致只修改最后一次不管用了。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git log --oneline

75bcb30 (HEAD -> main)TMD 改,老子不干了 x4
2d6b84e 再 TMD 改,老子不干了 x3
e21c6f8 再 TMD 改,老子不干了 x2
875613d 再 TMD 改,老子不干了 x1
4be98a7 这次的改动很符合实际应用情况,果然还是产品了解需求
bbcc6ee (origin/main, origin/HEAD) Initial commit

为了修改在提交历史中较远的提交,必须使用更复杂的工具。Git 没有一个改变历史工具,但是可以使用变基工具来变基一系列提交,基于它们原来的 HEAD 而不是将其移动到另一个新的上面。通过交互式变基工具,可以在任何想要修改的提交后停止,然后修改信息、添加文件或做任何想做的事情。可以通过给 git rebase 增加 -i 选项来交互式地运行变基。必须指定想要重写多久远的历史,这可以通过告诉命令将要变基到的提交来做到。

例如,如果想要修改最近四次提交信息,或者那组提交中的任意一个提交信息, 将想要修改的最近一次提交的父提交作为参数传递给 git rebase -i 命令,即 HEAD~3^HEAD~4。记住 ~4 可能比较容易,因为你正尝试修改最后四次提交;但是注意实际上指定了以前的五次提交,即想要修改提交的父提交:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git rebase -i HEAD~4

再次记住这是一个变基命令——在 HEAD~4..HEAD 范围内的每一个修改了提交信息的提交及其 所有后裔 都会被重写。不要涉及任何已经推送到中央服务器的提交——这样做会产生一次变更的两个版本,因而使他人困惑。

运行这个命令会在文本编辑器上给你一个提交的列表,看起来像下面这样:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
pick 875613d 再 TMD 改,老子不干了 x1
pick e21c6f8 再 TMD 改,老子不干了 x2
pick 2d6b84e 再 TMD 改,老子不干了 x3
pick 75bcb30 再 TMD 改,老子不干了 x4

# Rebase 4be98a7..75bcb30 onto 4be98a7 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.

需要重点注意的是相对于正常使用的 log 命令,这些提交显示的顺序是相反的。

注意其中的反序显示。交互式变基给你一个它将会运行的脚本。它将会从你在命令行中指定的提交(HEAD~4)开始,从上到下的依次重演每一个提交引入的修改。它将最旧的而不是最新的列在上面,因为那会是第一个将要重演的。

如果只想修改 commit 信息的话,可以将前面的 pick 改为 r 或者 reword 即可,修改方式是按照 vim 编辑器的命令来的,这里通过 vim 的命令将文本进行编辑如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
r 875613d 再 TMD 改,老子不干了 x1
r e21c6f8 再 TMD 改,老子不干了 x2
r 2d6b84e 再 TMD 改,老子不干了 x3
r 75bcb30 再 TMD 改,老子不干了 x4

下面的省略了,之后 wq 保存并退出

当保存并退出编辑器时,Git 将你带回到列表中的最后一次提交,把你送回命令行并提示以下信息:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
TMD 改,老子不干了 x1

下面的省略了

在这里同样是需要用 vim 命令来修改的,把 message 修改完成后同样 wq 保存退出,会继续提示 再 TMD 改,老子不干了 x2 的内容,依次修改即可,最后效果,这样就把多次吐槽的 message 修改完毕了

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git log --oneline

57616cd (HEAD -> main) 水光潋滟晴方好,山色空蒙雨亦奇
0aeb8dd 自测完成
a8e5c7f 完成自测
ca7c292 好好学习
4be98a7 这次的改动很符合实际应用情况,果然还是产品了解需求
bbcc6ee (origin/main, origin/HEAD) Initial commit

通过命令的提示可以看出 git rebase -i 下面有多个修改选项可以使用,通过不同的选项来达到不同的修改目的:

  • p, pick = use commit
  • r, reword = use commit, but edit the commit message
  • e, edit = use commit, but stop for amending
  • s, squash = use commit, but meld into previous commit
  • f, fixup = like "squash", but discard this commit's log message
  • x, exec = run command (the rest of the line) using shell
  • b, break = stop here (continue rebase later with 'git rebase --continue')
  • d, drop = remove commit
  • l, label= label current HEAD with a name
  • t, reset= reset HEAD to a label
  • m, merge [-C | -c][#] create a merge commit using the original merge commit's message (or the oneline, if no original merge commit was specified). Use -cto reword the commit message.

压缩提交

上面的操作产生了四次提交,通过交互式变基工具,也可以将一连串提交压缩成一个单独的提交。在变基信息中脚本给出了有用的指令:

s, squash <commit> = use commit, but meld into previous commit

如果,指定 “squash” 而不是 “pick” 或 “edit”,Git 将应用两者的修改并合并提交信息在一起。所以,如果想要这三次提交变为一个提交,可以这样修改脚本:

再次执行 $ git rebase -i HEAD~4,并修改后面的三次提交,将 pick 改为 squash,并执行 wq 保存

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
pick ca7c292 好好学习
squash a8e5c7f 完成自测
squash 0aeb8dd 自测完成
squash 57616cd 水光潋滟晴方好,山色空蒙雨亦奇

# Rebase 4be98a7..57616cd onto 4be98a7 (4 commands)

当保存并退出编辑器时,Git 应用所有的三次修改然后将你放到编辑器中来合并三次提交信息:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
You asked to amend the most recent commit, but doing so would make
it empty. You can repeat your command with --allow-empty, or you can
remove the commit entirely with "git reset HEAD^".
interactive rebase in progress; onto 4be98a7
Last commands done (2 commands done):
   pick ca7c292 好好学习
   squash a8e5c7f 完成自测
Next commands to do (2 remaining commands):
   squash 0aeb8dd 自测完成
   squash 57616cd 水光潋滟晴方好,山色空蒙雨亦奇
  (use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'main' on '4be98a7'.
  (all conflicts fixed: run "git rebase --continue")

No changes
Could not apply a8e5c7f... 完成自测

如果出现了 git rebase --continue 则需要根据提示继续操作,会让你对每次提交都进行一些修改操作,这里将后续的每次修改,都只保留了 水光潋滟晴方好,山色空蒙雨亦奇 的提交信息

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ git log --oneline

ce26c55 (HEAD -> main) 水光潋滟晴方好,山色空蒙雨亦奇
4be98a7 这次的改动很符合实际应用情况,果然还是产品了解需求
bbcc6ee (origin/main, origin/HEAD) Initial commit

当你保存之后,你就拥有了一个包含前三次提交的全部变更的提交。

通过 git rebase 还能进行其他的对历史提交的修改错误,具体可见 Git-工具-重写历史

后话

本来不想继续写,因为写这个很麻烦,比如你要写你如何解决冲突;如何使用 Git log 进行自我保护(如何根据 Git log 把锅甩给其他同事);如何查看历史变更定位到最开始的 bug 等等一系列问题,都需要自己做一些冲突来模拟,自己做的记录往往不能复现工作中多个同事之前的各种冲突情况,所以这个复现的步骤也比较麻烦。只能凑合写写,希望对你有所帮助。

前几天认识很久的阿姨,问了我很多 Git 解决冲突的问题,本来想等等有空在写,毕竟我也比较懒,现在阿姨离职了,虽然和我关系不大,但还是于心有愧,打算花点时间把她遇到的一些问题和我平常解决实际冲突的问题,赶紧写一下。祝阿姨找个更顺心的工作,下一个更香??。

这篇主要写了一些常见的教程、一些基础的配置和对提交历史的改写。下一篇会介绍一些常见的工具和冲突的合并操作。

后记的后记

关于写重写提交记录,其实是我真实的一个情况,当时我们的项目组,经常在代码里面写诗、日记、工资记录、吐槽产品、吐槽运维(这个主要是我)。代码里面注释虽然不是很详细,但是每个人的最近的心理状态还是清晰的记录在了每一行代码注释中,成了宝贵的财产。

记得有次和 F4 聊天的时候,在 IDEA 中提交代码的时候,把聊天内容写到了上面,并执行了 git pull,当时在 gitlab 上,马上就显示出来了,我赶紧重写了提交记录并强推了一波,才不至于尴尬。

吐槽写在代码注释里面就可以了,不要写在提交的 commit message 中哦 ?

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-18,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 双鬼带单 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Git——常用命令总结
思索
2024/08/14
1110
git 更新历史提交
有时候我们在git commit后才发现,之前的一些提交有些问题,比如有些代码忘提交了或者有一些typo需要修改。如果要修改的地方是需要添加到最后一次提交上的,那么可以参考我的这篇博文修改,如果是在非最后一次提交上的,那么就需要用git rebase来操作。这里简单记录一下操作的过程。
王云峰
2023/10/23
2800
日常开发过程中实际场景下使用git的一些简单总结
公司内部有代码仓库和 github 仓库邮箱不一致。例如已经全局配置了公司内的信息
ACK
2020/05/26
4730
关于 Git 重写提交历史的一些笔记
傍晚时分,你坐在屋檐下,看着天慢慢地黑下去,心里寂寞而凄凉,感到自己的生命被剥夺了。当时我是个年轻人,但我害怕这样生活下去,衰老下去。在我看来,这是比死亡更可怕的事。--------王小波
山河已无恙
2023/01/30
4060
学会这 11 条,你离 Git 大神就不远了!
支持使用 merge 的开发者,他们认为仓库的提交历史就是记录实际发生过什么,它是针对于历史的一个文档,本身其实是有价值的,我们不应该随意修改。我们改变历史的话,就相当于使用“谎言”来掩盖实际发生过的事情,而这些痕迹是应该被保留的。可能,这样并不是很好。
民工哥
2021/04/21
3600
git 修改倒数二个提交
之前有介绍 commit --amend , 通过这个命令可以修改最新的commit提交。 还不了解的可以查看git 修改最后一次commit 文章
艳龙
2021/12/16
5600
Git 帮助手册
国外网友制作了一张 Git Cheat Sheet,总结很精炼,各位不妨收藏一下。
硬件开源小站
2023/04/07
4.4K1
Git 帮助手册
Git 常用命令清单笔记
这里是我的笔记,记录一些git常用和一些记不住的命令,这个笔记原本是基于 颜海镜的文章增加的,后面慢慢增加了许多内容,可以看出的的学习轨迹。分享出来方便自己查看,也许能帮助到你。
小弟调调
2018/09/11
7870
如何维持整洁的 Git 提交记录?送你三个锦囊!
背景 大家都有学习如何规范简洁的编写代码,但却很少学习如何规范简洁的提交代码。现在大家基本上都用 Git 作为源码管理的工具,Git 提供了极大的灵活性,我们按照各种 workflow 来提交/合并 code,这种灵活性把控不好,也会带来很多问题 最常见的问题就是乱成一团的 git log history,那真的是老太太的裹脚布, 又臭又长, 个人极其不喜欢这种 log 造成这个问题的根本原因就是随意提交代码。 代码都提交了,那还有什么办法拯救吗?三个锦囊,就可以完美解决了 如果您正在学习Spring C
程序猿DD
2023/04/04
3750
如何维持整洁的 Git 提交记录?送你三个锦囊!
【linux命令讲解大全】013.Git:分布式版本控制系统的先驱和常用命令清单(二)
我还遇到了如下面错误,lab默认给master分支加了保护,不允许强制覆盖。Project(项目)->Setting->Repository 菜单下面的Protected branches把master的保护去掉就可以了。修改完之后,建议把master的保护再加回来,毕竟强推不是件好事。
全栈若城
2024/03/02
1120
【Git】Git 命令参考手册
在交互式 rebase 的编辑界面,使用 squash 或 fixup 合并提交。
LuckiBit
2024/12/11
3310
【Git】Git 命令参考手册
Git 从入门到精通,这篇包教包会!
集中化的版本控制系统,诸如 CVS,Subversion 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
java思维导图
2020/03/03
2.7K0
如何进阶成公司 Git 小能手(常见问题总结)
Git 命令对于程序员的你来说再熟悉不过,但是发现好多小伙伴都是会一些基本的提交流程,当遇到问题的时,查到的命令还不敢用,总是请教组里那几个精通 Git 的小伙伴。本文对 Git 使用过程中常出现的问题进行总结并且对 Git 的一些误区概念说明了一些,看完后记得自己尝试下,希望你也能成为组里被请教的那 个 Git 小能手。
coder_koala
2020/03/18
5630
如何进阶成公司 Git 小能手(常见问题总结)
开发者应该知道的 50 条最实用的 Git 命令
Git是一个分布式版本控制系统,可以帮助开发人员在任何规模的项目上进行协作。Linux内核的开发人员Linus Torvalds在2005年创建了Git,以帮助控制Linux内核的开发。
前端修罗场
2022/07/29
1.8K0
45个 GIT 经典操作场景,专治不会合代码
git对于大家应该都不太陌生,熟练使用git已经成为程序员的一项基本技能,尽管在工作中有诸如 Sourcetree这样牛X的客户端工具,使得合并代码变的很方便。但找工作面试和一些需彰显个人实力的场景,仍然需要我们掌握足够多的git命令。
程序员小富
2022/03/04
1.8K0
45个 GIT 经典操作场景,专治不会合代码
Git入门到高级系列2-git高级操作
项目分支就是版本库的一个副本,有了分支后可以把你的工作从开发主线上分离开来, 以免影响开发主线。
老马
2019/05/25
1.3K0
Git提交合并提交及注释
本地开发时,可以随时去提交写好的代码,但这样会导致提交历史比较多,推送到远端或者发起Pull Request显得比较杂乱,这时就可以使用rebase命令将几次提交或者全部提交合并成一次提交。
程序新视界
2021/12/07
7320
通过 41 个 问答方式快速了解学习 Git
Git是什么? Git是目前世界上最先进的分布式版本控制系统(没有之一,不接受任何反驳)。
Javanx
2019/11/01
1.6K0
相关推荐
Git——常用命令总结
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档