本 Wiki 开启了 HTTPS。但由于同 IP 的 Blog 也开启了 HTTPS,因此本站必须要支持 SNI 的浏览器才能浏览。为了兼容一部分浏览器,本站保留了 HTTP 作为兼容。如果您的浏览器支持 SNI,请尽量通过 HTTPS 访问本站,谢谢!
Git / GitHub Notes
Git 分为三个区域:工作区,暂存区,版本库:
打印信息的例子:
#git diff output example
#white, nothing changed, indicated in white
* @Author: Codinghare
* @Date: 2022-05-22 21:42:56
* @Last Modified by: hare
#start with "-", removed or replaced, indicated in red
- * @Last Modified time: 2022-05-30 00:16:57
#start with "+", changes to the file, indicated in green.
+ * @Last Modified time: 2022-05-30 00:42:45
退出使用按键 q
即可。
查看某个文件工作区与最新版本的区别:
git diff HEAD -- file
git commit 有一个非常好用的 tag amend
。这个 tag 允许我们对当前最新的 commit 的进行更新,而不是创建一个新的 commit。这个命令在修改当前 commit 中的一些细小错误时非常有用。
当然,虽然看上去是”更新“了 commit,amand
实际上还是创建了一个新的 commit,并取代了旧的 commit(只是不会有新的 commit)记录。但终端会弹出界面要求我们重新书写 comment(-m
里写的东西)。如果要维持之前的 comment,使用下面的命令:
git commit --amend --no-edit
打印信息的例子:
#SHA, unique id for the commit
commit 5f9c857051c2a9acc2036e90b4c965e16798bd6b
#Author
Author: hare <[email protected]>
#Date
Date: Thu Jun 2 23:14:49 2022 -0600
#comments, generated by git commit -m " "
fixed typos.
一些相关的 tag:
git log --online #shows the list of commits in one line format.
git log -S "keyword" #displays a list of commits that contain the keyword in the message.
git log --oneline --graph #Displays a visual representation of how the branches and commits
直接删除版本库文件夹下的文件并不能将其移除出版本库。查看会显示该文件的状态是被删除:
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: test.txt
git rm <file>
,然后做 git commit
git restore <file>
BackTracking 的主要内容:
关键的概念:
reset
命令会更改当前的 HEAD commit 到指定的 commitgit reset
通常用于暂存区中存在着不符合要求文件的情况。比如不小心将错误的源文件送至暂存区后,可以使用 reset 命令将其移除出暂存区。git reset + SHA
使得对应的 commit 会成为当前的 HEAD commit。该 commit 之后的所有内容将不再成为项目的一部分。git checkout
则是对工作区的文件进行还原。当不小心修改了工作区中的文件时,可以利用该命令将其还原到 HEAD commit 时文件的状态,也就是没有被修改前的状态。git restore
替换了 git checkout
和 git reset
的部分功能:
# revert the file that has not been added to the staging area.
# git checkout -- <file>
git restore <file>
# moving the file that has been added to the staging area back to the working driectory
# git reset file
git restore --staged <file>
这个命令主要用于保存当前未完成的工作。比如当我们正在进行工作 A(brach A),然后接到要求去 B(branch B)进行另外工作的要求。此时我们就可以使用 git stash
将 A 这边的工作暂存;当完成 B 的工作后,回到 A,使用 git stash pop
就可以将之前未完成的工作取回,接着进行工作了。
这个命令避免了将未完成的文件进行 commit 的情形。该临时暂存的档案可以建立多个,可以通过 git stash –list
查看。
# saving the WIP
git stash
# revert the WIP but keep the saving
git stash apply
# delete the save file
git stash drop
# revert the WIP and delete the save file
git stash pop
$ git config --global alias.co "checkout"
$ git config --global alias.br "branch"
$ git config --global alias.glop "log --pretty=format:"%h %s" --graph"
#define global user name for the local repo
git config --global user.name "xxxx"
#define email for the local repo
#must match the github user email
git config --global user.email "[email protected]"
git remote add origin https://repo.address
git push -u origin master
#check if the repo linked
git remote -v
Git 允许创建不同的 branch 来对项目进行实验;也就是说,新的 branch 是作为之前版本的改动而存在的;我们可以在新的 branch 中进行开发和实验,直到功能稳定之后再合并到主要版本中,再作为新的项目版本进行发布。新的 branch 包括两部分:
new_branch
的新 branch。branch_name
的 branch-D
tagbranch_name
的 branchbranch_name
的 branch 到 master
# create a new branch
git branch <new_branch_name>
# create and switch to a new branch
git switch -c <new_branch_name>
# list all branchs
git branch
# switch to a branch
# old school: git checkout <branch_name>
git switch <branch_name>
合并 branch 到 master 的前提是,master 在 branch 新建之后没有发生改变。如果改变发生,之后再将 branch 合并回 master,会造成合并冲突(merge conflict)。这种冲突是因为 master 的不一致导致的。
当冲突发生的时候,会产生如下的信息:
Auto-merging conflict_file_name
CONFLICT (content): Merge conflict in conflict_file_name
Automatic merge failed; fix conflicts and then commit the result.
之后我们再打开冲突发生的文件,会有如下的内容:
#master version
<<<<<<< HEAD
-content of master version
=======
#branch version
-content of branch version
>>>>>>> branch
-------------------
这一段代表了当前 master
与 branch
开始时的 master
中的内容差异。我们可以选择保留当前的 master
的修改,或是保留 branch
中对应的 master
内容。但无论如何,除了要保留的内容以外,其他所有内容(包括 git 自动产生的标记)都需要删除。
git 中可以对指定的分支做 tag:
# switch to the branch before tagging
git tag <tag_name>
# listing exsiting tag
git tag
#deleting tag
git tag -d <tag_name>
#deleting tag on origin
git tag -d <tag_name>
git push origin :refs/tags/<tagname>
默认的 tag 是关联到当前分支的最新 commit 上的。如果希望对指定的 commit 打 tag (比如忘记打了),需要加上 commit id:
git tag <tag_name> <commit id / 7 digits>
# creating tag with extra message
git tag <tag_name> -m "your message here" <commit id>
打好 tag 以后就可以很方便根据 tag 查看 commit 了:
git show <tag_name>
tag 默认存在本地。如果要推送到远程,使用以下命令:
git push origin <tag_name>
#push all tags at once
git push origin --tags
在多人使用 git 进行合作中,一般会需要:
所有这些内容都可以通过 Remotes 来实现。remotes 允许多个合作者(可以处于不同地方)进行同一个项目的开发。每个人都可以独立在自己的内容上工作,然后最终合并到一起。
# find the remote on remote_location and clone the your directiory called clone_name
# remote_location could be a website, or file path
git clone remote_location clone_name
#list all remotes
git remote - v
#updates the local copy
git fetch
#merge changes in the origin to the local copy
git merge origin/master
#push your branch feature to the remote
git push origin your_branch_name
#fetch and merge the newest master
git pull origin master
我们在 push 的时候,如果 origin 对应分支已经发生了改变(别人提交过了),那么需要用 fetch/merge 或是 pull 来同步 origin 中的新内容到本地分支。但这样做的问题在于,我们在本地的 commits 实际上处于 pull commit 之后了,那么从路径上来说我们的 commit 之于 master 的新内容之前。这样顺序是不对的。
git rebase
会将本地 commit 的提交历史止于 pull(origin 内容更新之后),等于重新顺理了一遍提交顺序。这样看使提交历史起来更加直观。
# before
|\
| * d662d56 (origin/master) Update readme.md.txt
* | 30bcffe modified hello2.py
* | 9091cc7 add hello2.py
|/
# after git rebase
* 280680e (HEAD -> master) modified hello2.py
* 8337019 add hello2.py
* d662d56 (origin/master) Update readme.md.txt
#after push
* 280680e (HEAD -> master, origin/master) modified hello2.py
* 8337019 add hello2.py
* d662d56 Update readme.md.txt
clone 命令是将指定的共享项目拷贝到本地的项目中。当共享项目被拷贝后,git 会自动将其与 origin
关联。
# list all origins
git remove -v
# add origin
git remote add origin <address>
# remove origin (link)
git remote rm origin
如果本地版本没有及时更新(本地使用的版本已经在 origin 中被别人更新),可以使用 fetch 命令更新本地版本到最新。这个更新指的是信息的更新。用户在查看更新后可以自行决定是否合并 origin 的新内容到本地的对应 branch 中。
fetch 只会从 origin 下载 objects。这些 object 会存储在 origin/branch_name
中等待被合并。如果希望应用所有 origin 的新内容到本地,需要使用 merge 命令;也就是将 origin/branch_name
中的内容转移到 branch_name
中。
push 命令允许我们将本地完成的内容推送到 origin 中。
# first time push
# -u: push the new data and link the local branch to the cloud branch
git push -u origin master
如果知道想回滚版本的 hash:
git reset --hard hash
如果不知道:
#find the hash
git reflog
#backtrack
git reset --hard hash
这种情况一般出现在:
这种情况下,无需去 dev 分支上再把 bug 修改一遍,只需在 dev 分支上使用如下命令即可合并 Bug 修复内容到 dev:
git cherry-pick <bug-fix-commit-code-7-digits>
#author + branch type + short branch description
hare_feature_dashboard_notifications
首先查找用户主目录下有没有 id_rsa
和 id_rsa.pub
的文件,如果没有,使用以下命令生成 key
(命令中的邮箱使用自己的邮箱):
ssh-keygen -t rsa -C "[email protected]"
运行以上命令后访问 .ssh
目录,会找到 id_rsa
与 id_rsa.pub
两个文件,前者是私有密钥,需要妥善保存;后者是公有密钥,可以放心告诉别人。
seting
中找到 SSH and GPG keys
,将刚才生成的 id_rsa.pub
中的内容作为一个新的 SSH key 添加到 GitHub中。
ssh -T [email protected]
如果显示以下文本就证明连接成功了:
Hi XXXX! You've successfully authenticated, but GitHub does not provide shell access.
到此就可以使用 git 命令对远程库操作了。
可能的解决方案:
sudo
进行 Git 命令的使用
Git XXX: fatal: could not set 'core.filemode' to 'false'
尝试修改 /etc/wsl.conf
,添加以下代码(没有则创建):
[automount]
options = "metadata"
之后运行:
wsl --shutdown
重启即可
fatal: Could not read from remote repository.
尝试将密钥文件夹复制给 root 一份:
sudo cp ~/.ssh/* /root/.ssh/
git config core.filemode false