关于Git的使用_git init一天白干?-CSDN博客

本文链接：https://blog.csdn.net/Cici__zc/article/details/119850246

创建版本库

先创建一个空目录hi，也就是空文件夹，在终端输入命令cd xxx进入这个空目录，而后可以输入命令pwd查看当前目录的路径。
通过git init命令初始化，把这个空目录变成Git可以管理的仓库。这是一个空的仓库，并且当前目录下多了一个.git的目录，这个目录就是Git用来跟踪管理版本库的，不要手动修改这个目录里的文件，不要破坏仓库。
现在可以开始编写一个readme.txt文件，一定要放到一开始创建的hi目录下，不然Git找不到。写完内容后，把这个readme.txt放进Git仓库需要两步：1、用命令git add告诉Git，即git add reademe.txt，当你想要添加多个文件时，可反复多次使用git add 。2、执行完上面的命令后没有任何显示，再用命令git commit -m “本次提交的说明”`。

编写内容

成功提交readme.txt文件后，当你之后修改了文件内容，输入命令git status查看结果，命令行会显示：readme.txt被修改过了，但还没有提交修改，如果你想查看具体修改了什么内容，可以使用命令git diff，你可以在命令行里看到你想要的信息。
了解了readme.txt修改的内容，下一步就是将它提交到仓库，还是两步：1、git add reademe.txt。2、git commit -m "本次提交的说明"。
提交后，用git status命令查看仓库的当前状态，命令行显示当前没有需要提交的修改，工作目录是干净的（working tree clean）。

查看修改内容

当你不断的对文件进行修改、提交后，如果你想要查看你过去修改的内容，这时候版本控制系统就真正起到作用了，使用git log命令查看，命令行显示从最近到最远的提交日志，如果想要看更加简洁的输出信息，可以用命令git log --pretty=oneline，命令行里显示的一大串类似1094adb…是commit id（版本号）。
如果想要把修改很多次的readme.txt回退道上一个修改的版本，首先需要知道当前版本是什么版本，在Git里，HEAD表示当前版本，上一个版本就是HEAD^ ，上上一个版本就是HEAD^ ，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
现在把readme.txt回退到上一个版本，使用git reset命令，git reset --hard HEAD^，然后查看文件内容，果然被还原成上一个版本了，用git log查看现在的版本库状态，之前最新的那个版本已经看不到了，如果想要找回丢失的那个版本，只要你上面的命令行窗口还没有被关掉，可以顺着上面找到那个版本的commit id，用命令git reset --hard 1094a，再去查看
readme.txt文件，发现最新的那个版本又回来了。如果你的电脑已经关了，而你又想恢复到新的版本，找不到新版本的commit id，Git提供了一个命令 git reflog用来记录你的每一次命令，然后你会看到版本号，这样也能解决。

工作区和暂存区

暂存区是Git很重要的概念，弄明白了暂存区，就弄明白了Git的很多操作到底在干什么。电脑里能看到的文件夹hi就是一个工作区，工作区有一个隐藏目录.git，就是Git的版本库，版本库里存了很多东西，其中最重要的就是称为stage（或者index）的暂存区，还有Git为我们自动创建的第一个分支 master，以及指向master的一个指针叫HEAD。
上面写了将文件放进Git版本库里是分两步执行的：
第一步git add <filename>就是把文件添加到暂存区；
第二步git commit -m "本次提交的说明"，就是把暂存区的所有内容提交到当前分支。
总的理解就是，把需要提交的文件都放到暂存区，然后一次性提交暂存区所有的文件。

Git管理的是修改，而不是文件

修改就是，新增了一行、删除了一行、更改了某些字符，或者创建一个新的文件，都是修改。当我们对一个文件进行一个修改，然后进行添加git add <filename>，然后再修改这个文件，进行提交git commit -m "本次提交的说明"，提交后查看状态git status，发现第二次的修改并没有被提交，回顾一下刚刚的操作过程：

第一次修改 -> git add -> 第二次修改 -> git commit

当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

所以，提交第二次修改的正确做法是：

第一次修改 -> `git add` -> 第二次修改 -> `git add` -> `git commit`

撤销修改

场景一：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- filename。

这里有两种情况：

一种是文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是文件已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

场景二：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景三：前提是没有推送到远程库，已经提交了不合适的修改到版本库时，想要撤销本次提交，参考上面第三点“查看修改内容”里的版本回退。

删除文件

输入命令rm <filename>，即可删除你想要删除的文件，这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了，现在你有两个选择：

一是确实要从版本库中删除该文件，那就用命令git rm <filename>删掉，并且git commit，然后文件就从版本库中被删除了。另一种情况是删错了，因为版本库里还有，所以可以很轻松地把误删的文件恢复到最新版本，输入命令恢复版本git checkout -- filename。

远程仓库

Git最重要之一就是远程仓库，Git全名是分布式版本控制系统，同一个Git仓库可以分布到不同的机器上，而GitHub可以提供Git仓库托管服务，只需要注册一个GitHub账号，就可以免费获得Git仓库，而不用去搭建服务器。

本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以需要创建SSH Key，GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

现在你已经在本地创建了一个Git仓库，又在GitHub上创建了一个Git仓库，这两个仓库可以进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作。
在GitHub上创建一个新的仓库，然后将本地库的所有内容推送到远程库上，git push -u origin master，实际上就是把当前分支master推送到远程仓库，由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库。

分支管理

分支管理简直是太厉害了。如果公司准备开发一个新功能，大家团队合作可以创建一个属于自己的分支，别人看不到，你在自己的分支上干活，直到开发完毕，再一次性合并到原来的分支上，这样既安全也不互相影响工作。
当我们创建新的分支dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上，新提交一次后，dev指针往前移动一步，而master指针不变。假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并。
例如，首先我们创建分支dev，输入命令git checkout -b dev，用git branch查看当前分支，此时应该是处于dev分支上的，然后我们在readme.txt做个修改，然后git add提交git commit提交，此时这个提交是在dev分支里进行的，现在dev分支的工作已完成，切回master分支，再查看readme.txt文件，发现刚刚在readme.txt文件里做的修改不见了。这是因为那个提交是在dev分支上，而master分支此刻的提交点并没有变。现在，我们把dev分支的工作成果合并到master分支上，输入git merge dev ，用于合并指定分支到当前分支，合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。合并完成后，就可以放心地删除dev分支了。删除后，查看git branch，就只剩下master分支了。

Feature分支

当在开发时，总会有不断的需求和功能添加进来，当添加一个新功能，最好新建一个feature分支，在这上面开发，完成后合并，最后删除此分支。

当你在feature分支完成了功能的开发后，又接到上级通知不要这个功能了，虽然白干了，但是分支里包含了公司的机密资料，还是必须要销毁，如果feature分支还没有合并过，使用命令git branch -d <filename>删除feature分支，命令行会显示当前分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数，所以就用git branch -D <filename>强行删除。

多人合作分支

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你自己的情况而定。

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改，当你同事已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送时，此时会推送失败，因为你的同事和你的提交有冲突。

解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送。

多人协作的工作模式通常是这样：

首先，可以试图用git push origin <branch-name>推送自己的修改；

如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

如果合并有冲突，则解决冲突，并在本地提交；

没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功；

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令
git branch --set-upstream-to branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

补充一下git stash和cherry-pick

git stash相当于备份当前的工作内容保存在git仓库里，将一个修改后的工作区中的改动保存起来，将工作区恢复到改动前的状态。

具体描述：
当你想要保存工作区的当前状态，并想要回到一个干净的工作目录时，可以使用git stash命令。该命令保存本地修改，并将工作区恢复到HEAD指向的commit状态。
git stash保存的内容可以通过命令git stash list列出，可以通过git stash show命令查看，可以通过git stash apply命令恢复(可以恢复到不同的commit/分支上)。不加任何参数调用git stash命令等同于git stash push。Stash信息默认展示为"WIP on branchname …"，但是你可以在stash命令执行的时候，添加相关描述性的信息。
创建的最新的stash信息保存在"refs/stash"，稍微早一点的stash可以通过这个引用的reflog查看，也可以通过通常的reflog语法命名规则指代。比如“stash@{0}”表示最新创建的stash，“stash@{1}”是更早些的stash。stash也可以只通过序号指代，比如"n"代表"stash@{n}"。