feed.rss

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content"><channel><title>JimLearningBlog</title><description>A description of JimLearningBlog</description><link>https://jimlearning.github.io</link><language>zh</language><lastBuildDate>Sat, 13 Mar 2021 22:21:30 +0800</lastBuildDate><pubDate>Sat, 13 Mar 2021 22:21:30 +0800</pubDate><ttl>250</ttl><atom:link href="https://jimlearning.github.io/feed.rss" rel="self" type="application/rss+xml"/><item><guid isPermaLink="true">https://jimlearning.github.io/tips/%E5%B8%B8%E7%94%A8%20Git%20%E5%91%BD%E4%BB%A4%E6%B8%85%E5%8D%95</guid><title>常用 Git 命令清单</title><description>常用 Git 命令清单.</description><link>https://jimlearning.github.io/tips/%E5%B8%B8%E7%94%A8%20Git%20%E5%91%BD%E4%BB%A4%E6%B8%85%E5%8D%95</link><pubDate>Fri, 13 Mar 2020 22:00:00 +0800</pubDate><content:encoded><![CDATA[<h1>常用 Git 命令清单</h1><p>作者： 阮一峰 日期： 2015年12月 9日</p><p>我每天使用 Git ，但是很多命令记不住。 一般来说，日常使用只要记住下图6个命令，就可以了。但是熟练使用，恐怕要记住60～100个命令。</p><img src="http://www.ruanyifeng.com/blogimg/asset/2015/bg2015120901.png"/><p>下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。</p><pre><code><span class="type">Workspace</span>：工作区
<span class="type">Index</span> / <span class="type">Stage</span>：暂存区
<span class="type">Repository</span>：仓库区（或本地仓库）
<span class="type">Remote</span>：远程仓库
</code></pre><h2>一、新建代码库</h2><pre><code># 在当前目录新建一个Git代码库
$ git <span class="keyword">init</span>

# 新建一个目录，将其初始化为Git代码库
$ git <span class="keyword">init</span> [project-name]

# 下载一个项目和它的整个代码历史
$ git clone [url]
</code></pre><h2>二、配置</h2><p>Git的设置文件为.gitconfig，它可以在用户主目录下（全局配置），也可以在项目目录下（项目配置）。</p><pre><code># 显示当前的Git配置
$ git config --list

# 编辑Git配置文件
$ git config -e [--global]

# 设置提交代码时的用户信息
$ git config [--global] user.<span class="property">name</span> <span class="string">"[name]"</span>
$ git config [--global] user.<span class="property">email</span> <span class="string">"[email address]"</span>
</code></pre><h2>三、增加/删除文件</h2><pre><code># 添加指定文件到暂存区
$ git add [file1] [file2] ...

# 添加指定目录到暂存区，包括子目录
$ git add [dir]

# 添加当前目录的所有文件到暂存区
$ git add .

# 添加每个变化前，都会要求确认
# 对于同一个文件的多处变化，可以实现分次提交
$ git add -p

# 删除工作区文件，并且将这次删除放入暂存区
$ git rm [file1] [file2] ...

# 停止追踪指定文件，但该文件会保留在工作区
$ git rm --cached [file]

# 改名文件，并且将这个改名放入暂存区
$ git mv [file-original] [file-renamed]
</code></pre><h2>四、代码提交</h2><pre><code># 提交暂存区到仓库区
$ git commit -m [message]

# 提交暂存区的指定文件到仓库区
$ git commit [file1] [file2] ... -m [message]

# 提交工作区自上次commit之后的变化，直接到仓库区
$ git commit -a

# 提交时显示所有diff信息
$ git commit -v

# 使用一次新的commit，替代上一次提交
# 如果代码没有任何新变化，则用来改写上一次commit的提交信息
$ git commit --amend -m [message]

# 重做上一次commit，并包括指定文件的新变化
$ git commit --amend [file1] [file2] ...
</code></pre><h2>五、分支</h2><pre><code># 列出所有本地分支
$ git branch

# 列出所有远程分支
$ git branch -r

