git和github

 

git

Git 是一个开源的分布式版本控制软件,用以有效、高速的处理从很小到非常大的项目版本管理.

git的目的:通过git来管理github来托管项目代码。

安装很简单直接在官网上下载对应的操作系统就可以了

git分为的区域

工作区:我们编辑修改,删除文件的地方。

暂存区:暂存已经修改好的文件,最后统一提交到仓库中。

仓库区:最后确认的文件保存到仓库区,成为一个新的版本并且对他人可见。

git的操作

安装好了后就可以运行了.

1.首先在所要管理的项目文件夹类,点击鼠标右键 选择git bash here ,就可以得到git的命令行窗口

2.初始化命令,初始化完成后, 会在当前目录自动创建 .git 文件夹(注意这是一个隐藏的文件夹),该文件是Git中最重要的文件夹,因为Git相关文件以及版本都将保存在该文件夹中,有了它,妈妈再也不用担心我好多文件来记录版本了,通过Git命令可以将所有版本保存在 .git 文件中,两条命令创建一个版本:

git init

3. git status 查看当前状态

4. git add   后边跟文件名,你要把那个文件添加,如果是所有文件的话,就是这样

git add .  #把所有文件添加到暂存区

5. 提交版本到库,并填写版本说明,以便以后回滚 注意.git中会增加一个object文件

git commit -m  "第一次提交" 

注意在这时候可能需要你输入用户名和邮箱,该配置用于记录当前版本由那个用户提交

git config --local user.name '小明'
git config --local user.email 'you@example.com'

6. 查看版本记录

git log
MacBook-Pro-4:pondo wupeiqi$ git log                      # 查看历史版本提交记录(根据版本commit值可以进行回滚)
commit f139d5d0a648af06d8a1ecadd90faf572afc388a
Author: 小明<you@example.com>
Date:   Fri Aug 11 10:02:14 2017 +0800

    第二次提交

commit df47fe49fc1f14d9cdd1534baa96f46ec71a9934
Author: 武沛齐 <you@example.com>
Date:   Fri Aug 11 08:49:49 2017 +0800

    第一次提交

 

7.当前版本上线后发现效果不理想,还没有上个版本好用,需要回滚到上个版本.

- git reset --hard df47fe49fc1f14d9cdd1534baa96f46ec71a9934  出现问题回滚到上一个代码脚本

8. 查看回滚后的版本记录

git reflog

9,某一天,我又想用我第二次提交的版本

git reset --hard  f139d5d0a648af06d8a1ecadd90faf572afc388a

查看设置命令   git config --list

core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
rebase.autosquash=true
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
http.sslbackend=openssl
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager
user.email=sticker@example.com
user.name=sticker
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
remote.origin.url=https://github.com/Sticker0726/github_text.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

 

stash

场景应用

在你刚开发到一半的功能时,发现原来上线的代码出bug了,stash用于将工作区发生变化的所有文件获取临时存储在“某个地方”将工作区还原当前版本未操作前的状态,去修复bug,

git stash 

你处理完bug后,这时候还要继续开发没完成的功能,这时候你需要找到刚才暂存的那些文件

get stash pop  

执行 git stash pop 命令时,可能会遇到冲突,因为在紧急修复bug的代码和通过stash存储在“某个地方”的代码会有冲突的部分,(因为你在原文件修改了bug,但是在新功能中还没修改)所以执行 git stash pop 时候就会出现冲突,有冲突解决冲突即可。其实就是直接删掉没有修复bug的代码,保留修复后的代码.

a. 原来内容:
    from django.shortcuts import render,HttpResponse

    def index(request):
        return render(request,'index.html')

    def africa(request):
        return HttpResponse('非洲专区')

    
b. 开发到一半直播功能:
    from django.shortcuts import render,HttpResponse

    def index(request):
        return render(request,'index.html')

    def africa(request):
        return HttpResponse('非洲专区')


    def live(request):
        print('开发到一半')
        return HttpResponse('....')


c. 执行git stash,回到当前版本未修改状态:
    from django.shortcuts import render,HttpResponse

    def index(request):
        return render(request,'index.html')

    def africa(request):
        return HttpResponse('非洲专区')

d. 修复Bug并提交:
    from django.shortcuts import render,HttpResponse

    def index(request):
        return render(request,'index.html')

    def africa(request):
        return HttpResponse('非洲xxxxx专区')


