- Git下载与安装
- 创建git版本库
- 时光穿梭机（版本回退）
- 时光穿梭机（工作区与暂存区）
- Git分支开启多人协作
- Git config与配置别名、打标签、忽略文件
- GitHub远程仓库
- GitLab搭建私有库
一、Git下载与安装
下载windows系统版本地址：https://git-scm.com/download/win
更多的其他版本地址：https://git-scm.com/download
再安装windows和mac上安装采用的是图形界面操作，傻瓜式下一步就好。linux或者unix系统采用命令行下载安装，Git官网有相应的下载安装命令说明。https://git-scm.com/download/linux
二、创建git版本库
2.1创建git本地版本库：
创建文件夹 —— 文件夹内右键 —— 选择:Git Bash Here(打开git控制台窗口)；
$ git init //初识化本地版本库
执行这条命令后会在当前文件夹下生成一个（.git）文件夹，本地版本库创建成功。
在这之前你可能没有设置你的git名称和邮件地址，这会让你无法提交文件，也就是后面git commit 指令提交文件到仓库会报这个错误（*** Please tell me who you are. ...）
git config --global user.name "Your Name" //your name--你的昵称（这里配置在全局的配置文件上） git config --global user.email "email@example.com" //email@example.com--你的邮件地址（这里配置在全局的配置文件上）
然后这里再介绍一个指令：git status，这个指令是用来查看仓库的状态：（下面这几个状态配合2.2的内容对照理解）
fatal: not a git repository (or any of the parent directories): .git
//当没有初识化仓库时，它会高数你不存在git存储库
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)
//1.创建仓库，工作区没有保存任何文件，暂存区、提交区也没有提交文件
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
readme.txt
nothing added to commit but untracked files present (use "git add" to track)
//2.工作区保存了文件，但没有提交到暂存区
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
//3.添加文件到暂存区，但还没有提交时的提示
On branch master
nothing to commit, working tree clean
//4.提交文件到提交区后，仓库的状态（又回到了创建仓库的初始状态了）
2.2在git仓库中创建文件 —— 添加到仓库 —— 提交到仓库
这里需要注意的是在window系统下，系统原生的记事本存在一些缺陷，建议使用Notepad++编辑器创建文件，或者使用专业的代码编辑器创建文件。
git add "readme.txt" //向仓库中添加readme.txt文件
创建文件这种事情我就不展示了，没有文件你提交啥？文件可以直接写在仓库目录下或者子目录下。
git commit -m "wrote a readme file" //向仓库提交添加的文件， -m是用来输入本次提交说明的，这里的说明是"wrote a readme file"，强烈不建议不添加说明的提交
三、时光穿梭机（版本回退）
在进入这一节主题内容之前来看一下git管理文件的基本原理：
有第二节中git status指令打印的状态可以了解到，git管理文件存在三种状态：工作区保存文件未添加至暂存区、文件被添加至暂存区但未提交到提交区、文件被添加到提交区。
如果一个文件只是像上面这个示图一样，从工作区到暂存区再到提交区这种非常理想的工作流程，这是不可能的，我们在编写代码的过程中存在各种修改、维护、版本更新。比如我们可能在工作区修改了代码，但是你突然发现有了更好的解决方案需要从头再来，这时候你更新的代码可能存在各个位置，你需要回到代码最初的状态怎么办？或者这个事情发生在暂存区？或者发生在提交区？
这种代码回退或更新操作就可以被看作是版本管理，通过git可以在代码版本的各个节点来回更替，是不是感觉就像是时光穿梭机一样，有了git你可以在你的代码上到达任意的一刻的节点。
3.1使用git log查看版本日志信息：
首先对一个文件执行三次添加提交操作，每一次都对文件内容做一些更改（建议从仓库初识化开始），建议依照廖雪峰大佬的这个教程：git教程：时光机穿梭（版本回退），然后使用git log指令查看文件提交日志：
//你会看到这样格式的日志被打印出来 commit 4905021a08be5b2637ea3876cf34c179319ccb99 //提交日志的id Author: Your Name <email@example.com> //提交用户信息：名称 <邮箱地址> Date: Wed Nov 13 11:40:53 2019 +0800 //提交时间
如果你正确执行了三次文件添加提交操作，打印出来就会有三个这样格式的日志信息，并且你最近提交的信息被放在第一组，安装倒序一次展示。
3.2使用git reset --hard Commitid穿梭到你想到达的任何提交节点：
//比如我第二次提交的版本commitid是88fdff6d5a79b69e72513f907df132f869b442b9 //使用reset --hard commitid回退到第二个版本 git reset --hard 88fdff6d5a79b69e72513f907df132f869b442b9
这是非常简单的操作，只要有对应的commitid你就能去到任何你想到达的提交节点，而这种操作实际上就是将提交的某个版本的文件加载到你的工作区。
3.3回退版本代码重新编辑提交到提交区，文件日志会如何变化？
//假设你已经进行了3.2的操作了，并且就回退到工作区的第二版本修改在提交，然后再查看日志： git log
这时候打印出来的结果是只有三个版本，并没有出现想象中的第四个版本，也就是说你将回退到工作区的第二个版本修改再提交以后，最新的提交日志覆盖了原来第三次提交的日志。
到这里又有了一个新的疑惑，这是因为相邻的回退修改造成的覆盖，还是只要是回退然后修改提交就会将该回退版本后面提交的版本日志全部覆盖吗？
那就尝试以下直接回退到第一个版本，然后再修改第一个版本提交，看看会发生什么？你会发现以下结果（日志被覆盖了）：
回退到某个版本后修改再提交，会将该回退版本后面提交的版本日志全部覆盖，只保留该回退版本到刚刚最近更新的版本日志。
3.4如果回退到某个版本并修改提交后，又想回到已经被覆盖的日志中的某个版本节点，可不可行呢？
答案是肯定的，这里分为两种情况：
第一种情况：命令行窗口还有要回到某个版本节点的commitid，就直接可以通过git reset --hard Commitid穿梭到你要去的版本。
第二种情况：命令行窗口被清空，或者重新启动的命令行窗口，不能直接获取commitid，可以通过git reflog查看所有日志的id：
1 git reflog
2 //会根据以下格式打印出所有提交和回退或其他版本操作信息
3 //fefcfb9 HEAD@{1}: reset: moving to fefcfb98424bc3baafc69544efe257f45e9a8b30
4 //...
注意这个信息又有些什么？
第一段：该版本的commitid前几位，可以通过该id的前几位截取部分穿梭到你要区的版本节点
第二段：版本头及日志编号
第三段：提交或者回退的版本信息，示例中的reset表示为回退的日志信息；当然还会有commit，表示为提交信息。（这里还会有其他信息）
第四段：如果第三段是回退信息，那么对应的第四段就是该版本的日志详细commitid；如果第三段是提交信息，第四段则是该提交信息的说明；（这里也还会有其他信息）
这里有一个需要注意的地方，就是如果只是纯粹的连续版本回退前进穿梭不会影响git log日志内容，每次穿梭后的git log日志内容都是一致的。
3.5通过git reset hard HEAD到上一个版本或者上上个版本
git reset hard HEAD^ //回退到上一个版本 git reset hard HEAD^^ //回退到上上个版本
但是这里需要注意的是，通过git redet hard HEAD回退会影响git log查看日志内容，这个回退会覆盖回退的版本日志。而在git reflog中查看所有版本操作日志时，git redet hard HEAD回退操作会在第二段多出这样一个信息“(HEAD -> master)”表示这类回退操作。
只用一行打印查看日志的信息的指令git log --pretty=oneline：这个指令只会打印出commitid、操作类型、操作说明。相当于git log的精简版，不会打印用户信息和操作时间。
四、时光穿梭机（工作区与暂存区）
3.1通过git checkout -- fileName 将修改的文件还原到最初状态。这一般发生在从版本库中拉取代码或者回退版本后，在工作区修改了一些内容，但又想还原到文件的最初状态，可以通过下面这个git status查看修改文件后的状态信息：
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
在信息里就明确的提示了两种操作，一种是将工作区修改的文件通过add、commit指令提交，还有一种就是checkout放弃更改。
3.2通过git reset HEAD fileName 撤销添加到暂存区但未提交到提交区的文件，将暂存区还原成提交区的最新状态。
现在比如有这样一种情况：工作区修改的文件被add指令提交到了暂存区，但是这时候想回到文件最初的状态，该如何处理？这里实际上存在两个环节，将添加到暂存区的文件撤销，然后还需要将工作区的文件内容还原到最初状态：
git reset HEAD fileName //fileName为要撤销的文件名称，需要后缀 git checkout -- fileName //同上
但是，这里还有必要看一下文件添加到暂存区的状态，毕竟仓库状态时操作仓库最重要的知道信息：
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt
五、Git分支开启多人协作
在进入正式的操作之前，有必要来了解一下Git分支的工作原理，在面的所有操作就是在git版本库的主分支上进行的，我们可以在这个分支上来回进行版本切换，这里就可以思考一个问题，在进行版本切换的时候git真正干了什么？实际上git只做了一个很简单的事情，就是将一个版本标记切换到指定的位置，这个可以理解为指针指向你要去到的版本代码位置，然后将这个版本以及之前的所有内容读取出来。画个图来理解一下：
看到上面的版本提交图，在最新提交版本上使用了一个master标识，在这个标识上方还有一个HEAD标识，这个HEAD标识可以简单的称它为“头指针”。
而这里的master所表示的是当前分支是主分支。这个主分支是每个版本库创建以后自动默认的一个分支，既然有了主分支那必然就有其他分支，而其他分支是需要手动创建的。
5.1创建分支：git checkout -b branchName，这里branchName表示分子的名称。创建完成以后并且还会打印出一个信息：
git checkout -b dev_xiaoming //创建分支xiaoming Switched to a new branch 'dev_xiaoming' //创建完成以后的提示：切换到一个新的分支xiaomign
也就是说创建完成一个分支以后它就自动切换到了刚刚创建的分支上，也就是说如果要回到主分支上就需要手动切换分支。
5.2查看分支与切换分支：
git branch //查看分支,打印出来的分支名称列表前面被一个“星号”标记的就是当前分支 git checkout master //切换到主分支，如果需要切换到其他分支就将master替换成其他分支名称即可，切换完成以后同样会提示"切换到了主分支"Switched to branch 'master'
5.3分支详解：分支提交、分支合并、解决提交冲突
每个分支都有自己独立版本更新记录，而合并分支则是在主分支上，将各个分支的最新版本合并起来，这样的解释感觉可能还是一头雾水，下面还是用示图的方式来解析一下：
合并分支指令git merge branchName（branchName表示分支名称）：
合并分支一次只能通过git merge 指令合并一个，所以多个分支需要合并多次。如果只是一个分支没有什么问题，但是如果是多个分支就会出现合并冲突。这种冲突都发生在合并第二个分支及后面的其他分支，这是为什么呢？
合并冲突的底层原理与解决方案：
合并冲突是因为一开始各个分支重主分支上拉取代码，然后合并时其实就是检测当前要合并的分支内容，是否除该分支修改的部分以外是否与当前分支的内容一致。所以第一个合并的分支合并就直接可以将修改的内容正常的合并到主分支上，但是再接着合并时，检测的内容就会与多出第一个（或前面合并的分支）添加的内容，这时候就不能正常匹配除该分支修改的以外内容，如果执行合并会出现以下提示和相关状态：
Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt //冲突(内容):readme.txt中的合并冲突 Automatic merge failed; fix conflicts and then commit the result. //自动合并失败;修复冲突，然后提交结果。
但是这时候查看工作区的文件你会发现内容已经被修改了，但是使用git log查看主分支的日志并没记录，也就是说各个合并冲突的内容被放到了工作区，这时候就需要我们手动来解决冲突，然后再主分支上通过 git add 、git commit手动提交到主分支上。
手动解决冲突的话这要看代码的具体编写内容是什么，一般情况下我们都是各自负责一个功能模块，这种情况就只需要手动将git自动添加的冲突提示信息删除就可以了，如果有其他情况要更具代码的具体情况而论。
5.4删除分支
git branch -d branchName //删除分支 git branch -D branchName //强制删除分支
删除分支这两个命令的的区别就在于如果被删除的分支，有提交但未合并到主分支的文件时，就会不能被删除，如果可以忽略该分支的提交就可以强制删除分支，否则需要合并该分支才能删除。
删除分支还有一些细节需要注意：如果被删除的分支有文件添加到暂存区，但该分支被删除了的话，只能切换到被删除的分支的父级分支上，并且需要对添加到暂存区的文件做撤销或者提交操作，如果撤销的话还需要对当前工作区的文件进行还原操作。只有做完这些操作才能切换到其他分支。
还有，如果分支被删除，但是添加暂存区的文件没有被撤销或者提交，在该删除的父级分支上重新创建同名的分支可以恢复之前的分支状态（前提是该名称没有被在其他地方重新创建）。
六、Git config与配置别名、打标签、忽略文件
1.可以通过git config查看git命令列表；
2.可以通过git config -l查看git的配置文件的配置信息，这个命令查看到的信息是系统、用户、当前仓库的总和。
//git系统配置文件在git的安装目录下 git安装路径\etc\***.config //git用户配置文件在系统用户的.git下，例如window系统的git用户配置文件路径 C:\Users\**你当前的系统用户名**\.gitconfig //git当前仓库配置文件 当前仓库路径\.git\config
git配置文件与很多程序的配置文件都一样，采用就近原则，如果在当前仓库配置了某个配置信息，那这个配置信息就只作用于当前仓库，其他仓库不会被作用到。
git config --globale -l //查看全局的配置信息 git config --system -l //查看当前系统用户的配置信息 git config --local -l //查看当前仓库的配置信息
3.可以通过git config --[globale, system, local] [-e, --edit]开启一个控制台编辑器，对指定的配置文件进行编辑，[globale, system, local]表示选择指定级别的配置文件，[-e, --edit]表示开启控制台编辑器（-e是--edit的缩写）。例如：
git config --local -e //编辑当前仓库配置文件
关于git vim编辑器的操作更多内容：
如果是输出状态，首先按Esc键退出输入状态，然后按Shift+“;”，再输入q!或wq!（不保存改动，wq!是保存文件的写入修改）退出。 补充： 只要按住shift键盘，下面的这些命令都可以用： 1、如果你想编辑某个文档，可以直接编辑的如：你有文档AA，可以用vi AA 【注意：必须在AA所在的目录下】。 2、如果没有文档，而且你又想编辑就可以直接编辑vi aa【名字你可以随便命名】。 3、也可以先建立一个文档touch aa ，然后再编辑vi aa。 4、编辑器有三种模式：1、命令行模式 2、末行模式 3、输入模式。 5、按Esc 就可以进入命令行模式，也是系统默认模式。 6、输入模式可以按 o i a 都可以进入，退出可以进入末行和命令行模式。 7、末行模式可以按ctrl+；它的主要功能是退出编辑器，也可以保存退出文档。 8、q! 【强制退出不保存】，q【退出不保存】，wq【退出并保存后面也可以加个！】。 9、在输入模式和命令行模式命令很多。 10、如复制（yy）、粘贴（p)、删除（d）等等。
4.配置git指令别名：
//在全局配置文件上配置status的别名为st git config --global alias.st status
上面这个操作就是在全局配置文件上将git status指令修改了git st，这时候就可以通过git st指令查看用户状态，st就是status的别名，它拥有相同的含义。有设置别名就必然会有删除别名：
git config --global --unset alias.st //删除别名st
配置别名是需要注意组合指令需要使用引号包裹，比如下面这个别名的配置：
git config --global alias.logone "log --pretty=oneline"
5.给提交记录打标签：
//给最新的提交记录打标签 git tag tagname //tagname表示标签名 git tag tagname -m "标签说明" //还可以给标签添加说明 //给以前的提交记录打标签 git tag tagname commitid //在后面添加上指定的提交记录的commit id //删除标签 git tag -d tagname //查看标签列表 git tag
6.忽略文件，在仓库的根目录下创建一个.gitignore文件，然后在文件内编辑好指令忽略的文件：
vim .gitignore //使用vim创建一个.gitignore文件 .... //编辑需要忽略的文件，根据具体需要，github有参考可以查查 *.py[cod] *.so *.egg *.egg-info dist build //shift +; 从编辑状态切换出来 qw！//输入退出并保存的指令就Ok了
但是，这里还有一个问题需要注意，虽然可以通过.gitignore文件来告诉git忽略指定的文件，但是它自身也是一个文件，当查看状态时git也会提示文件没有被提交，所以一般.gitignore文件直接提交到提交区：
git add .gitignore git commit -m "gitignore commit"
七、GitHub远程仓库
7.1在github上创建一个仓库：
（1：开始创建远程仓库）
（2：创建远程仓库）
（3：将本地仓库推送到远程仓库）
将本地仓库推送到远程仓库的几个步骤：
git remote //查看本地仓库是否已经被推送到远程仓库,如果没有被推送就没有任何信息打印出来 git remote add origin 远程仓库的地址 //在本地仓库添加远程仓库 git push -u origin master //将本地代码推送到远程仓库上
第一次推送代码时可能会出现没有权限的情况，需要在本地生成一个ssh key安全认证：
cat ~/.ssh/id_rsa.pub //查看本地是否已经存在ssh key本地公钥 ssh-keygen -t rsa -C "邮箱地址" //在本地生成一个ssh key本地公钥
然后把在：系统盘\用户\用户账号\.ssh\id_rsa.pub里面的内容全部复制出来，在github上的settings里面找到add keys，将其粘贴到key即可，title随便填：
然后将id_rsa.pub文件内容粘贴到key中，确认按钮就可以了。
现在就可以开始推送代码了，但是第一次认证后推送代码还会有一个在本地有一个认证流程：
这里输入yes然后回车就可以开始推送代码了。
如果在其他分支上有修改，再推送主分支之前必须要进行合并再推送。
除了推送主分支以外，当然也可以推送其他分支，比如：
git push -u origin master //这个时推送主分支 git push -u origin 其他分支名称 //将你要推送的分支名称替换掉主分支名称master
7.2从github远程仓库拉取代码：
在拉取代码之前需要注意一点，如果跟换了机器，在该机器上生成ssh key安全认证，并将密钥绑定到远程仓库，操作方式与上面一样。然后在使用git clone +远程仓库地址就可以将整个远程仓库克隆到本地了：
git clone git@github.com:michaelliao/bootstrap.git
最后还有一个需要注意的地方就是，在远程仓库中只有你之前已经推送的分支，没有推送的分支在远程仓库中是没有的，也就是说没有推送的分支不能被拉取下来，因为远程仓库根本就没有。
标签：文件,git,提交,仓库,版本,使用,安装,分支 来源： https://www.cnblogs.com/ZheOneAndOnly/p/10930933.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。