# 列出所有本地分支和远程分支
$ git branch -a

# 新建一个分支，但依然停留在当前分支
$ git branch [branch-name]

# 新建一个分支，并切换到该分支
$ git checkout -b [branch]

# 新建一个分支，指向指定commit
$ git branch [branch] [commit]

# 新建一个分支，与指定的远程分支建立追踪关系
$ git branch --track [branch] [remote-branch]

# 切换到指定分支，并更新工作区
$ git checkout [branch-name]

# 切换到上一个分支
$ git checkout -

# 建立追踪关系，在现有分支与指定的远程分支之间
$ git branch --<span class="keyword">set</span>-upstream [branch] [remote-branch]

# 合并指定分支到当前分支
$ git merge [branch]

# 选择一个commit，合并进当前分支
$ git cherry-pick [commit]

# 删除分支
$ git branch -d [branch-name]

# 删除远程分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]
</code></pre><h2>六、标签</h2><pre><code># 列出所有tag
$ git tag

# 新建一个tag在当前commit
$ git tag [tag]

# 新建一个tag在指定commit
$ git tag [tag] [commit]

# 删除本地tag
$ git tag -d [tag]

# 删除远程tag
$ git push origin :refs/tags/[tagName]

# 查看tag信息
$ git show [tag]

# 提交指定tag
$ git push [remote] [tag]

# 提交所有tag
$ git push [remote] --tags

# 新建一个分支，指向某个tag
$ git checkout -b [branch] [tag]
</code></pre><h2>七、查看信息</h2><pre><code># 显示有变更的文件
$ git status

# 显示当前分支的版本历史
$ git log

# 显示commit历史，以及每次commit发生变更的文件
$ git log --stat

# 搜索提交历史，根据关键词
$ git log -<span class="type">S</span> [keyword]

# 显示某个commit之后的所有变动，每个commit占据一行
$ git log [tag] <span class="type">HEAD</span> --pretty=format:%s

# 显示某个commit之后的所有变动，其"提交说明"必须符合搜索条件
$ git log [tag] <span class="type">HEAD</span> --grep feature

# 显示某个文件的版本历史，包括文件改名
$ git log --follow [file]
$ git whatchanged [file]

# 显示指定文件相关的每一次diff
$ git log -p [file]

# 显示过去5次提交
$ git log -<span class="number">5</span> --pretty --oneline

# 显示所有提交过的用户，按提交次数排序
$ git shortlog -sn

# 显示指定文件是什么人在什么时间修改过
$ git blame [file]

# 显示暂存区和工作区的差异
$ git diff

# 显示暂存区和上一个commit的差异
$ git diff --cached [file]

# 显示工作区与当前分支最新commit之间的差异
$ git diff <span class="type">HEAD</span>

# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]

# 显示今天你写了多少行代码
$ git diff --shortstat <span class="string">"@{0 day ago}"</span>

# 显示某次提交的元数据和内容变化
$ git show [commit]

# 显示某次提交发生变化的文件
$ git show --name-only [commit]

# 显示某次提交时，某个文件的内容
$ git show [commit]:[filename]

# 显示当前分支的最近几次提交
$ git reflog
</code></pre><h2>八、远程同步</h2><pre><code># 下载远程仓库的所有变动
$ git fetch [remote]

# 显示所有远程仓库
$ git remote -v

# 显示某个远程仓库的信息
$ git remote show [remote]

# 增加一个新的远程仓库，并命名
$ git remote add [shortname] [url]

# 取回远程仓库的变化，并与本地分支合并
$ git pull [remote] [branch]

# 上传本地指定分支到远程仓库
$ git push [remote] [branch]

# 强行推送当前分支到远程仓库，即使有冲突
$ git push [remote] --force

# 推送所有分支到远程仓库
$ git push [remote] --all
</code></pre><h2>九、撤销</h2><pre><code># 恢复暂存区的指定文件到工作区
$ git checkout [file]

# 恢复某个commit的指定文件到暂存区和工作区
$ git checkout [commit] [file]

