关闭

git

306人阅读 评论(0) 收藏 举报
git 命令说明


1、初始化git repository 建立仓库
cd 工作目录
git init


2、向仓库接交文件(这里每次修改都重复的步骤)
git add 文件名                      //每次修改,如果不add到暂存区,那就不会加入到commit中
如果这时修改文件,(暂叫:第二次修改)
git commit -m "版本说明"


第二次修改的并没有提交到仓库,所以git commit 只提交 git add 当时放到暂存区的内容,如果在git add 之后再修改文件,并不能提交。


3、查看本地修改与仓库文件不同
git diff 文件名




4、查看本地文件状态
git status


如发现更改:重复第二步git add ,git commit提交更改


5、查看log日志
git log


commit bd2e79523074db036338ee7ace96599ea20fa4f6
Author: mo <1731550497@qq.com>
Date:   Fri Mar 25 11:08:05 2016 +0800


    修改增加插件说明


commit 89b08b08f2487707a3111290998afaf6de8f50b1
Author: mo <1731550497@qq.com>
Date:   Fri Mar 25 11:04:46 2016 +0800


    增加一行文字


commit 769e8ab95c779876b7be04cf8d1f89bcb4e3587e
Author: mo <1731550497@qq.com>
Date:   Fri Mar 25 11:00:11 2016 +0800


这里显示提交的版本ID :commit 后面这一串,bd2e79523074db036338ee7ace96599ea20fa4f6
提交者:mo <1731550497@qq.com>
提交时间: Fri Mar 25 11:04:46 2016 +0800
如果要退回版本:就用到ID


6、退回:退回到指定ID的版本
git reset --hard 提交ID


7、查看所有的ID:这个命令用于当有退回时,还可以回到未来。
git reflog


bd2e795 HEAD@{0}: reset: moving to bd2e795
89b08b0 HEAD@{1}: reset: moving to 89b08b08f2487707a3111290998afaf6de8f50b1
bd2e795 HEAD@{2}: commit: 修改增加插件说明
89b08b0 HEAD@{3}: commit: 增加一行文字
769e8ab HEAD@{4}: commit (initial): 首次个改,


这里显示提交的版本ID在前面:89b08b0


7-1、有关概念:
工作区:即当前正在修改的文件夹。
暂存区:使用git add 时文件的状态。
仓库区:使用git commit已提交的文件。


8、撤销未提交的(工作区)更改:
git checkout -- 文件名


退回到最后一次提交到仓库的状态。


9、撤销对暂存区的更改:
git reset HEAD 文件名












远程仓库:


在继续阅读后续内容前,请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:


第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:


$ ssh-keygen -t rsa -C "youremail@example.com"


你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。


如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。


第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:


然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容:


github-addkey-1


点“Add Key”,你就应该看到已经添加的Key:


github-addkey-2


为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。


当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。


最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。


如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。


确保你拥有一个GitHub账号后,我们就即将开始远程仓库的学习。


一、增加远程仓库关联: git remote add origin https://github.com/KevinMoo/mytest1.git 
二、向远程仓库推送: git push -u origin master
以上:origin仓库的名称,master表示分支名称,https://github.com/KevinMoo/mytest1.git  仓库地址
由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。






三、从服务器上第一下下载代码:
git clone https://github.com/KevinMoo/gitskills.git
https://github.com/KevinMoo/gitskills.git是远程仓库的地址。
这条命令会创建一个项目名的文件夹。如本例:gitskills。所以如果要克隆代码,不需要先创建文件夹。只要在上级文件夹运行命令就行了。


如果有多个人协作开发,那么每个人各自从远程克隆一份就可以了。


你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。


使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
小结


要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。


Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。


四,分支管理
1、创建分支(并切换):
git checkout -b dev


dev 是分支名称
git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
git branch dev
git checkout dev


2、查看分支
git branch


git branch命令会列出所有分支,当前分支前面会标一个*号。


3、切换回master分支
git checkout master


4、合并更改:将dev分支上的合并到master
先用上面命令切换回master分支:git checkout master
再合并:git merge dev


5、删除分支
合并完成后,就可以放心地删除dev分支了:
git branch -d dev




6、冲突解决:
如果两个分支都修改了同一个文件,并切通过:
git add readme.txt
git commit -m "说明"
提交了,
这里再合并,就会产生冲突。
git merge dev
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
如上所示,表示有冲突。
git status 
查看状态。
这时就要解决,通过以上命令之后。git 会在文件中标注各自的修改:
例如:
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> dev
Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容,我们修改如下后保存,再提交:
git add readme.txt 
git commit -m "conflict fixed"


用以下命令可以查看冲突的图示:
git log --graph --pretty=oneline --abbrev-commit
git log --graph




五、分支管理策略


通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。


如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。


下面我们实战一下--no-ff方式的git merge:


首先,仍然创建并切换dev
命令:请注意--no-ff参数,表示禁用Fast forward
git merge --no-ff -m "merge with no-ff" dev






分支策略


在实际开发中,我们应该按照几个基本原则进行分支管理:


首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;


那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;


你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。


六、保护现场,Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。


当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交:


并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?


幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
1、保护当前分支的命令:
git stash


2、当修复bug 之后,再回到dev分支。
查看分支现声命令:
git stash list
返回 :
stash@{0}: WIP on dev: deabb6a merge with no-ff
表示存在stash


一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;


另一种方式是用git stash pop,恢复的同时把stash内容也删了:
3、还原现场:
git stash pop




七、Feature分支
当分支功能未合并,但又想销毁,需要用:
git branch -D 分支名称
注意-D是大写字母


八、多人协作。
1、查看远程仓库名称:
git remote


更多内容:
git remote -v


2、推送,上面已经有了:
git push origin master


但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?


    master分支是主分支,因此要时刻与远程同步;


    dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;


    bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;


    feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。


总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!










因此,多人协作的工作模式通常是这样:


    首先,可以试图用git push origin branch-name推送自己的修改;


    如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;


    如果合并有冲突,则解决冲突,并在本地提交;


    没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!


如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name。


这就是多人协作的工作模式,一旦熟悉了,就非常简单。


提示这个:
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'feature/newbranch_name' which can not be resolved as commit? 
原因,在拉取时未建立分支,后来建立的分支,这里拉取不至,解决如下:
  
git remote show origin  
    #If the remote branch you want to checkout is under "New remote branches" and not #"Tracked remote branches" then you need to fetch them first:  
  
git remote update  
git fetch  
     #Now it should work:  
  
git checkout -b local-name origin/remote-name  




一份代码推送到多仓库


通过谷歌、度娘可以很快的找到一大堆关于git如何配置推送到多仓库,配置我就不在啰嗦了,直接打开.git\config文件添加或看命令:


git remote set-url --add origin https://www.xxx.com/xxx/xxx.git


配置是好了,但是我找了半天也没找到在两个或多个仓库建好之后是如何初始化,举个栗子:A为你现在正在使用的远程仓库,里边已有用绳命敲的码;B为新建的空的、null、empty的远程仓库。那么问题来了:怎么才能把两个远程仓库代码同步?以便以后可以代码同时推送到这两个仓库。


这就是答案、答案、答案


直接在命令行敲:


git push -f origin master 注释: origin远程仓库名,master分支名,-f为force,意为:强行、强制。


这行命令的意思就是强制用本地的代码去覆盖掉远程仓库的代码,敲git push --help可查看官方的解释(英文的)。当然不止这一种操作方式了,但是这种操作是最快(bao)速(li)的,不会有冲突什么的,当然我也有一个忠告:请谨慎使用!请谨慎使用!请谨慎使用!


又是一个快乐的周末


看个视频,然后就睡觉了。Good Night!














3. 从服务器端检出版本库到PC-2,在PC-2上新建文件并上传到服务器端:
  git clone ssh://huzhenwei@192.168.1.2/home/huzhenwei/repos.git workspace
  cd workspace
  touch newfile         #创建一个新文件来做测试
  git add newfile
  git commit -m 'add newfile'
  git push origin master        #将本地的代码上传到服务器端


4. 在PC-1上获取PC-2更新的内容:
  git pull origin master        #将服务器端的代码下载到本地








3、切换回master分支
git checkout master


4、合并更改:将dev分支上的合并到master
先用上面命令切换回master分支:git checkout master
再合并:git merge --no-ff dev
上一条命令的--no-ff参数是什么意思。默认情况下,Git执行"快进式合并"(fast-farward merge),会直接将Master分支指向Develop分支。
使用--no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法
5、删除分支
合并完成后,就可以放心地删除dev分支了:
git branch -d dev
重建dev分支
git checkout -b dev




以后开发在dev上进行,如果完成一定功能后合并到master.
如果在开发过程中发现,使用中的版本有问题,先保护好当前dev分支现场,然后直接从master生成一个分支,然后在上面修改,修改完成后,生成并发布应用,然后合并到master分支。
刚打的补丁dev分支怎么办?把补丁的问题也合并到dev
具体的操作如下:
1、保护dev现场:
如果没有在dev,先切回dev:   git checkout dev
git stash
2、切回当前正在使用的版本,一般是master分支,即在已发布的分支上修复bug 
git checkout master
3、生成修复分支:取名为:fixbug-0.1
git checkout -b fixbug-0.1
现在回到VS修复问题 ,测试OK之后。生成应用,发布应用,上传到服务器。完成修复,下面的工作是代码管理工作。
4、提交fixbug-0.1
git add .
git commit -m "关于bug修复说明"
5、合并到master
git checkout master
git merge --no-ff fixbug-0.1
这里可以增加一个标签:git tag -a 1.1
6、合并到dev分支,这一步有可能有问题。因为如果修复的bug与dev正在修改的有冲突,那么可能会出现代码冲突,这里参考前面的处理冲突来做。
先恢复现场:
git stash pop
git merge --no-ff fixbug-0.1
7、最后一步,删除fixbug-0.1分支,大功告成
git branch -d fixbug-0.1















0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:94266次
    • 积分:1353
    • 等级:
    • 排名:千里之外
    • 原创:36篇
    • 转载:10篇
    • 译文:0篇
    • 评论:31条
    文章分类
    最新评论