标签：主机 忽略 remote res 模式 omv linux git push 自动生成
目录
首发日期：2018-09-23
题外话：什么是版本控制系统？--以版本控制系统的功能开始
在你日常生活中，如果你对某个项目进行不断的版本增强的时候，你可能会得出多个版本（例如初定版，1.1版，3.0版，最终版），而由于你是不能百分百确定最新版本是否是符合开发思路的（可能走某条路反而让版本增加了更多bug，于是要从头开始），所以你会需要每个版本的记录文件，确保存有原来的版本来进行重新开发，你可能会对每个版本进行拷贝一份，这样就可以确保自己存有发生错误之前的版本了。但“拷贝”法有很严重的问题，一是单纯的拷贝会浪费较多空间、二是每个拷贝你都需要提供一个文件来描述这个拷贝是哪个版本的。而版本控制系统就可以很大程度地解决上面两个问题。
1.版本控制系统可以帮助开发者协同工作，节省项目管理时间：以Linux的版本控制为例，众所周知，Linux是开源的，所以它有很多“免费的员工”，如果没有一个版本控制系统的话，一个普通公司的多个程序员提交的代码主管要“手动拷贝+手动合并+手动清理优化”才能得到最终的代码，而使用一些市面上的版本控制软件如SVN，主管就可以定义一个“房间”，程序员给“这个房子装修的东西”，主管可以在版本控制软件上进行代码对比查看合并，这样就节省了项目管理的时间。
2.版本控制系统可以帮助开发者记录项目的开发记录、回退版本和版本对比：以给软件增加新功能为例，开发新功能，首先要保证旧系统运行，在没有版本控制系统的情况下，我们一般都要对原始代码进行拷贝，避免在原始代码的基础上修改导致出错时无法恢复到功能上线前（假设不是修复新功能而是先下线再修复）。而使用版本控制系统后，开发者可以将原始代码记录提交到版本控制系统上，然后每一次开发都提交一次记录到版本控制系统上，版本控制系统会将提交的所有的开发记录保存，这使得我们可以方便的“回退”到某一版本。而版本控制系统一般还提供版本对比功能，可以查看某版本与另一个版本的代码在哪里有区别。（有人说可以拷贝，但长期开发时，拷贝消耗的时间很多，而提交只需要几条命令。并且不同的版本控制系统采用不同的记录方法，所以会比拷贝要节省资源，同时拷贝不可以对比文件的细致内容。）
所以，总的来说，版本控制系统有以下几个好处：
- 辅助多人协同开发
- 提交项目管理效率，提高开发效率
- 跟踪记录项目中版本变化，可以查看不同版本之间的细致区别
- 帮助管理源代码，轻松回退历史版本
- 跟踪记录整个软件的开发过程
- 权限控制：管理开发者提交、修改的权限，
题外话：集中式与分布式版本控制系统的区别？
git与集中式版本控制系统（如svn等）不同，集中式版本控制系统由主服务器存储更新记录，git可以在多台主机中保存更新记录。
集中式的版本控制系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，开发者通过客户端连到这台服务器，取出最新的文件或者提交更新。 完成工作后，开发者都必须提交到这台服务器。由于服务器的限制，集中式版本控制系统最大的毛病就是必须联网才能工作。
分布式控制系统，每一个客户机都相当于一台服务器，每台主机都是一个版本库，当需要协作开发时，客户端并不只是从某台主机中提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。而开发者完成工作后，开发者可以将修改推送给别人，别人就可以看到开发者的修改。
要把代码提交到本地服务器，那么就要认识下面几个区域。考虑到对项目更新的追踪情况，git将项目的所处区域分为以下几种。
git status查看出来。
git add来让它被git追踪。git add后就会变成staged状态。git commit后，数据已经提交并保存在本地仓库中，就会变成已提交状态。【这个状态也是未修改状态，刚提交的文件就是说明是未修改的】git add或git commit来将修改后的文件提交到本地库。由于git是分布式的，所以它可以在本地中创建版本仓库，但在多人协作开发的时候，由于处在不同的主机，所以需要某个主机作为“远程库”来管理核心的版本信息。远程库与本地库性质相同，不同它由于处在远端区域，所以称为远程库，远程库用于管理多人协作时的版本更新，开发者可以克隆远程库到本地中作为本地库，然后提交修改后的信息到远程库。
这里以windows安装为例，如果想了解其他系统的安装方式，可以自查。
1.下载安装
官网：https://git-scm.com/
2.开始安装
之后就是纯粹的安装了。
先提一下命令的输入位置，然后下面再介绍有什么命令。在windows下，右键可以看到（如果你安装过程勾选了的话）
，第一个就是在本目录中以可视化方式打开git，第二个是以命令行方式打开git。下面介绍的使用将只介绍命令行方式。学会了命令行方式你就很容易去学会在可视化窗口下操作git。
命令行窗口是这样子的：
稍微提一下，git是linux之父创造的,git也支持很多Linux命令。所以你可以使用linux命令的方式来显示下一页、显示下一行等操作【这些命令由于是Linux的内容，这里不会讲】
git用于版本控制更新，要使用它，必须要有一个用于记录版本信息的仓库。
git的版本控制命令要在仓库中才能使用，所以要在需要进行版本控制的项目目录进行初始化仓库（也就是追踪一个项目的也必须要在这个项目文件夹进行初始化仓库。）。这样就可以对项目的文件进行管理了。
git initgit init 目录名《git官方文档》：初始化后，在当前目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。不过目前，仅仅是按照既有的结构框架初始化好了里边所有的文件和目录，但我们还没有开始跟踪管理项目中的任何一个文件。
git的其他命令使用需要先设置用户签名，这是为了区分不同开发人员的身份。如果没有任何能够标识提交者的东西的话，就没办法知道这份工作是谁做的了，这是不允许的。
用户签名包含用户名和邮箱，仅用于本地库中区分开发者（这不是远程库的账户密码）。远程库需要的别的用户名和密码，这会在后面github协作中再讲。【用户签名中用户名和邮箱仅仅涉及用户标识，所以它不必是真实的，邮箱和用户名是可以随机的】
用户签名是必须的，不允许匿名用户提交版本操作。
用户签名也是有作用范围的，采用两种不同的设置方式。
语法：
//仓库级别
git config user.name 用户名
git config user.email 邮箱
//全局级别
git config --global user.name 用户名
git config --global user.email 邮箱示例：
$ git config user.name neo
$ git config user.email xxx@163.com
$ git config --global user.name tom
$ git config --global user.email tom@163.com仓库级别的用户签名信息保存在仓库目录下.git/config文件中；全局级别的用户签名信息保存在系统用户目录下的.gitconfig 文件中【使用cd ~可以快速切换到当前用户目录】
查看这些配置信息可以使用git config --list来查看
git statusgit add 文件名git add .*，例如git add *.java代表提交所有以.java为后缀的文件名。
git commit 文件名【执行这个命令后会以vim方式打开一个文件，需要在这个文件的非#起头的行中输入版本更新描述】git commit -m "版本更新描述" 文件名【由于版本更新描述都会比较简洁明了，通常使用这个方式】git commit -a -m "版本更新描述"git commit -a?-m?"版本更新描述"。
git commitgit mv file_from file_togit commit
每一次git commit都相当于提交一次版本更新操作，这会留下一个版本记录。
版本记录会使用哈希值来唯一标识每一个版本。
查看版本记录可以帮助我们了解版本更新情况，以及可以帮助我们进行版本回退等操作。
命令：
查看所有版本更新记录：git log 【注意翻页(space)、下一行（enter）这些操作与linux的相同，q为退出】
默认不用任何参数的话，
git log会按提交时间列出所有的更新，最近的更新排在最上面。
显示每次提交的内容差异：git log -p
查看最近num次的提交：git log -num
单行显示版本更新记录(只包含哈希值和版本描述信息)：git log --pretty=oneline或git log --oneline
以格式化的方式显示版本更新记录：git log --pretty=format:"%h - %an, %ar : %s"
| 选项 | 说明 |
|---|---|
%H |
提交对象（commit）的完整哈希字串 |
%h |
提交对象的简短哈希字串 |
%T |
树对象（tree）的完整哈希字串 |
%t |
树对象的简短哈希字串 |
%P |
父对象（parent）的完整哈希字串 |
%p |
父对象的简短哈希字串 |
%an |
作者（author）的名字 |
%ae |
作者的电子邮件地址 |
%ad |
作者修订日期（可以用 -date= 选项定制格式） |
%ar |
作者修订日期，按多久以前的方式显示 |
%cn |
提交者(committer)的名字 |
%ce |
提交者的电子邮件地址 |
%cd |
提交日期 |
%cr |
提交日期，按多久以前的方式显示 |
%s |
提交说明 |
显示版本更新中分支变化情况（用于查看分支合并情况）：git log --graph
完整显示版本更新记录：git reflog【git永远只会增加版本，不会因为版本回退而删除某个版本（完整地记录版本更新情况，连回退操作也当成一个版本更新操作），版本回退之后，git log是看不到比回退版本更高的版本的，而git reflog可以看到完整的版本更新情况】
当发生某个重大bug时，我们可能希望回到某个版本重新开始，那么可以使用版本回退。【前进就是回退之后又突然想去新版本看看】
git reset --hard 哈希值 【哈希值可以使用头七位】git reset --hard HEAD^【一个^表示回退一步,n个表示回退 n 步】git reset --hard HEAD~n【表示后退n步】git reflog命令，因为需要借助这个命令来查看哈希值。git reflog中记录了所有的版本更新情况，即使是回退，它也会进行记录，不会因为回退而删除某些版本更新纪录。有了哈希值之后，就可以利用git reset --hard 哈希值来前进了有时候可能需要查看文件修改情况，可以使用文件对比来查看修改情况。
git diffgit diff 文件git diff --cachedgit diff 哈希值 文件名
什么是分支？
当多人协作开发一个项目时，可能多人开发的并不是同一种功能（例如战斗功能、交易功能），一般来说都会分别开发功能，最后再进行整合。
而这些功能可能都会基于某个前置功能，某些额外功能的开发都需要前置功能的代码，对于不使用版本控制的开发来说，可能会使用拷贝基础的代码，再进行开发。
而使用了git之后，你应该知道你可以直接使用命令来获取某个版本的代码文件的。这就省去了繁杂的拷贝了。
但git提供的分支（默认我们开发的分支是master分支）可以形象地显示分功能开发问题，而分支合并可以处理整合问题。
"分支就是不同流向的分支历史"
git branch 分支名git branch -v或git branchgit checkout 分支名git checkout -b 分支名git merge 分支名【在某个分支执行这个命令，就是把当前分支与目标分支合并】git branch -d 分支名
切换分支也会更改工作区的文件。
上面提到了分支合并，但有时候合并会发生冲突的。例如，某个开发者基于master分支的某个版本创建了issue分支来进行了开发，（要注意的是这时候issue分支基于某一份共同的代码），但创建了issue分支之后，master分支上继续进行了版本更新，于是原本issue基于的代码发生了变化。开发完了之后，要进行分支合并，git会检查文件是否相同，它就会发现两份代码有了不一样的地方，于是就有了冲突。【就好比A从B的冰箱拿了四个苹果，B自己偷偷拿了1个苹果，后来A要还给B苹果的时候，B说原本有五个苹果，但A说只拿了四个，这就是一种冲突】
可以合并的文件会进行合并，当无法合并后，git会在目标文件中进行标注：
手动选择保留哪些内容:
使用git add来告诉git冲突解决。然后使用git commit进行提交即可。
1.创建新仓库：
2.填写仓库描述：
git remote add [远程库简写名] [url]【远程库简写名是用于简便使用远程库的，可以随意】
要查看当前配置有哪些远程仓库，可以用 git remote 命令，它会列出每个远程库的简写名字及url。
git remote -v ：显示对应的克隆地址git remote show [远程库简写名]：查看远程仓库信息克隆远程库，就是从远程库拉取完整的版本更新记录和项目数据下来，会在本地创建一个远程仓库名的文件夹。
git clone [url]git clone url 文件夹名称来更改仓库的名称。
克隆远程库是完整地拷贝一个仓库。如果你之前已经有过这个仓库了，你可以直接拉取分支，拉取某个分支需要的流量会比克隆远程库要少得多。在拉取的时候也会获取到版本更新记录
git pull 远程库简写名 分支名：拉取某个分支的代码到本地，要求本地已经初始化了仓库,会与本地的分支进行合并。【由于会合并，所以要考虑本地库和远程库版本差距太大的时候的情况。】git fetch 远程库简写名 分支名 ：拉取某个分支的代码到本地，要求本地已经初始化了仓库,但注意pull会尝试合并分支，而fetch不会尝试合并分支。git push 远程库简写 分支名：把本地仓库的代码提交到远程库的指定分支上。git taggit tag 标签名git tag -a 标签名 版本哈希值
git show 标签名git push 远程库简写名 标签名git push 远程库简写名 --tags
一个项目在开发的过程中，可能会需要运行测试，所以可能会把一些运行日志文件留在项目目录中，而这些日志文件对于版本更新是没有作用的，所以不应该把他提交到远程库中。要知道每一份空间都是珍贵的。
而除了日志文件，可能还有其他一些文件，这些文件可能是比较有用的，所以我们不能去“净化工作区”----删除它们。通常我们都会定义一个.gitignore文件，这个文件通常用于过滤上传到远程库的项目文件，在里面定义的文件不会被提交到仓库中。
.gitignore文件要位于仓库的根目录
文件 .gitignore 的格式规范如下：
＃ 开头的行都会被 Git 忽略。/）说明要忽略的是目录。!）取反。所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号（
*）匹配零个或多个任意字符；[abc]匹配任何一个列在方括号中的字符（这个例子要么匹配一个 a，要么匹配一个 b，要么匹配一个 c）；问号（?）只匹配一个任意字符；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配（比如[0-9]表示匹配所有 0 到 9 的数字）。
通常来说，网上都会有大量的针对不同项目的gitignore文件。普通使用的时候去网上抄一份就行，如果有特殊文件，那么就要自己手写了。
下面以在github中创建仓库时选择自动生成的针对java项目的.gitignore文件为例：
# Compiled class file 过滤.class文件
*.class
# Log file 过滤日志文件
*.log
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package Files # 过滤jar包，war包
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar
# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
基本来说，上面这些命令足够日常使用了。
希望这篇博文能帮助到你
标签：主机 忽略 remote res 模式 omv linux git push 自动生成
原文地址：https://www.cnblogs.com/progor/p/9693797.html