# 恢复暂存区的所有文件到工作区
$ git checkout .

# 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变
$ git reset [file]

# 重置暂存区与工作区，与上一次commit保持一致
$ git reset --hard

# 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变
$ git reset [commit]

# 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致
$ git reset --hard [commit]

# 重置当前HEAD为指定commit，但保持暂存区和工作区不变
$ git reset --keep [commit]

# 新建一个commit，用来撤销指定commit
# 后者的所有变化都将被前者抵消，并且应用到当前分支
$ git revert [commit]

# 暂时将未提交的变化移除，稍后再移入
$ git stash
$ git stash pop
</code></pre><h2>十、其他</h2><pre><code># 生成一个可供发布的压缩包
$ git archive
</code></pre><p>（完）</p><blockquote><p>文档信息<br>
> 版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）<br>
> 发表日期：2015年12月9日<br></p></blockquote>]]></content:encoded></item><item><guid isPermaLink="true">https://jimlearning.github.io/tips/script-with-swift</guid><title>Script with Swift</title><description>Learn how to run executable scripts in Swift.</description><link>https://jimlearning.github.io/tips/script-with-swift</link><pubDate>Tue, 28 Jan 2020 06:00:00 +0800</pubDate><content:encoded><![CDATA[<h2>Prerequisites</h2><p>To keep things simple we will assume you have access to a machine running macOS or Linux and have already installed Swift.</p><h2>How to script with swift</h2><img src="https://jimlearning.github.io/images/posts/swift-logo.svg" alt="Swift logo"/><p>If you are already a Swift developer, you should be familiar with the process of creating a Swift package, application or command line tool. Once you have created one of these you would usually need to build a binary and then place it in a executable path before it can be run from a Command Line Interface (CLI). Sometimes, however, we just want to write a script and execute it as is, rather than package it for deployment. This can be particularly useful if you'd like to use Swift in different stages of the software development lifecycle such as inside of your Continuous Integration or Continuous Deployment pipelines.</p><p>In such pipelines, it's typical to create a bash file and execute it. For example you could create a file called <code>hello-world</code> with the following contents:</p><pre><code>#!/usr/bin/env bash

echo <span class="string">"Hello, World!"</span>
</code></pre><p>You would then make it executable by running:</p><pre><code>chmod +x hello-world
</code></pre><p>And then execute it by running:</p><pre><code>./hello-world
</code></pre><p>But this is not just limited to runtime languages like bash, the comment on the first line tells the machine what program to use when interpreting the file. This means we can create and execute a script using the Swift programming language instead. For example, let's replace the contents of the <code>hello-world</code> file we created earlier with this:</p><pre><code>#!/usr/bin/env swift

