小谈GIT原理和使用
Git诞生
大家都知道linux 那你知道linux是谁开发的吗？ 不错是linus开发的 在1991年linus 创建了开源的linux
但linux的功能强大的完善却靠的是全世界的热心的代码志愿者完成的 在2002年之前代码的管理是由各个大牛们将源代码通过diff的方式发给linus 然后由linus本人来手动合并代码 也许你会有疑问 为啥不讲这些代码放到版本控制器里 因为linus坚决的反对使用CVS和SVN 这些免费的集中式的版本控制不仅需要连接网络 并且使用速度超级慢 当时也由商用的版本控制管理系统 但这些都是收费的 跟Linus的开源精神不符合
这样的局面一直持续 到2002年 至今为止 Linux开源至今已经10年了 代码库之大已经让Linus 很难通过手工的方法来管理代码 于是Linus 选择了一个商业版的版本控制BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。这样平静的日子一直持续到2005年 Linux社区的兄弟们 在使用BitKeeper的同时 也在破译BitKeeper公司的协议 （ 这件事情还不止一个人在进行 ） 这件事情被BitKeeper公司发现了 于是BitKeeper 公司怒了 要收回Linux社区的免费使用权 Linus大神了 没有办法 也不想向BitKeeper公司低头 于是就花了两周的时间写了一个分布式的版本控制 于是风靡全球的GIT就此诞生了 ！！！
集中式和分布式
The centralized version control version library is placed on the central server. When we work, we first go to the central server to pull the code and then modify it and then push it to the remote. Its biggest feature is insecurity and inefficiency. If the central server is
broken Then everyone can’t work. It still needs to have a network. If you have a fast enough network in the local area network, it’s okay. If the network is slow, it may take 5 minutes to submit a code, and it’s still suffocating.
Compared with centralized version control, distributed version control has no concept of central server. Our own computer is a version control library. We can add, delete, modify and check locally without multi-person collaboration on the Internet. For example, if you modify a file A, you Colleague B also modified file A, and you both modified it locally. You don’t know what each other changed, so you need a middle point to convey to you what the other party has modified. This middle point is just for the convenience of everyone’s communication and modification points. It's just that communication is inconvenient. The middle point is the version control on the remote server.
Several concepts of git
work area
The directory of the project on our own computer is the project we develop daily
Repository
Also called the temporary storage area,
the warehouse used to manage your code can be understood as a directory, and all files in this directory are managed by git
git command
Every operation we do will be recorded by git, like a timeline. There are many nodes on each line, and each node represents our operation record.
version rollback
– git log View all submitted logs
– git log --pretty=oneline The log shows one line
and rolls back to the first submission record
git resegitt --hard [hardId]
此时的git log中 没有修改首次提交的记录
如果你此时你发现你不用回退版本 还是要用回退前的代码 如果此时你的命令行没有关闭 你可以直接找到最新提交的HEAD 那么直接回退到这个HEAD就行 如果你的命令行窗口关闭了 你不知道你最新的HEAD 那么你需要有用git reflog 查看所i有的记录
git reset --hard HEAD@{10} 回退到指定的版本
git log 查询是所有的正常的操作记录 不会记录回退操作记录
git reflog 查看所有历史版本 由于 查看历史版本信息太多 大多数是为了版本回退和恢复操作使用的
撤销文件
git checkout -- readme.txt
文件没有被保存在暂存区 修改后就是回到编写之前的状态 即跟版本库是一摸一样的
文件已保存在暂存区 修改就是回到添加到暂存区之后的状态
删除文件
rm test.txt
已存在暂存区
未存在暂存区
在status中没有记录
如果你不小删除了文件 可以用 checkout 撤销上一步的操作
git checkout -- test2.txt
关联远程仓库
如果你需要将你的代码作为一个备份 或者让别人来协助你完成 那么你可以在github上建一个远程仓库
当你建完仓库后 需要获取远程的仓库链接 将你的本地项目和远程仓库进行一个关联
git remote add origin https://github.com/sthbb/test-demo.git
接下来就是推送代码了 第一步是将你本地分支和远程的分支进行关联
git push -u origin master
-u 就是进行关连的
以后推送代码直接push就行了
上面 sthbb 就是你自己远程库列表 如果你写成别人的 关连是没有问题的 但是由于ssh不对 密钥不对 那么往远程推送代码是不行的
克隆项目
克隆项目有两种方式 git 和 http 由于git 支持很多种协议 默认的git://使用ssh，但也可以使用https等其他协议。
打标签
git 打标签打在之分支上的
打标签
git tag v1.0
查看标签
git tag
If you want to tag the historical submission records, you must first find the corresponding head and then tag the head
f52c633 short for historical head
git tag v0.9 f52c633
View label details
git show v1.0
create tag with description
-a tag name -m tag description
git tag -a v0.1 -m "version 0.1 released" 1094adb
delete label
git tag -d v1.0
Push tags to remote
git push origin v1.0
Push all tags to the remote
git push origin --tags
Delete the remote tag
first delete the local tag
git tag -d v1.0
delete remote
git push origin :refs/tags/v0.9
Create and switch branches
view branch
git branch
create branch
git branch dev
switch branch
git checkout dev
Create and switch branches
git checkout -b dev
merge branch
Merge dev branch on current branch
git merge dev
delete branch
git branch -d dev
If the branch you deleted has not been merged, you will be prompted to delete it carefully. After deleting, your modification will be lost
force delete branch
git branch -D dev
Since checkout and undo operations conflict, switch is used instead of checkout in the latest version
create and switch branch
switch branch
git switch -c dev
```typescript
git switch master
code staging
We often encounter, for example, I am developing a function and suddenly test it on my local branch and find an online bug that needs to be corrected immediately. Then you need to suspend your existing work to fix the bug. At this time, you need to put your Previously developed code is stored
Temporary storage
git stash
After you have modified the online bug, you need to continue your previous operation
and find the stash Id of your previously temporarily stored code
View all stashes
git stash list
Restoring the code
First, use git stash apply. The problem is that after the code is restored, there is still the previous code in the temporary storage area.
Second, use git stash pop to restore and delete the previous code
In actual development, you may save a lot of stash, and only one stash can be restored when restoring @{0} stash Id
git stash apply stash@{
0}
Copy the contents of a commit
For example, if you find a bug on the master branch, you may cut a branch from the master to hotfix and merge it into the master branch after the hotfix, but the dev branch does not contain the content you just modified. At this time, you do not want to merge the entire master branch into On the dev branch, you just want to merge the bug you just modified
, then you need to find the id of your commit and then cherry-pick it
git cherry-pick 4c805e2
In this way, you merge the code modified on 4c805e2 into your current branch
Remotely
View information about remote libraries
git remote
View the detailed information of the remote library. If you do not have permission, you will not be able to see the push information, only the fetch information.
git remote -v
Push branch to remote
git push origin dev
One case is that the branch you created has been associated with the remote, so you can push the code directly
Create a branch corresponding to the remote branch locally
git checkout -b dev origin/dev
One is that you create your branch and the remote is not associated, so you need to manually associate it
In actual development, for example, if you are going to develop a function, you pull a branch locally and then push it to the remote after the development is complete. You
may encounter the code you modified and the code modified by your colleagues as a file, so you need to update it first and then push it.
To github.com:michaelliao/learngit.git ! [rejected] dev -> dev
(non-fast-forward) error: failed to push some refs to
‘[email protected]:michaelliao/learngit.git’ hint: Updates were rejected
because the tip of your current branch is behind hint: its remote
counterpart. Integrate the remote changes (e.g. hint: ‘git pull …’)
before pushing again. hint: See the ‘Note about fast-forwards’ in ‘git
push --help’ for details.
git pull 也报错 说你的本地分支和远程没有进行关联
$ git pull There is no tracking information for the current branch.
Please specify which branch you want to merge with. See git-pull(1)
for details.git pull <remote> <branch>If you wish to set tracking information for this branch you can do so
with:git branch --set-upstream-to=origin/<branch> dev
与远程进行关联
git branch --set-upstream-to=origin/dev dev
如果你与远程进行关联后 再pull 报冲突 你解决冲突后再重新提交
注意：
- Tags are always linked to a commit. If the commit appears in both the master branch and the dev branch, then the label can be seen on both branches.
- git tags are not sorted chronologically but alphabetically
git log --graph --pretty=oneline --abbrev-commit
can see the merge situation of the branch, including the branch merge graph (–graph), one line display (–pretty=oneline), and the submission check code abbreviation (–abbrev -commit) shows