git配置

1. 全局配置自己的名称及邮箱

git config --global user.name "Your Name"       #全局配置名称

git config --global user.email "email@example.com"    #全局配置邮箱

2. 配置ssh生成秘钥

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

3. 查看公钥

cat /.ssh/id_rsa.pub

gitlab配置

setting --> SSH Keys --> 粘贴公钥信息

使用

• 创建版本库
  1. 新建文件夹 mkdir test #项目名
  2. 进入文件夹cd test 初始化 git init
  3. gitlab创建项目 获取项目地址
  4. 添加远程仓库地址 git add origin git@gitlab.jdhoe.com/xxxx 这里可以添加多个远程地址 origin这个是别名 远程地址的别名
  5. 这样项目就算是初始化完成了
  6. 创建文件touch README.md
  7. 添加到文件暂存区 git add README.md
  8. 创建版本提交到仓库 git commit -m "add README.md "
  9. 拉去远程仓库信息 git pull origin master 养成一个好习惯 (解释一下什么都是干什么用的 origin 是远程别名 指向的地址 master 是分支 创建git默认分支就是master也成为主分支)
  10. 提交到远程 git push origin master 推送到远程仓库
• 工作区和暂存区的一个概念
  1. 工作区顾名思义就是我们要写代码工作的目录 也是整个项目需要做版本控制的地方 例如:

  echo '# git示例 ' >> README.md #向这个文件里面写了一行文字为'git 示例' 并没有做任何操作这也是我们开发中经常做的操作输入我们要写的代码此时我们只是在我们的工作区内
  

  2. 暂存区 在git版本控制的概念里面只有修改这一个改变其他都没有 也就是说我们其他的操作用git 的命令都是修改 例如:

git add REMADE.md #这里只是在git暂存区里面添加了这个修改的操作并没有把这个文件直接提交  有人会问为什么要多这一步操作 不能直接提交  这就是git 牛逼的地方我现在继续解释(装逼)

• 场景一

今天上午功能谢了一半, 还不能完整的构成一次提交, 我先把这个代码放到暂存区里面 git add . 提交到暂存区里面下继续写. 回来发现自己写突然发现自己电脑关机了,打开电脑发现自己之前写的代码也乱了根本不知道改了哪些东西 这个时候我们不是发火的时候而是直接把代码还原到我们吃饭之前哪里去 git checkout -- . #这里的.指的是所以有工作区内容保存并且继续写然后把代码添加到缓冲区里面 这样一方面避免了commit提交的无用的版本 还能达到我们的需求.

• 场景二

这个可能是使用git中常见的场景了现在还没讲到忽略文件怎么使用. 就拿他来举例 我们开发中过程中由于要运行代码会生成大量的执行文件这些文件对于我们来说并不能提交到代码里面去 我们经常是比较懒得总是使用git add .这样的方式来把代码放到暂存区里面相信大家都深有体会. 有些不小心已经添加进去这个时候我们要把这些文件从新放回到工作区里面 git reset HEAD /../../xxx.o只能这样一个一个的放入到工作区里面.然后在提交版本这样才能避免这样的问题.

• 忽略文件
  > 刚刚我们已经受够了那样每次添加到暂存区里面都要小心翼翼的一个文件一个文件的添加 这完全不能符合我们的工作效率那在Git里面我们是如何忽略文件的呢? 首先我们创建忽略文件. 回到项目的根目录里面创建忽略文件

touch .gitignore #创建忽略文件

我们来看一个完成的忽略文件来分析

# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore

## Build generated
build/ #忽略当前问价下的所有文件
DerivedData/
*.xcuserstate # 忽略所有已.xcuserstate结尾的文件
## Various settings
*.pbxuser
!default.pbxuser #不需要忽略的文件 但是包含在了.pbxuser忽略的内容 !是取反的意思
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/

## Other
*.moved-aside
*.xccheckout
*.xcscmblueprint
Podfile.lock
.DS_Store
../C_JDHOE.xcworkspace/xcuserdata/


## Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
Pods/

# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts

Carthage/Build

# fastlane
#
# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the
# screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://docs.fastlane.tools/best-practices/source-control/#source-control

fastlane/report.xml #忽略指定路径的文件
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output

# Code Injection
#
# After new code Injection tools there's a generated folder /iOSInjectionProject
# https://github.com/johnno1962/injectionforxcode

iOSInjectionProject/

• 版本回退

版本回退可能是我们会经常用到的一个工作场景了.下面依旧是一举例的方式来说明怎么使用版本回退

• 场景一