<span class="call">print</span>(<span class="string">"Hello, World!"</span>)
</code></pre><p>Now you can execute the script by running the same command as we did earlier:</p><pre><code>./hello-world
</code></pre><p>Once again you should see the text <code>Hello, World!</code> printed to the console.</p><h2>Summary</h2><p>That's it! In this post we have demonstrated a simple way to build small Swift scripts that you can modify and run in place whenever you need to, without the need to recompile and deploy them.</p><h2>References</h2><ul><li><a href="https://swift.org/ "swift.org"">Swift</a></li></ul>]]></content:encoded></item><item><guid isPermaLink="true">https://jimlearning.github.io/articles/github-actions</guid><title>Continuous Deployment with GitHub Actions and Docker Hub</title><description>In this post we will assume that you practice Continuous Integration (CI) and have a product which is packaged as a Docker image. As your next step you are looking to implement Continuous Deployment (CD) from scratch or move to it from a Continuous Delivery workflow. Our aim will be to build and push a docker image to Docker Hub using GitHub actions.</description><link>https://jimlearning.github.io/articles/github-actions</link><pubDate>Mon, 20 May 2019 16:25:00 +0800</pubDate><content:encoded><![CDATA[<h2>Principles</h2><p>Before we dive into how we can achieve this goal, it’s important to understand the principles behind what we are trying to achieve and why. If you’re already familiar with Continuous Delivery and Continuous Deployment as well as the distinction between the two, feel free to skip this next part.</p><h3>What is Continuous Delivery?</h3><p>Continuous Delivery is a software development discipline where you build software in such a way that the it can be released to production at any time<sup>[1]</sup>. In a Continuous Delivery workflow, each development change that is pushed to the main repository is ready to be shipped. However, the action of shipping requires human approval. Although there is usually a focus on automated testing as part of this process, in many organisations the risk of promoting a release to production is shouldered by the individual approving that release. Onus is placed on the developers to prioritise keeping the code deliverable over implementing new features.</p><h3>How does Continuous Delivery differ from Continuous Deployment?</h3><p>By contrast, in Continuous Deployment each development change that is pushed to the main repository is automatically released to production, without any human intervention. In this workflow, a strong emphasis is placed on automated testing, as it should not be possible to merge code into the main development branch without that code passing a test suite. This means that the quality of your test suite determines the level of risk for a release, and automated testing must be prioritised during development. As such it’s important to ensure you don’t fall into the trap of mistaking good code coverage in your test suite for good quality tests. Developers within the team must ensure that the quality of tests presented in code reviews remains high.</p><h2>Using Github actions for Continuous Deployment</h2><p>Now that we understand what Continuous Deployment is and what we are aiming for, let’s create a workflow that builds a Docker image and publishes it to Docker Hub. To begin, you’ll need to navigate to GitHub, ensure you are logged in and have opened the repository that you would like to work with. The repository should already contain a <code>Dockerfile</code>. Click the <em>Actions</em> button at the top of the page: <img src="https://jimlearning.github.io/images/posts/github-actions-title-bar.jpg" alt="GitHub actions button"/></p><p>GitHub will prompt you to confirm that you’d like to create a new workflow, click the <em>Create a new workflow</em> button: <img src="https://jimlearning.github.io/images/posts/github-actions-create-button.jpg" alt="Git hook screenshot"/></p><p>Leave the name of the file as <code>main.workflow</code> and click the button labelled <em>Edit file</em> <img src="https://jimlearning.github.io/images/posts/github-actions-heading.jpg" alt="Git hook screenshot"/></p><p>Add the following to the contents of the editor, replacing <code>&lt;project-name&gt;</code> and <code>&lt;docker-hub-username&gt;</code> with the name of your project and username for Docker Hub:</p><pre><code># <span class="type">Create</span> a new workflow that’s triggered by a push to master
workflow <span class="string">"Build on push"</span> {
  on = <span class="string">"push"</span>
  resolves = [
    <span class="string">"Push Docker image with build number"</span>,
    <span class="string">"Push Docker image with latest"</span>,
    <span class="string">"Archive release"</span>
  ]
}

# <span class="type">Optionally</span> add an action to run your test suite here

# <span class="type">Filter</span> pushes to only those on the master branch
action <span class="string">"Filter for master"</span> {
  uses = <span class="string">"actions/bin/filter@master"</span>
  args = <span class="string">"branch master"</span>
}

# <span class="type">Login</span> to <span class="type">Docker Hub</span> with your credentials (<span class="type">The GitHub UI</span> will prompt you <span class="keyword">for</span> them <span class="keyword">if</span> they have not already been provided).
action <span class="string">"Authenticate with Docker Registry"</span> {
  uses = <span class="string">"actions/docker/login@master"</span>
  needs = [<span class="string">"Filter for master"</span>]
  secrets = [<span class="string">"DOCKER_USERNAME"</span>, <span class="string">"DOCKER_PASSWORD"</span>]
}

# <span class="type">Build</span> a docker image based off of a <span class="type">Dockerfile</span> <span class="keyword">in</span> the root directory of the repository
action <span class="string">"Build Docker Image"</span> {
  uses = <span class="string">"actions/docker/cli@8cdf801b322af5f369e00d85e9cf3a7122f49108"</span>
  needs = [<span class="string">"Authenticate with Docker Registry"</span>]
  args = <span class="string">"build -f Dockerfile --tag &lt;project-name&gt; ."</span>
}

