I can believe fly.

Wednesday, June 27, 2018

docker 日常操作命令集

查看容器
docker ps -a

删除容器
docker rm 3b2620dd77cf

查看镜像
docker images

删除镜像
docker rmi  本地镜像名称:tag名称
docker rmi  IMAGEID   (会碰到image is referenced in multiple repositories)

获取镜像
docker pull 远程镜像

为镜像打标答
docker tag 本地镜像名称:tag名称  远程镜像仓库名称:tag名称

推送打好的标答到远程仓库

docker push  远程镜像仓库名称:tag名称 

GIT学习-两个git仓库迁移操作

命令行:
1. 创建新仓库
2. 以bare方式clone旧仓库:
    git clone —bare  旧仓库

3. 以镜像方式推送到新仓库
       cd 旧仓库
    git push --mirror 新仓库远程地址

4. 如果想保留本地暂存stash的修改记录,更换远程指向地址

    git remote set-url origin remote_git_address 


界面式:
在界面创建项目时选择Import project -》Repo by URL按指引操作

Tuesday, June 19, 2018

git clone 三种方式

  • git clone origin-url (non-bare) : you will get all of the tags copied, a local branch master (HEAD) tracking a remote branch origin/master, and remote branches origin/next,origin/pu, and origin/maint. The tracking branches are set up so that if you do something like git fetch origin, they'll be fetched as you expect. Any remote branches (in the cloned remote) and other refs are completely ignored.
  • git clone --bare origin-url : you will get all of the tags copied, local branches master (HEAD), next, pu, and maint, no remote tracking branches. That is, all branches are copied as is, and it's set up completely independent, with no expectation of fetching again. Any remote branches (in the cloned remote) and other refs are completely ignored.
  • git clone --mirror origin-url : every last one of those refs will be copied as-is. You'll get all the tags, local branches master (HEAD), next, pu, and maint, remote branchesdevA/master and devB/master, other refs refs/foo/bar and refs/foo/baz. Everything is exactly as it was in the cloned remote. Remote tracking is set up so that if you run git remote update all refs will be overwritten from origin, as if you'd just deleted the mirror and recloned it. As the docs originally said, it's a mirror. It's supposed to be a functionally identical copy, interchangeable with the original.
  • Monday, June 18, 2018

    iOS构建环境CocoaPods故障处理--`find_spec_for_exe': can't find gem cocoapods

    【问题】
    关健信息:.rvm/rubies/ruby-2.3.3/lib/ruby/site_ruby/2.3.0/rubygems.rb:271:in `find_spec_for_exe': can't find gem cocoapods (>= 0.a) (Gem::GemNotFoundException)

    从日志原以为是环境某个依赖库更新导致的问题
    查看gem list 对比其它环境,发现有些工具依赖版本不同,但是最近软件并没有更新。
    换个思路,到本地工程路径下pod install --repo-update 时发现创建Pods目录提示没有权限 
     ls -l 一看,才发现工作区是以root权限获取的。这说明slave是root账号拉起,但我们实际服务是要用另一个账号。
    解决:ps -ef | grep jenkins 查看是否有进程残留,如有先kill,最后重启slave服务。