Git基础

working directory

stage/index

HEAD

git init

git add

如果git add，文件会被tracked，此时修改文件，会出现Changes not staged for commit

可见file1.txt虽然更新了，但是并没有被更新到暂存区。

这时候的再次执行git add操作，会在暂存区生成一个新的git object，并且新的修改的记录也提交到了暂存区

但是如果已经git add过，git commit会把修改直接commit到本地仓库

git commit实际上是一次快照，记录一个版本的信息。

此时对文件进行了修改，commit的还是上个版本的，stage里已经是最新的文件，需要commit才能把当前的文件作为快照保存起来。

再次提交，发现多了个parent的信息，指向上一个commit

git commit之后，文件还是会在暂存区，还是之前的ecd2文件，所以如果对文件进行了修改需要进行git add才能把修改提交到暂存区，git是无法追踪到文件的新修改的。

可见object对象是被压缩过的，如果直接打开就是乱码，解压才能看到文本信息。

git commit的同时会把文件更新到暂存区，git commit相当于要先add修改到暂存区，再commit

如果没有add过，就不属于git管理，就无法进行commit

如果一个文件没有被git add过，他就不受git的管理，所以file5在任何一个branch都是有的。

而file1-4则会受到checkout branch的影响。

命令
git init	初始化git仓库，但是不会做任何操作， 与git clone出来的不同
git cat-file -p hash	查看git object的内容
git ls-files --stage	查看暂存区的文件
git add filename/*	添加文件/修改后的文件 到暂存区
git commit filename -m "message"	commit 生成版本的快照
git status	查看git状态
git rm --cache filename: 历史版本里还有，但是当前工作区没有，提交的时候也不会有 git rm -f filename： 删除暂存区和工作区的文件
撤销已提交的版本库，不会修改暂存区和工作区 git reset --soft hash 撤销已提交的版本库和暂存区，不会修改工作区 git reset --mixed hash git reset --hard hash 工作区也会修改
git rebase -i HEAD~3 合并多个版本 pick => s 在弹出来的vim界面，把下面两行改成s，就会把后两次压缩到第一行 git rebase --abort	https://segmentfault.com/a/1190000007748862
git rebase -i HEAD~3 修改多个版本 pick => s git commit --amend 分别修改对应的commit message 就可以实现批量修改commit message
git commit --amend git commit --amend --no-edit	修改message或者提交内容 首先作出你想要补上的修改， 暂存它们，然后用 git commit --amend 以新的改进后的提交来 替换 掉旧有的最后一次提交
git push -f origin feature:feature [本地] ：[远程]	强制push到远程库
git ls-tree -r HEAD

本地分支

在本地创建分支 git checkout -b branchname 创建并切换到分支。此时两个分支的文件内容是完全一致的。

创建一个分支可以理解为新建了一个feature指针。指针指向了当前最后的一次commit，

当在当前的feature分支进行的新的commit之后，feature的指针向后进行了移动，指向了新的commit。

命令
git log	git操作的log git log参数
git reflog	branch 指针变化的log
git checkout -b branchname	创建并切换到分支
git log --graph --oneline --all	查看所有分支

如果此时checkout到master分支，就会切换到master分支所指向的那一个版本。

再在master 快进merge到feature 此时都指向一个commit了

远程分支

git clone

在自己本地的master分支工作，远程的master分支也会有更新，git fetch会获取新的数据

git fetch

git remote add origin https://github.com/paranoiddemon/test-git.git	添加远程仓库
git push -u origin master:master git push -u origin master:main 后面是远程分支名，如果省略，就会创建一样名字的分支
git stash git stash save "test-cmd-stash" git stash apply/pop git stash drop git stash list	https://www.cnblogs.com/tocy/p/git-stash-reference.html
git checkout branchname
git branch -vv 显示跟踪的分支
git push origin --delete feature 删除远程的feature分支 git fetch + git merge 会比较好 git fetch --all
git branch branchname 创建分支 git checkout branchname 切换到指定分支 => git checkout -b branchname
git fetch git merge origin/master fetch只是创建远程分支在本地的拷贝origin/master，再执行合并操作 => git pull origin master:feature 把远程的master分支合并到本地的feature分支，如果是合并到本地的master分支 则可以省略 :master
git checkout server + git rebase master => git rebase master server :git rebase [basebranch] [topicbranch] 切回到master 快进合并 git checkout master git merge server
git push --force origin feature:feature [localbranch]:[remotebranch]	强制覆盖服务器上的记录
fast forward: git checkout master git merge hotfix git branch -d hotfix 删除分支 git merge branchname ：当前所在分支合并指定的分支 如果产生冲突处理完要git add表示已经处理完冲突
git branch --merged: 如果已经合并了，不用的分支可以删掉 git branch -d testing git branch --no-merged
git ls-remote
git remote show

git merge vs git rebase

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行 变基操作，这样，你才能享受到两种方式带来的便利。

工作目录下的每一个文件都不外乎这两种状态：已跟踪 或 未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。

工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们， 而你尚未编辑过它们。

编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。

Git使用及原理