Git管理修正(取消跟踪、合并commit)

本文总结了最近使用Git时候遇到的两个问题:

1. 当将不必要跟踪的文件加入到仓库后如何处理?

2. 提交了多个功能相同的commit后如何处理?

总结经验

  1. 在创建仓库的一开始,就要设置号.gitignore文件,用于过滤掉不需要跟踪的文件和文件夹
  2. 谨慎提交commit,确保每个commit中所有的改动都是跟同一个任务相关的。

我是怎么解决上述两个问题的

1. 移除对文件/文件夹的跟踪,但不删除

  • 使用命令git rm --cached ignore_target_file 删除对某个文件的跟踪
  • 新建.gitignore文件,使用下列规则添加要忽略的文件或者文件
    • 所有空行或者以注释符号 # 开头的行都会被 Git 忽略。
    • 可以使用标准的 glob 模式匹配。
    • 匹配模式最后跟反斜杠(/)说明要忽略的是目录
  • 举例,我的.gitignore文件内容如下
# 忽略.gitignore文件
.gitignore
# 忽略.idea/文件夹
.idea/
# 忽略target/文件夹
target/

执行移除,新建.gitignore文件之后,再次git status就可以看到,这些讨厌的多余文件已经不被跟踪了。什么样的文件需要被忽略?编译生成的文件夹,如target目录;机器自动生成的,我们不会手动修改的隐藏文件,如.idea目录;中间文件,例如java项目中的.class文件。

2. 合并多个相似的commit

  • git rebase -i HEAD~4
  • 将除了第一行(最老的那个commit)之外的行首的pick全部换成squash
  • :wq保存并推出
  • 修改最新的commit message即可

参考资料

  1. Git基础–记录每次更新到仓库
  2. Git使用规范流程

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-19 10:36:08

Git管理修正(取消跟踪、合并commit)的相关文章

GIT 分支管理:创建与合并分支、解决合并冲突

分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN. 如果两个平行宇宙互不干扰,那对现在的你也没啥影响.不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN! 分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了.如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险. 现在有了分支,就不用怕了.你

【转】git合并commit

有时commit太多,而且可能一个commit只是提交一个小bug,那么合并commit势在必行.有两种方法:一是在提交最后一个修改的commit使用参数,这时之前的一个commit将会合并到这个即将提交的commit中来:git commit -a --amend -m "my message here"如果之前有一个提交,并且信息为:git commit -a -m "my last commit message" 则这个commit message将不存在.但

git取消跟踪文件

取消跟踪文件: $git rm --cached FILENAME 取消跟踪目录: $git rm --cached FILENAME -r

Git管理项目实例说明-记录和跟踪项目

假设一个HTML项目,使用Git来记录和跟踪这个项目,包括以下内容:1)创建版本库.2)添加与修改文件.3)创建新分支.4)打标签并整理版本库.5)克隆版本库. 1.创建版本库 Creating a Repository在Git中,版本库(.git目录)是与工作目录树并排放在同一个目录中的.本例中,要创建一个HTML页面,给这个项目取名为mysite.首先创建一个同名目录"mysite",并进入到这个目录,然后输入命令git init.[[email protected] ~]# mk

git分支管理之创建与合并分支

在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支.截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支.HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支. 一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点: 每次提交,master分支都会向前移动一步,这样,随着你不断提交,m

git rebase -i 合并commit

每次可能修改一个小的bug就会有一个提交,或者写了一小段代码就提交了一次. 这样经常会有多个commit,对此我们用git rebase -i HEAD~n来合并多个commit为一个commit. 如下图所示: 先用git status 查看下有多少个commit,下图中提示 Your branch is ahead of 'origin/master' by 2 commits. 很明显是2个commits待push. git log 里的内容请忽略掉. 现在用git rebase -i H

git管理修改

为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件. 新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改. 为什么说Git管理的是修改,而不是文件呢?我们还是做实验.第一步,对readme.txt做一个修改,比如加一行内容: $ cat readme.txt Git is a distributed version control system. Git is fre

2017-03-10<Git管理修改>

Git管理修改 Git跟踪并管理的是修改,而非文件. 什么是修改? 比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改. 实验: 第一步,对readme.txt做一个修改,比如加一行内容:Git tracks changes. $ cat readme.txt Git is a distributed version control system. Git is free software

使用 Git 管理源代码

在现代软件开发项目中,要成为一个有效的软件开发人员,我们必须能够与其他项目贡献者并行进行开发.源代码管理(SCM)系统不是什么新思想.为了编写一些能够更快速.简单地开发以后软件项目的软件,已经进行了很多尝试.最新的源代码解决方案都包含了版本控制系统,它可以对源代码的修改进行回滚,从而将有害的代码剔除出项目之外,或者简单地跟踪哪些人修改了代码的哪些行的内容.版本控制系统试图解决开发人员在试图同时对某个文件进行修改时所出现的冲突问题,可以防止用户覆盖其他人所作的修改.源代码管理使用的很多流行解决方案