最近换了一家新公司,之前公司都是使用SVN来做版本管理的,一直都觉得挺好的,没什么问题,直到深入接触了Git,才发现Git是如此的方便和易用。这里呢记录一下,iOS开发者日常使用Git的一些知识。
Git常用命令
Git的命令有很多,但我们操作正确的话,只需要来来回回用那么几个命令,我是比较喜欢在终端中直接写命令的,其他同事呢喜欢用可视化工具,但我觉得,直接使用命令有助于我们理解Git的运作方式。
克隆代码到本地
git clone git@example.com:namespace/projectname.git
修改代码后提交到服务器
git add .
git commit -m "修改的文字说明"
git pull
git push
如果在执行git pull
时候有冲突呢,需要优先解决冲突,有冲突也不用怕,git会吧对应的冲突文件告诉你,你只需要打开对应的文件,然后解决冲突就可以了,在终端里面打开文件的命令是open 文件路径
,修改后重新提交就好了。
多人协作的工作模式通常是这样:
- 首先,可以试图用
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 status
查看日志
git log
// 只查看版本号和提交日志
git log --pretty=online
回退到上一个版本,如果要回退到指定版本,只需要将HEAD换成对应的版本号即可
git reset --hard HEAD^
把readme.rtf文件在工作区的修改全部撤销,其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
git checkout -- readme.rtf
删除文件
git rm test.rtf
第一次推送
git push -u origin master
之后的推送
git push origin master
本地git和远程建立连接
git branch --set-upstream-to=origin/master master
GitHub运用
分支管理
创建分支
git checkout -b dev
git checkout 命令加上-b参数表示创建并切换,相当于以下两条命令:
git branch dev
git checkout dev
查看分支
git branch
切换分支到master
git checkout master
合并分支到master
git merge dev
删除分支
git branch -d dev
通常,在合并分支的时候,Git会用 Fast forward 模式,但在这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用 Fast forward 模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
git merge --no-ff -m "merge with no-ff" dev
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master 分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那么在那干活呢?干活都在dev分支上,也就是说,dev分支是不稳定,到某个时候,比如1.0版本发布的时候,再把dev合并到master分支上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时的往dev分支上合并就可以了。
就像这样:
bug分支
每一个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。但是如果dev上的工作未完成还没有提交,现在要必须修复bug怎么办?</br>
Git提供了一个status功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作
git stash
在新建分支后,解决完bug,并且将bug分支删除,此时回到之前的工作分支,发现工作区是干净的,那之前保存的工作现场去哪了呢?使用 git stash list 命令可以查看到
git stash list
恢复有两个办法:
一是用 git stash apply 恢复,但是恢复后,stash内容并不删除,你需要用 git stash drop 来删除;
二是用 git stash pop,恢复的同时把stash内容也删除了;
git stash pop
如果要恢复指定的stash,可以先用 git stash list 命令查看,然后用命令恢复
git stash apply stash@{0}
feature分支
如果新建一个分支,但是并没有合并,现在需要删除,命令
git branch -D <name>
碰到的问题
- 在忽略文件中修改了,这个时候想要生效,需要清理缓存
git rm -r --cached .
git add .
git commit -m 'update .gitignore'
- 如何去解决fatal: refusing to merge unrelated histories
因为他们是两个不同的项目,要把两个不同的项目合并,git需要添加一句代码,再git pull,
git pull origin master --allow-unrelated-histories
iOS的Gitignore
当我们在使用git作为版本管理的时候,需要在gitignore文件中添加需要的忽略文件,通常情况下自动生成的文件并不能满足我们的要求,而有的时候又需要我们根据不同的项目来定制,也可能会在项目进行到一半的时候修改忽略文件,这里根据实际开发统一一下规范。
注意:如果ignore文件已经在版本管理中,这个时候在修改ignore文件的时候通常不会生效,我们需要先清理缓存,然后重新添加提交,清理缓存的命令是
git rm -rf --cached .
Objective-C
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
## macOS
.DS_Store
.AppleDouble
.LSOverride
## Build generated
build/
DerivedData/
## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/
## Other
*.moved-aside
*.xccheckout
*.xcscmblueprint
## Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM
## CocoaPods
Pods/
Podfile.lock
!Podfile
Swift
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
## macOS
.DS_Store
.AppleDouble
.LSOverride
## Build generated
build/
DerivedData/
## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/
## Other
*.moved-aside
*.xccheckout
*.xcscmblueprint
## Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM
## Playgrounds
timeline.xctimeline
playground.xcworkspace
# Swift Package Manager
#
# Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
Packages/
Package.pins
Package.resolved
.build/
# 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/
Podfile.lock
!Podfile
#
# Add this line if you want to avoid checking in source code from the Xcode workspace
*.xcworkspace
# 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/**/*.png
fastlane/test_output
# Code Injection
#
# After new code Injection tools there's a generated folder /iOSInjectionProject
# https://github.com/johnno1962/injectionforxcode
iOSInjectionProject/