e. 继续开发直播功能 git stash pop,此时会出现冲突:
    MacBook-Pro-4:pondo wupeiqi$ git stash pop
    Auto-merging app01/views.py
    CONFLICT (content): Merge conflict in app01/views.py

    表示app01/views.py存在冲突需要解决,此时文件内容为:

    from django.shortcuts import render,HttpResponse

        def index(request):
            return render(request,'index.html')

        def africa(request):
        <<<<<<< Updated upstream:               # 修复Bug时更改的内容
            return HttpResponse('非洲xxxx区')  
        =======                                  # 修复Bug前正在开发新功能时的内容
            return HttpResponse('非洲专区')

        def live(request):
            print('刚开发到一半')
            return HttpResponse('直播功能')
        >>>>>>> Stashed changes


    需要自行解决冲突,然后继续开发,如:

    from django.shortcuts import render,HttpResponse

        def index(request):
            return render(request,'index.html')

        def africa(request):
        
            return HttpResponse('非洲xxxx区')  
        
        def live(request):
            print('刚开发到一半')
            return HttpResponse('直播功能')
        

git stash pop 出现冲突
View Code

相关的命令

git stash             将当前工作区所有修改过的内容存储到“某个地方”,将工作区还原到当前版本未修改过的状态
git stash list        查看“某个地方”存储的所有记录
git stash clear     清空“某个地方”
git stash pop       将第一个记录从“某个地方”重新拿到工作区(可能有冲突)
git stash apply     编号, 将指定编号记录从“某个地方”重新拿到工作区(可能有冲突) 
git stash drop      编号,删除指定编号的记录

branch

其实在我们真正的工作中很少用stash来处理写到一半的功能的代码的. 一般开发新功能流程为:开发新功能时会在分支dev上进行,开发完毕后再合并到master分支。

注意: 分支学习:branch称为分支,默认仅有一个名为master的分支。你需要注意,下边代码括号中的内容就是当前文件的分支

 

1.创建一个新分支 ,其实就是把master中的代码复制了一份,注意这两个分支是并列的关系不是不是包含的关系

git branch dev

2, 切换到新分支dev

git checkout dev

3,当开发到一半遇到上个版本有bug时候

当要紧急修复bug了
                    a. 将 dev 中现在正在开发的功能提交到dev
                        git add .
                        git commit -m 'xxx'
                        
                    b. 切换回主分支
                        git checkout master 
                    
                    c. 创建并切换到bug分支 #这里不要在master中修改bug要新开一个bug分支
                        git branch bug 
                        git checkout bug 
                        在bug分支上进行修复....
                        git add .
                        git commit -m 'xxx'

4. 把修复好的bug分支合并到master分支中

 git checkout master #首先切换到master分支
git merge bug  #在master分支中合并bug分支
                        
git branch -d bug   #删除bug分支,一半情况下都需要删除bug分支的

5切换到 未开发完功能的代码,继续开发,开发完提交到dev中然后再和master合并

切换到dev继续开发
git checkout dev 
.....
git add .
git commit -m '开发完成guanzi'
                        
                        
git checkout master  #切换到master分支
git merge bug    #合并bug

面试题: 如何理解 git rebase 和 git merge 的区别?

当用git merge 合并分支的时候:

合并后git log查看,所有历史提交都在。
提交比较完整的保留,如果你的提交比较杂乱,你会发现分支特别的混乱,这就成了缺点。而且merge会引入一个合并提交。

 

 

当用 git rebase 合并分支的时候

 

 

 合并后git log查看,提交历史是以最新dev2分支为基础的,master自己的提交记录在新基础的后方。即线性提交,这样看起来很舒服

 

 

 从上图可以看出,在对特征分支进行rebase之后,其等效于创建了新的提交。并且老的提交也没有被销毁,只是简单地不能再被访问或者使用。

Rebase的黄金法则

1.不能在公共分支上使用它。比如master,develop。
2.通常用在你自己的独享分支上。

不能再一个共享的分支上进行Git rebase操作。所谓共享的分支,即是指那些存在于远端并且允许团队中的其他人进行Pull操作的分支。

总结:

1.想要保存项目完整的历史,并且避免重写公共分支上的commit,使用git merge

2.想要一个干净的、线性的提交历史,没有不必要的合并提交,使用 git rebase

 

注意:  

如果产生冲突:
解决完冲突后, 需要执行这样操作

git add .
git rebase --continue