# <span class="type">Give</span> the docket image a unique tag based on the <span class="type">GitHub SHA</span>
action <span class="string">"Tag Docker Image with build number"</span> {
  uses = <span class="string">"actions/docker/cli@8cdf801b322af5f369e00d85e9cf3a7122f49108"</span>
  needs = [<span class="string">"Build Docker Image"</span>]
  args = <span class="string">"tag &lt;project-name&gt; &lt;docker-hub-username&gt;/&lt;project-name&gt;:$GITHUB_SHA"</span>
}

# <span class="type">Automatically</span> push the image to <span class="type">Docker Hub</span>
action <span class="string">"Push Docker image with build number"</span> {
  uses = <span class="string">"actions/docker/cli@8cdf801b322af5f369e00d85e9cf3a7122f49108"</span>
  needs = [<span class="string">"Tag Docker Image with build number"</span>]
  args = <span class="string">"push &lt;docker-hub-username&gt;/&lt;project-name&gt;:$GITHUB_SHA"</span>
}

# <span class="type">Filter</span> <span class="keyword">for</span> a tag which indicates that this push <span class="keyword">is</span> a release (i.<span class="property">e</span>. <span class="property">the</span> push <span class="keyword">is</span> tagged with v1.<span class="number">0.0</span>)
action <span class="string">"Filter for tag"</span> {
  uses = <span class="string">"actions/bin/filter@master"</span>
  needs = [<span class="string">"Push Docker image with build number"</span>]
  args = <span class="string">"tag v*"</span>
}

# <span class="type">Tag</span> the docket image <span class="keyword">as</span> latest
action <span class="string">"Tag Docker Image with latest"</span> {
  uses = <span class="string">"actions/docker/cli@8cdf801b322af5f369e00d85e9cf3a7122f49108"</span>
  needs = [<span class="string">"Filter for tag"</span>]
  args = <span class="string">"tag &lt;project-name&gt; &lt;docker-hub-username&gt;/&lt;project-name&gt;:latest"</span>
}

# <span class="type">Automatically</span> push the image tagged latest to <span class="type">Docker Hub</span>
action <span class="string">"Push Docker image with latest"</span> {
  uses = <span class="string">"actions/docker/cli@8cdf801b322af5f369e00d85e9cf3a7122f49108"</span>
  needs = [<span class="string">"Tag Docker Image with latest"</span>]
  args = <span class="string">"push &lt;docker-hub-username&gt;/&lt;project-name&gt;:latest"</span>
}

# <span class="type">Create</span> a release <span class="type">ZIP</span> archive and add it to the repository
action <span class="string">"Archive release"</span> {
  uses = <span class="string">"lubusIN/actions/archive@master"</span>
  needs = [<span class="string">"Filter for tag"</span>]
  env = {
    <span class="type">ZIP_FILENAME</span> = <span class="string">"&lt;project-name&gt;"</span>
  }
}
</code></pre><p>That was a lot to digest, so let’s take a look at the actions in this workflow. The workflow is trigged by any push to the repository. The first action filters out all pushes other than those to the master branch. It then attempts to login to Docker Hub using the credentials you have supplied as secrets.</p><p>Once authenticated, an action builds a Docker image, another tags it and yet another pushes it to Docker Hub. The next action is a filter, it checks if the push to the master branch was tagged as a release. If the push was a release then the next action tags the Docker image as latest and another pushes it to Docker Hub. Finally, an action zips the source code up and publishes it to the release page on GitHub.</p><p>To see all of this in action, commit the <code>main.workflow</code> file to the repository. Navigating to the actions tab should now show any in-progress builds as well as historical ones:</p><img src="https://jimlearning.github.io/images/posts/github-actions-run-results.jpg" alt="Git hook screenshot"/><h2>References</h2><ul><li><a href="https://martinfowler.com/bliki/ContinuousDelivery.html        "Martin Fowler - Continuous Delivery"">Martin Fowler - Continuous Delivery</a></li></ul>]]></content:encoded></item></channel></rss>