赞
踩
http://gitbook.liuhui998.com/4_2.html
将文件每一次的变化都记录在系统中,以便后期查询文件的历史记录。它还允许你与程序,代码或文件上的同事进行协作。
追溯文件历史变更
多个团队协同开发
代码集中统一管理
svn:集中式的版本控制系统
git:分布式版本控制系统。
集中式的版本控制系统 只有一个中央数据仓库,如果中央数据仓库故障,所有的使用者都无法使用svn,因为每次进行版本控制工作都需要和远程服务器建立通信。
分布式版本控制系统会将远程代码仓库完整镜像下来进行本地离线版本控制,每一次的提交都不依赖远程服务,待有网络时再与远程仓库进行版本同步。
简单理解:svn需要依赖于网络,git不依赖网络
github和类似的服务(包括GitLab和BitBucket)都是托管git服务器程序来保存代码的网站。
下载 Git-2.26.0-64-bit.exe,点击安装
yum install git -y
方法一:pip install git (MAC)
方法二:先按照homebrew,
再使用brew命令安装git: brew install git
git --version
$mkdir lls
$cd lls
$git init
创建后,git就可以管理这个目录下的文件
2、本地仓库包括工作目录和版本库。本地仓库中的.git目录就是版本库。工作目录就是工作区。
git 版本库中包含暂存区(stage)、git 为我们自动创建的第一个master分支和指向master分支的指针HEAD
1、提交一个文件到暂存区
$ git add red.txt
2、提交所有文件
git add .
$ git commit -m “add cfg for elk”
$ git commit -a -m “add txt”
$ git status
git mv file1 file2
$ git rm test.txt
$ git commit -m “remove test.txt”
显示从最近到最远的提交日志/查看版本/commit 快照
$ git log
查看简介日志:
$ git log --oneline
查看分支图
$ git log --graph --oneline
查看最新一次提交的记录
git log -1
查看分支所有的操作记录,包括reset和rm操作
$git reflog
git reflog 和git log的区别:git log只能看commit操作,git reflog 可以看包括commit rm reset的操作。
history
1、对比工作目录和暂存区的不同 git diff [file1]
2、对比暂存区和版本区的不同 git diff --cached [file]
3、对比工作区与版本库某个文件的不同
Git diff HEAD --CODE.TXT
2.对比版本库中两个版本的不同
Git diff HEAD HEAD^
比较两个历史版本之间的差异
git diff SHA1 SHA2
1.当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时
$ git checkout – read.txt
2.当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃暂存区的修改
$ git reset HEAD tsd.txt
$ git checkout - -read.txt
3.已经提交了不合适的修改到版本库时,想要撤销本次提交,采用版本回退命令
1)HEAD 指针从当前分支的最新的版本,回退到上一个版本
$ git reset --hard HEAD^
$ git reset --hard HEAD~1
2)回退到上上一个版本
$ git reset --hard HEAD^^
$ git reset --hard HEAD~2
3)回退到某个版本:版本编号从git log 中的comment中查看,取前几位就行。或者用git reflog查看以前的操作记录
$ git reset --hard 1094a
$ git branch dev
$ git checkout dev
等同于:
$ git checkout -b dev
$ git branch
当前分支前面会标一个*号
一、合并分支有两种方式,一种是merge,另一种是rebase
二、merge和rebase的区别
假设现在基于远程分支"origin",创建一个叫"mywork"的分支。现在我们在这个分支做一些修改,然后生成两个提交C5 C6。与此同时,有些人也在"origin"分支上做了一些修改并且做了提交C3 C4。
这就意味着"origin"和"mywork"这两个分支各自"前进"了,它们之间"分叉"了。
1、merge:用"pull"命令把"origin"分支上的修改拉下来并且和“mywork”的修改合并生成C7,再和origin合并, 结果看起来就像一个新的"合并的提交"
2、rebase:把"mywork"分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁C5’ C6’(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 到最新的"origin"分支,最后把保存的这些补丁应用到"mywork"分支上。
3、用合并(merge)和用rebase所产生的历史的区别:
1.快速合并 fast forward模式
$ git merge dev
Fast forward 快速合并分支,删除分支后,会丢掉分支信息
2.recursive模式
当master分支和dev分支上都有更新,但是没有冲突的时候,将dev分支合并到master分支会提示输入提交描述信息,是因为git会自动提交一次分支内容。
3. 禁用fast forward模式
git merge --no-ff -m “禁用fast forward模式” dev
因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
4、修改bug时会临时创建一个分支,合并master时会禁用fast forward模式。
5、git merge --squash 使用场景
将dev分支或者很多零散的分支merge到一个公共release分支里。
但是有一种情况是需要你处理的,就是在你的dev的分支里有很多commit记录。而这些commit是无需在release里体现的。
在合并进release的时候我们希望在release里的commit log里只看见一次commit,而且这个commit的message不是很随意的,而是符合正规提交流程的约定格式的,比如,”develop:finished import data interface”。我们就需要借助git merge –squash命令参数来重新准备提交。
6、git merge --abort
回到解决冲突前的状态
【今天的项目工程文件产生了冲突,没办法,显示包内容。三下五除二把冲突解决了,结果发现项目的project文件还是不能打开,但是已经无法回归到解决冲突之前的状态了。怎么办,问了公司的大牛,执行git merge --abort命令回到解决冲突之前的状态。】
$ git checkout master
$ git branch -d dev
$ git branch -D dev
git status也可以告诉我们冲突的文件,解决冲突后提交分支
1、Git会停止rebase并会让你去解决 冲突;
2、在解决完冲突后,用"git-add"命令去更新这些内容的索引(index), 然后无需执行 git-commit,只要执行:$ git rebase --continue,这样git会继续应用(apply)余下的补丁。
3、在任何时候,你可以用–abort参数来终止rebase的行动,并且"mywork" 分支会回到rebase开始前的状态。
$ git rebase --abort
git tag
git tag -l
先push生成commitid后才可以打tag
git tag -a “v1.0” -m “项目描述”
git tag -a “v1.0” commitid -m “项目描述”
可以对一个commitid打多个标签
git show v1.0
git tag -d v1.0
首先,登陆GitHub,创建一个新的仓库(点击【new repository】按钮),名字叫gitskills。我们勾选Initialize this repository with a README,这样GitHub会自动为我们创建一个README.md文件。
使用远程仓库,需将电脑的ssh配置在github上
1、修改.gitconfig文件
也可以使用命令配置
git config --global user.name “用户名,和gitlib保持一致”
git config --global user.email “用户邮箱,和gitlib保持一致”
2、使用ssh-keygen -t rsa -C ‘用户邮箱’ 命令生成ssh,默认在当前用户的.ssh目录下
3、将id_rsa.pub的内容添加到github上。
4、github 添加ssh的位置在头像-- > setting ssh 里
在本地克隆远端仓库(需要有远端仓库的地址)
$ git clone git@github.com:michaelliao/gitskills.git
遇到问题:
已经配置好ssh密钥了,但是还是不可克隆代码,提示 『Unable to negotiate with 172.21.141.7 port 22: no matching host key type found. Their offer: ssh-dss』
解决方法:
在.ssh目录下增加config文件,命令如下:$ vim config
在config中需要写入如下内容:
Host git.XX.XX.com
HostKeyAlgorithms +ssh-dss
保存后重新克隆就OK了
$git remote add origin git@github.com:michaelliao/learngit.git
其中origin 是远程仓库的别名, git@github.com:michaelliao/learngit.git是远程仓库的地址
$ git remote
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
git remote set-url origin git@github.com:gsxhk-qadev/s.git
第一次推送使用-u ,Git不仅会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来。
$ git push -u origin master
本地仓库分支与远程仓库分支关联后,可直接使用
$ git push origin master
git tag -a “v1.1” -m “test”
git push origin v1.1
git remote remove origin(远程仓库别名)
一、$ git pull origin dev
或者
$ git fetch origin dev
git pull –rebase
二、git pull --rebase 使用场景
1、大家都基于develop拉出分支进行并行开发,这里的分支可能是多到数十个。然后彼此在进行自己的逻辑编写,时间可能需要几天或者几周。在这期间你可能需要时不时的需要pull下远程develop分支上的同事的提交。这是个好的习惯,这样下去就可以避免你在一个无用的代码上进行长期的开发,回头来看这些代码不是新的代码。甚至是会面临很多冲突需要解决,而这个时候你可能还需要对冲突的部分代码进行测试回归,这就很麻烦了。
2、在pull时候需要习惯性的加上—rebase参数,这样可以避免很多问题。–rebase的本意是想让事情的发展看起来很连续和优美,而不是多出很多无用的merge commit 。
3、
git fetch是将远程主机的最新内容拉到本地,用户在检查了以后决定是否合并到本机工作分支中。
git pull 则是将远程主机的最新内容拉下来后直接合并。
git pull = git fetch + git merge,这样可能会产生冲突,需要手动解决。
$ git branch --set-upstream-to=origin/dev dev
$ git branch -r
git remote update origin --prune
git remote update origin -p
1.隐藏当前分支
$ git stash
2.查看隐藏地址
$ git stash list
3.恢复分支并删除stash内容
$ git stash apply
$ git stash drop
等同于:
$ git stash pop
1、提交本地代码到当前分支
$ git checkout dev
$ git add *
$ git commit -m ‘sd’
2、拉取master最新代码
$ git checkout master
$ git pull origin master
3、本地master分支代码合并到本地dev分支,并解决冲突
$ git checkout dev
$ git meger master
4、提交dev分支代码到远程dev分支
$ git push origin dev
5、在GitHub 上 create meger request
如果只是修改小部分代码,不需要开 feature branch,比如修复某个崩溃,开发工作的流程为:
git co develop; git pull
修改代码
git commit -a -m “xxxx”
重复2和3
git pull –rebase,如果有冲突,解决冲突
git push
重复1到6
如果进行大改动,需要开 feature branch,比如业务改造,开发流程会多增加几步:
git co develop; git pull
git co -b new_feature_branch; git push -u origin new_feature_branch
修改代码
git commit -a -m “xxxx”
重复3和4
git pull –rebase,如果有冲突,解决冲突
git push
重复上面3~7步
git co develop; git merge –no-ff new_feature_branch
git branch -d new_feature_branch
重复1到10
也就是说,在 new_feature_branch 开发完成前,修改都是在 new_feature_branch 上进行 commit,最后new feature 完成后,再 merge 到 develop。
fork模式:在github页面,点击fork按钮。将别人的仓库复制一份到自己的仓库。
分支模式:将github中别人的仓库克隆到自己本地电脑中
比如:有一个叫做Joe的程序猿写了一个游戏程序,并且Joe将他的代码放在了GitHub仓库上。而你要去改进它。
1、在GitHub上复制Joe的仓库,复制后的仓库在你自己的GitHub帐号下。
2、.将fork的代码克隆到本地
git clone my-fork-project master
3、将fork的源项目地址进行关联(这里的upstream随意填写和origin同级 相当于一个远程仓库的关联)
git remote add upstream (fork的别人的源仓库地址)
3.获取并合并upstream代码到本地
git fetch upstream
git merge upstream/master
// 或者直接(fetch更安全)
git pull upstream master
4.提交代码并推送到自己的远程仓库
git add .
git commit -m ‘merge upstream’
git push
5.将自己提交的代码推送到原作者的远程仓库(需要权限),如果没有权限可以去github新建pull request, 发起拉请求之前应先同步原作者代码
git push upstream master
1、gIt忽略文件的原则是:
a. 忽略操作系统自动生成的文件,比如缩略图等;
b. 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
c. 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
2、强制添加被忽视的文件
$ git add -f App.class
3、忽略某些文件时,需要编写.gitignore;也可以在github上编辑。
1、git配置级别主要有以下3类:
1)仓库级别 local 【优先级最高】
2)用户级别 global【优先级次之】
3)系统级别 system【优先级最低】
2、git 仓库级别对应的配置文件是当前仓库下的.git/config 【在当前目录下.git目录默认是隐藏的,所以在文件管理器中我们要打开显示以藏文件】
进入到具体的目录下查看仓库配置 git config --local -l
3、git 用户级别对应的配置文件是用户宿主目录下的~/.gitconfig 【宿主目录:C:\Users\xiong】
进入到具体的目录下查看用户配置 git config --global -l
4、git系统级别对应的配置文件是git安装目录下的 /etc/gitconfig
进入到具体的目录下查看系统配置 git config --system -l
5、查看所有的配置信息,依次是系统级别、用户级别、仓库级别
git config -l
6、编辑配置文件 git config --local -e
7、添加配置项
git config --global user.email “you@example.com”
git config --global user.name “Your Name”
配置这两个主要是为了知道代码是谁提交的
8、配置命令别名
$ git config --global alias.st status
$ git st
9、启动默认的颜色配置 git config --global color.ui true
记住:HEAD指向当前分支,当前分支指向提交点
刚开始master分支
新建dev分支:

修改dev分支并提交

dev合并到master分支:

删除dev分支后:

gitlib是在git的基础上开发的开源的分布式版本控制系统,Ruby语言开发的,可用于管理项目源代码,对源代码进行版本控制、以及代码的复制和查找。
gitlib是按着github做的,gitlib有社区版和企业版。社区版不收费
1、开源免费,搭建简单,维护成本低,适合中小型企业
2、权限管理,代码对部分人可见,确保项目安全性
3、离线同步,不在实时依赖网络环境
sudo docker run --detach
–hostname mygitlab.com
–publish 443:443 --publish 80:80 --publish 22:22
–name gitlab
–restart always
–volume /srv/gitlab/config:/etc/gitlab
–volume /srv/gitlab/logs:/var/log/gitlab
–volume /srv/gitlab/data:/var/opt/gitlab
gitlab/gitlab-ce:latest
volume的冒号前面为物理机器上的实际目录,需提前建好,然后改为正确路径。冒号后面为挂载点,不要改。
22是ssh端口
443是https端口
初次访问需要设置root密码。
vi /opt/docker/gitlab/config/gitlab.rb
external_url ‘http://172.1.1.1:9081’
vi /opt/docker/gitlab/config/gitlab.rb
gitlab_rails[‘smtp_enable’] = true
gitlab_rails[‘smtp_address’] = “smtp.server”
gitlab_rails[‘smtp_port’] = 465
gitlab_rails[‘smtp_user_name’] = “smtp user”
gitlab_rails[‘smtp_password’] = “邮箱授权码”
gitlab_rails[‘smtp_domain’] = “example.com”
gitlab_rails[‘smtp_authentication’] = “login”
gitlab_rails[‘smtp_enable_starttls_auto’] = true
gitlab_rails[‘smtp_openssl_verify_mode’] = ‘peer’
如果你使用的SMTP服务是默认的 ‘From:gitlab@localhost’,你可以修改这里的 ‘From’ 的值。
gitlab_rails[‘gitlab_email_from’] = ‘gitlab@example.com发邮件的人’
gitlab_rails[‘gitlab_email_reply_to’] = ‘noreply@example.com’
gitlib-ctl reconfigure
gitlib-ctl start
gitlib-ctl restart
gitlib-clt status
gitlib-clt tail
gitlib-clt stop
用户和组关联,组和项目关联。加入组的用户可用操作项目,部分高级用户可用管理项目。
通常不会将用户直接关联到项目
1、先创建组
2、创建项目,让项目隶属于该组
3、创建用户,添加到组 并分配权限
【创建组】->组名->群组url自动生成->组描述->可见性: 私有->允许创建项目:开发人员
【创建项目】->项目名称->项目url:选择创建的组->项目标识:默认和项目名称相同->项目描述->可见等级:私有
【创建用户】->名称->邮箱->can create group->access level:普通用户/管理员
新用户创建后可收到邮件,在邮件中设置密码
选择组->选择用户->选择角色(开发、主程序、访客、所有者等)->确定
开发人员只能看代码
主程序人员可以修改代码
管理中心->设置->注册设置->取消注册
一、设置备份
1、gitlib默认的备份路径 在/etc/gitlab/gitLab.rb文件中查找backup_path
2、一般会新建一个有大空间的目录存放备份
mkdir /data/gitlab/backups -p
修改备份路径:backup_path = “/data/gitlab/backups”
backup_keep_time = 604800 保留7天
3、重新加载配置:gitlab-ctl reconfigure
二、手动执行备份
gitlab-rake gitlab:backup:create
三、将备份写入定时任务,自动执行备份
1、命令:crontab -e
在打开窗口中写入“ 00 09 00 00 00 gitlab-rake gitlab:backup:create”并保存
00 00 00 00 00 (对应分时日月周)
2、执行命令 crontab -l
一、停止数据写入服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
二、备份
gitlab-rake gitlab:backup:restore BACKUP=备份名(不要备份文件的_gitlab_backup.tar后缀)
三、重启
gitlab-ctl restart
master分支
feature分支:新功能分支
bug分支:修改bug
code review分支:代码评审分支
1、找到commitId
2、git checkout -b branchname commitid
3、git push origin branchname
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。