如果要以最后提交分支中的内容为主的话,可以执行下边这个操作

git rebase --skip

 

merge vs rebase

到底该使用 merge 方式开发还是使用 rebase 方法开发是有争议的

有一种观点认为,仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档,本身就有价值,不能乱改。 从这个角度看来,改变提交历史是一种亵渎,你使用谎言掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办? 既然事实就是如此,那么这些痕迹就应该被保留下来,让后人能够查阅。

另一种观点则正好相反,他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事,怎么方便后来的读者就怎么写。

总的原则是,只对尚未推送或分享给别人的本地修改执行变基操作清理历史,从不对已推送至别处的提交执行变基操作,这样,你才能享受到两种方式带来的便利。

  • git branch 分支名称             创建分支
    git checkout 分支名称          切换分支
    git branch -m 分支名称        创建并切换到指定分支
    git branch                          查看所有分支
    git branch -d 分支名称         删除分支
    git merge 分支名称              将指定分支合并到当前分支

     

github

GitHub是一个基于Git的远程文件托管平台(同GitCafe、BitBucket和GitLab等)。

1.  开发完毕部分功能将代码推送到GitHub。 

首先你要先在github上建立一个库

$ git remote add origin https://github.com/WuPeiqi/pondo.git   # 为地址起一个别名origin
$ git push origin master              # 将本地master分支内容以及版本信息推送到GitHub
Username for 'https://github.com':                               # 输入GitHub用户名
Password for 'https://':                       # 输入GitHub密码
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 270 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/WuPeiqi/pondo.git
   634aac4..274f1e4  master -> master
$ git push origin dev              # 将本地dev分支内容以及版本信息推送到GitHub
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 261 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/WuPeiqi/pondo.git
   274f1e4..50e2169  dev -> dev

这里如果出现了:

 

原因:电脑公钥(publickey)未添加至github,所以无法识别。 因而需要获取本地电脑公钥,然后登录github账号,添加公钥至github就OK了。

 具体解决方法:见微博:https://www.jianshu.com/p/3b56f4e6ac77

 

 

 在公司 第一次使用该仓库需要需要将代码从GitHub中获取并继续开发 .  注意这里只是把mster分支获取出来了,

$ git clone https://github.com/WuPeiqi/pondo.git    # 将项目从GitHub中获取,

2.切换到项目内  注意很重要 我好几次就出错在这里了

 cd pondo

3. 创建dev并远程下载dev

 git checkout -b dev  # 创建分支b并且切换到b分支, 一定要先创建才能拉下来远程的代码
git pull origin dev #从远程下载dev分支 一定要下载,否则提交不上去
  

4. 把编写完的工作区代码 提交到暂存区,暂存区代码提交到仓库

git add .
git commit -m '2018提交’

5.把仓库中的dev 分支提交到github上的dev分支上去

git push origin dev

在家里 1. 切换到dev分支,并从远程GitHub仓库获取dev分支最新内容,并合并到本地

git checkout dev                                   # 切换到dev分支
git pull origin dev                                # 从远程GitHub仓库获取dev分支最新内容,并合并到本地

 2.然后写dev 上传远程,这样就可以刻重复操作

协同开发出现的冲突

在公司里,每个人会有一个分支, 特别是当两个人开发同一个脚本时,如果一个人先提交,则第二个人提交时会发生冲突,这时候的解决方法

1.把提交的那个人的代码拉下来,
2. 这时候和你的进行合并   #其实不需要你自己合并,git会自己帮你合并的,这是我联系的时候发现的
3.手动解决冲突后
4.提交到远程

 

有三种方式操作,三者都可以完成合并并提交新功能,但是日志记录会有差异,如:前两者版本记录中会出现合并,而第三种可以保证版本记录干净整洁。

  • 先 git pull origin master   然后 git push origin master
  • 先 git fetch origin master 然后 git merge origin/master   再 git push origin master
  • 先 git fetch origin master 然后 git rebase origin/master  再 git push origin master

 贡献给别人的代码的方式:

1.提交issue

2.pull request 提交请求:

  1.   需要先fork别人的仓库到自己的仓库中。
  2. 然后再自己的仓库中添加好新功能。
  3. 然后提交 pull request
  4. 最后经原创者同意。

 

 详细内容见: 佩奇博客

 github page 搭建个人网站

 

 
 
posted @ 2019-03-27 23:04  种树飞  阅读(249)  评论(0)    收藏  举报