-
Notifications
You must be signed in to change notification settings - Fork 45
git basic practice
- SSH vs Http(s)
- git config
gitlab/github中的git config#user.name#user.email只用来提交的日志信息,和权限没有一毛钱关系 即使不配置,你有权限,也可以push等,只不过用的是自动的PC的user 肯定是建议配置,可配置global也可根据项目配置
- gitlab权限验证原理
对于gitlab的权限管理,最终是根据账号做权限管理的,在authorized_keys除了公钥还有对应的user(可以在gitlab#user#setttings#配置这个公钥),进而根据user去做权限验证 github只要ssh验证成功即有权限 Gitosis/Gitolite
- 本地仓库初始化并关联远端仓库
- 编辑.gitignore 忽略如.project/.classpath等
> git init
Initialized empty Git repository in /git-sample/.git/
> git remote -v
> git remote add origin git@gitlab.xxx-inc.com:zz/yyy.git
> git remote -v
origin git@gitlab.xxx-inc.com:zz/yyy.git (fetch)
origin git@gitlab.xxx-inc.com:zz/yyy.git (push)
- 直接clone仓库到本地 然后本地新建工程 即自动执行了local和remote的关联
- 跟踪文件
- git add
- git status
- git diff/git diff --staged
- git reset HEAD
- git checkout --
- 提交到本地仓库
- git commit -m
- git log
- gitk
git新版本 mac#brew cask install tcl
- 远程仓库
- git remote -v
- fork出来一个仓库 需要添加源仓库为上游
git remote add mavs git@gitlab.xxx-inc.com:yyy/zzz.git git fetch mavs Remote Tracking
origin/master mavs/master
- git fetch [remote-name]
从远程仓库抓取数据 fetch 命令只是将远端的数据拉到本地仓库,并不自动合并到当前工作分支 git merge mavs/master
- 默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支(假设远程仓库确实有 master 分支)
- git pull
- git push [remote-name] <local_branch>:<remote_branch>
推送之前 如果远程已有更新 则需要先fetch/merge 再推送
- 用git push origin branch-name推送自己的修改
- 推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并
There is no tracking information for the current branch git branch --set-upstream-to=origin/branch-name git branch -u origin/branch
本地分支与远程分支关联
git push -u origin dev 推送的时候用-u参数关联
- 如果合并有冲突,则解决冲突,并在本地提交
- 没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功
- git branch
-r 远程分支
- git branch -vv
可查看upstream分支
- git branch newBranch
git checkout branch 切换分支 git checkout -b branch 切换并创建分支
- 典型情景
git checkout -b hotfix 新建并切换到hotfix分支 可指定远程分支 vim git commit -m "hotfix" git checkout master 切回master分支 git merge hotfix 将hotfix的修改合并到master git branch -d hotfix 完成使命删除分支
- git push origin :hotfix 删除远端分支
- Fast-Forward
快进,指针直接向右移动
- 三路合并
-
有三个分支
-
master和hotfix合并 快进
-
另外一个分支iss53做了一些修改 此时无法Fast-Forward
git checkout master git merge iss53
- Git 会用两个分支的末端(C4 和 C5)以及它们的共同祖先(C2)进行一次简单的三路合并计算
-
对三方合并后的结果重新做一个新的快照,并自动创建一个指向它的提交对象(C6)
-
- 解决冲突
merge提示Conflict git status 查看冲突 Git 会在有冲突的文件里加入标准的冲突解决标记
<<<<<<< HEAD
......
=======
......
>>>>>>> iss53
git tag 查看当前tag
-n
git tag -a v20171201 -m "20171201 for version audit" git show v20171201 git push origin v20171201
git checkout -b branch_name tag_name
detached HEAD 快照 无法修改
需要从tag创建一个分支
- 切换分支、合并分支时通常需要我们的workspace是clean的
- 情景
在master分支开发 做了一些修改 但是还未提交到本地仓库 接到一个任务需要修复一个bug 不想提交一半的工作
- 储藏栈
可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中,随时可以重新应用
-
git status 查看工作区状态 git stash 储藏当前未完结变更 git status 此时查看工作区则是clean的 git checkout bugfix 切换到另一个分支工作修复bug git checkout master 切换master分支 git stash list 查看储藏栈 git stash apply 恢复
git stash apply stash@{2} 指定恢复 git stash pop 出栈 git stash drop 删除
-a/-u
git log查看的时候会有一个'commit' Merge branch 'merge-test' 如果合并是Fast-forward策略 则查看git log的时候 没有单独的commit表示曾经合并过 执行合并时,如果设定了non fast-forward选项,即使在能够fast-forward合并的情况下也会生成新的提交并合并 merge后master均会有分支修改的commit记录(无论是否删除分支)
经验:分支合并的时候禁用fast-fowrd git merge --no-ff -m "merge" merge-test
- 情景
master分支 新网络层新代码 3.0 audit分支 旧网络层新代码 2.0 不能直接将两个分支合并 master修复了一个功能bug 需要同步到audit分支
- 测试
newbie-sample工程#master#HelloPlaycrab新增两个commit/增加两行代码 git log显示有两个最新的commit 切换到git checkout merge-test git cherry-pick 92a8a5e8 // 选择修改的第一个commit 此时可以看到merge-test中只增了一行代码 即master的第一个commit的内容
线上建议修复一个bug一个commit
- 对比三路合并
- 你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍
- 快速合并
- 优缺点
推送之前清理提交历史的手段 git pull --rebase 你的项目历史会非常整洁 而git merge则会有大量的合并提交 黄金法则-绝不要在公共的分支上使用它 从私有branch合并(merge)代码到主干branch时rebase
git fetch --all git reset --hard origin/master
Eclipse#egit
Git Gonfiguration Git Staging Team
git reflog
显示整个仓库的commit包括已经撤销的commit