项目经理安排小明写的积分管理模块, 小明今天状态不错,愉快的写着代码很是开心的写完了.自测没有什么大问题了高兴的提交了代码. git commit -a "feat 积分管理模块" 正在打算把代码推送的时候测试跑过来给我说你上个版本的代码有个bug 吓得小明赶紧去检查下代码是不是出了什么问题.虽然想这肯定不是我的锅. 但是模块还是自己写的还是看看是什么影响了. 此时代码已经提交了修改了那些文件好像也不太记得了.怎么办呢? 想着先在当前版本排查一下按照测试大佬说的场景走了一遍并没有发现问题.难道在写代码的时候顺手改了么改了哪里好像并不知道. 还是回到上个版本看下到底是哪里影响了. 这个时候看下自己提交的日志;

git log  #发现输出了一堆的信息, 看的头都晕了.

git log --pretty=oneline  #这样发现就好看多了  这个参数是把所有的提交一行显示

>7808698047ce03bd4e789f6614bac793477a433b (HEAD -> dev, origin/dev) feat 积分管理模块  前面是hash值 这里也解释一下为什么需要用到hash值 如果使用自增版本号的话因为是分布式的那这样的话会导致版本号冲突不能愉快的使用了hash那就不一样了 每个都不会一样加入一些特殊数的算法相当于唯一id 就不容易重复了  这里我们在写代码的时候也可以借鉴一下.又学到了新东西(又学会了装逼的技能)
c01a7f7ffe849edd35db3732fbb041968230e30c fix 修复文件上传
962ee50695114b1a5f4843efa064ff4d27d97163 test 添加单元测试 

#现在我们回到上个版本

git reset --hard c01a7f7ffe84   #可以不需要写出所有当然我们都是复制粘贴 这到无所谓了  这样就回到了上个版本

小明继续排查这BUG 发现这个BUG确实在没有修改但是会在特定场景下回隐藏这个问题 这也是为什么自己新写的版本没有出现这个问题. 可能在以后还是会发现这样的问题. 小明已经修改BUG的思路了准备下手写代码了. 等等好像有点不太对.这个时候如果要是写了代码提交了那之前新写的功能岂不是白干了. 想想就一阵后怕. 但是现在要怎么回到之前的版本呢? 还好之前的输出日志没有关

git rest --hard 7808698047ce03bd4e789f6614bac793477a433b 


git log #看了下果然回来了 自己的小心脏可以放到心里了. 开心继续愉快的改完bug 看了下还有两个小时要下班了.想想今天都是发生了什么事.

git里面的版本控制到底是怎么来管理的呢.实际上是指针的一个说法.每一个版本都有记录一个节点. 我们只需要把HEAD这个指针指向我们的工作地方就可以了这个可能是写C 的大佬深刻的理解C语言指针的精华打造出来这么好用的版本控制的工具.
注意 : 如果我们已经看不到原来的记录了但是我们还是想回到未来的版本此时要怎么办.身为程序员的我们总是可以办到.没有办不到是事情这个我是我们的创造的源泉.git reflog 这个我们可以看到我们所有的操作日志

分支

这里只讲怎么创建分支合并分支的,以及删除分支的操作,具体的使用我们来分析git flow 工作流模型来讲解怎么在实际开发中使用分支和标签

1. 创建分支

git branch develop  #创建一份分支
git branch #查看分支

2. 切换分支

git checkout develop   #切换到 develop 分支

#简写
git checkout -b develop  # 创建分支并切换到 develop 分支

3. 合并分支分支

#切换到主分支
git checkout master

git merge --no-ff develop  # --no--ff 这里是指 不使用fast-forward方式合并，保留分支的commit历史  也就是说分支上的commit 信息在主分支上就不要了  不需要这些信息 来看到大量的无用提交信息  这里后面会讲为什么不需要这些信息!

4. 删除分支

 git branch -d develop #删除分支 之前都说过git所有的工作都是有指针完成的 我们的每一次操作其实都是有记录的  即使是删除了也是可以恢复的 只需要知道分支的hash值就可以重新创建这个分支 .还记得我们之前说的命名 `git reflog` 这个命令么?

标签

标签在我们日常工作中也是使用的非常多的一个了, 在项目管理中是一个里程碑的一样的东西存在着. 每当我们需要上线的时候我们要记录下我们上线的版本是什么 当前的版本号 都可以以标签的形式来表现

1. 创建标签并查看 

#创建标签其实就是在某一次的提交上来追加一个标签的描述   我们及时有的时候忘记打标签了也不怕 因为我们还可以根据我们的提交记录来打标签;

git tag -a v1.0 -m "1.0 版本发布"  cba749e35da46c7   # -a 是添加 -m 描述 后面的hash 值指的是在哪个一个提交版本来打标签

git show v1.0  #来查看当前tag 的信息是什么

2. 删除标签

git tag -d v1.0  #这样就删除了  基本的操作这些懂了就差不多了. 当然实际开发中还是会碰到很多问题.  

总结

这里我并没有说解决冲突的方法,我希望大家自己去摸索怎么使用和学习一个工具. 这里只是来告诉一下大家怎么样来学习! 解决冲突的话我还是会推荐几个工具供大家来使用! beyond compare 这个对比工具 kdiff功能很强大