Seleniumのインストール（python:3-slimベース）

ChromiumとWebDriverをインストールする

インストールするChromiumとChromeDriverのバージョンは極力近いものをインストールする必要がある。
ChromeDriverのインストールはPythonのchromedriver-binaryモジュールを使う。

• ChromeDriver - WebDriver for Chrome
• chromedriver-binary

1
2
3
4
5

RUN apt-get update -y && \
    apt-get install -y --no-install-recommends chromium && \
    pip install --upgrade pip setuptools wheel && \
    # webdriverはなるべく近いバージョンをダウンロード
    pip install chromedriver-binary~=$(chromium --version | perl -pe 's/([^0-9]+)([0-9]+\.[0-9]+).+/$2/g')

Chromeのインストールパスの問題

Chromeのインストールパスはwebdriver.Chrome()で指定する必要がある。
指定していない、下記のコードではエラーとなる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

from selenium import webdriver

def test_access(driver):
    driver.get('https://www.google.com')
    driver.save_screenshot('test.png')
    print(driver.title)
    driver.quit()

if __name__ == '__main__':
    options = webdriver.ChromeOptions()
    options.add_argument("--headless")
    options.add_argument("--no-sandbox")
    driver = webdriver.Chrome(options=options)
    test_access(driver)

実行結果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$python sample_test.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/selenium/webdriver/common/service.py", line 72, in start
    self.process = subprocess.Popen(cmd, env=self.env,
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'chromedriver'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "sample_test.py", line 13, in <module>
    driver = webdriver.Chrome(options=options)
  File "/usr/local/lib/python3.8/site-packages/selenium/webdriver/chrome/webdriver.py", line 73, in __init__
    self.service.start()
  File "/usr/local/lib/python3.8/site-packages/selenium/webdriver/common/service.py", line 81, in start
    raise WebDriverException(
selenium.common.exceptions.WebDriverException: Message: 'chromedriver' executable needs to be in PATH. Please see https://sites.google.com/a/chromium.org/chromedriver/home

chromedriver_binaryでインストールしている場合、import chromedriver_binaryを追加すれば、でChromiumのインストールパスが解決される。

日本語フォントの問題

実行結果の画面キャプチャは文字化けしている

localeの設定と日本語フォントのインストールすれば文字化けは解消する

1
2
3
4
5
6
7

ENV LANGUAGE ja_JP.UTF-8
ENV LANG ja_JP.UTF-8
RUN apt-get install -y --no-install-recommends locales && \
    locale-gen ja_JP.UTF-8 && \
    # 日本語フォントをインストール
    apt-get install -y --no-install-recommends fonts-ipafont && \
    echo "*** INSTALLED: ja_JP locale & font ***"

Selenium Container（python:3-slimベース）のコンテナイメージ例

Dockerfile

python:3-slimベースのSelenium/Chromium環境

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

FROM python:3-slim
# Chrome & Webdriver
RUN apt-get update -y && \
    apt-get install -y --no-install-recommends chromium && \
    pip install --upgrade pip setuptools wheel && \
    pip install selenium && \
    # webdriverはなるべく近いバージョンをダウンロード
    pip install chromedriver-binary~=$(chromium --version | perl -pe 's/([^0-9]+)([0-9]+\.[0-9]+).+/$2/g')

# 日本語環境
ENV LANGUAGE ja_JP.UTF-8
ENV LANG ja_JP.UTF-8
RUN apt-get install -y --no-install-recommends locales && \
    locale-gen ja_JP.UTF-8 && \
    # 日本語フォントをインストール
    apt-get install -y --no-install-recommends fonts-ipafont

テストコード

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

from selenium import webdriver
import chromedriver_binary

def test_access(driver):
    driver.get('https://www.google.com')
    driver.save_screenshot('test.png')
    print(driver.title)
    driver.quit()

if __name__ == '__main__':
    options = webdriver.ChromeOptions()
    options.add_argument("--headless")
    options.add_argument("--no-sandbox")
    options.add_argument("--window-size=1224,844")
    driver = webdriver.Chrome(options=options)
    test_access(driver)

実行結果

1
2
3
4

PS > docker-compose run selenium-dispshell bash
root@8dc58c2f02c2:/# cd /app
root@8dc58c2f02c2:/app# python sample_test.py
Google

コメント・シェア

DevOps Trend

• DevOps and Cloud InfoQ Trends Report - February 2019
• DevOps and Cloud InfoQ Trends Report - February 2019 (ja)

Late Majority

CIやIaC、Containerなど主要なものはすでにLate Majority扱いになっている。

• Generals DevOps
• Containers
• Infrastructure as Code
• Continuous Integration tooling

Early Majority

Immutable infrastructureを基にしたContainer orchestration、Continous Delivery、Deploymentキーワードが挙げられている。

• Continuous Delivery (CD)
• CD for mobile
• Immutable infrastructure
• Feature flags & blue/green-deployments
• Centralized log aggregation
• Container orchestration
• Enterprise DevOps toolchain

Early Adapters

CI/CDをより高度にしたキーワードが挙げられている。

• Continuous Testing
• Chaos engineering practices
• Cloud: FaaS, BaaS
• ChatOps
• GitOps/DiffOps

Service meshes

クラウドを抽象化したアプリ実行基盤としてKubernetesがデファクトになりつつあるが、PaaSとしては不十分なため、効果的なCI/CDのためService meshesが注目されている。

Kubernetes has well and truly cornered the domain of container orchestration, and is arguably becoming the default cloud-agnostic compute abstraction. However, Kubernetes is not a complete Platform-as-a-Service (PaaS), which is arguably what most organisations require for effective deployment and operation of software, and so the next “hot topics” in this space appear to be “service meshes” for managing interservice communication and release control, and developer experience and workflow tooling to allow engineers to implement effective dev-test-deploy-observe cycles.

Chaos engineering

Netflixの事例やO’REILLYの書籍によってカオスエンジニアリングも勢いがある。

• Presentation: UNBREAKABLE: Learning to Bend but Not Break at Netflix
• O’REILLY Chaos Engineering
• Chaos Engineering Experiment Automation
• Gremlin

We believe that the topic of chaos engineering has moved into early adopter, largely due to the increased promotion by the Netflix team and the O’Reilly Chaos Engineering book authors, and tooling such as the Chaos Toolkit and Gremlin’s as-a-service offerings. Based on discussions with John Allspaw, Casey Rosenthal, Nora Jones and other members of the community, we have separated out the topic of “resilience engineering”, which we have previously conflated with chaos engineering, and placed this within the innovator category.

DevOps Tool Chain

XebiaLabsのPERIODIC TABLE OF DEVOPS TOOLS

元素周期表のデザインでDevOpsのTool Chainを表現している。

• XebiaLabs PERIODIC TABLE OF DEVOPS TOOLS

DevOpsのTool Chainとしている領域は以下

• Source Control Management
• Database Automation
• Continuous Integration
• Testing
• Configuration
• Deployment
• Containers
• Release Orchestration
• Cloud
• AIOps
• Analystics
• Monitoring
• Security
• Collaborations

SANS Secure DevOps Toolchain and SWAT Checklist

DevSecOps関連のTool Chain。

• SANS Secure DevOps Toolchain and SWAT Checklist

コメント・シェア

Shift-Left & Shift-Rightアプローチ

Shift-LeftとShift-Right

• How DevOps Teams Can ‘Shift Left’ and Shift Right’ Their Way to an Effective Continuous Development Model

Shift-Leftはソフトウェアのデリバリーチェイン（端的に言えばCI/CDパイプライン）の早い段階（より左）で特定のプロセスを実行すること。多くの文脈でテストやセキュリティの事を指しているが、どんなプロセスでも適用できる。

Put simply, shift left refers to the concept of performing a given process earlier in the software delivery chain.
When you hear people talking about the shift-left concept today, they’re usually discussing either software testing or IT security.
However, the shift-left idea can be applied to any type of process that occurs within the delivery chain. Data management, software monitoring and even software marketing could be moved to the left, too.

Shift-Rightはソフトウェアのデリバリーチェインの遅い段階（より右）で特定プロセスを実行すること。アプリケーションのリリース前にリリース後の問題を把握するために行う。

As you might imagine, shifting processes to the right means performing them later in the delivery pipeline. In many cases, this specifically means taking processes that typically happen before application release and moving them into production, to help you catch post-release issues before end users notice them.

テストやセキュリティなどのコアソフトウェア配信プロセスを継続実施することが重要。

Shift-left and shift-right are both valuable concepts, but DevOps teams should not embrace them in isolation. Instead, think of shift-left and shift-right as steps that you can take to make core software delivery processes like testing and security continuous across your pipeline. Continuity is the real goal.

Shift-Left Testing

テストにおけるShift-Leftという単語は適切でないという指摘。

• Shift Left – Why I Don’t Like the Term

I think the first time I heard the term was in a talk by Paul Gerrard – perhaps a webinar for EuroStar in 2014. In the notes I made at the time, I have this sentence “
Shift Left ??? – redistributing test activities … same thing we have been saying … why is he calling it shift left? I don’t understand this at all.”

Shift-Leftという単語は開発プロセスが直線的なプロセスの様に感じらるので、コンセプトが誤解されるのではないか？コンセプトに合うのは継続的/全体的テスト（Continuously/Holistic testing）*

What I fear may happen using the term ‘shift-left’, is that some people will misunderstand the concept and go back to big upfront requirements that need to be tested before coding is even started. Shift-left also doesn’t include the idea of DevOps, so people have started saying shift-right, or shift-outwards.
I personally think better terms are testing continuously or holistic testing, taking into account whatever your context may be.

Continuous Testing

DevOpsのあらゆる場所でテストはあるという指摘。

• Continuous Testing in DevOps…

Shift-Right Testing

リリース前だけでなくリリース後の本番環境でのテストも含めてShift-Rightであり、以下の項目が例として挙げられている。

• release validation（リリースの検証）

• destructive/chaos testing（破壊的テスト、カオステスト）

• A/B and canary testing（A/Bテスト、カナリアテスト）

• CX-based testing（カスタマーエｋスペリエンステスト）

• crowd testing（クラウドソーシングテスト）

• production monitoring（本番モニタリング）

• extraction of test insights from production data（本番データからのテスト項目の抽出）

• Shift-Right Testing: The Emergence of TestOps

Shift-right entails doing more testing in the immediate pre-release and post-release phases (i.e. testing in production) of the application lifecycle. These include practices such as: release validation, destructive/chaos testing, A/B and canary testing, CX-based testing (e.g. correlating user behavior with test requirements), crowd testing, production monitoring, extraction of test insights from production data, etc.
Shift-right not only introduces such new testing techniques, but also requires testers to acquire new skills, make aggressive use of production data to drive testing strategies and collaborate with new stakeholders, such as site reliability engineers (SRE) and operations engineers.

CXは、カスタマーエフォートスコア（CES）、ネットプロモータースコア（NPS）、カスタマー満足度スコア（CSAT）などのさまざまなメトリックを使用して測定する。これらはある程度Shift-Leftも可能だが、ほとんどは本番稼働中のシステムからの測定になる。

Unlike classic testing, this takes into account real-world users and their experiences. An application with perfect traditional quality scores (such as FURPS) may still suffer from poor CX if it fails to delight the customer. CX is measured using various metrics such as Customer Effort Score (CES), Net Promoter Score (NPS), Customer Satisfaction Score (CSAT), etc. While it is possible to shift-left some of these measurements to some degree, most CX measurements are deduced from systems in production (or close to production).

TestOps

The Emergence of TestOps

TestOpsは単純にShift-Rightの事をではなく、可能なものはShift-Leftした継続的なテストを指す。

• Shift-Right Testing: The Emergence of TestOps

Though the term TestOps (like all the X-Ops sub-disciplines within DevOps) implies the collaboration between testing and operations, it isn’t simply about shift-right. Why? Because with DevOps, operational disciplines themselves have shifted left (such as shift-left of monitoring, configuration management, SRE, etc.). Hence TestOps—true to the principle of continuous testing—refers to better collaboration with operations disciplines across the DevOps lifecycle.

TestOps Shift-Left

アーキテクチャや構成リソースなど本番環境を使ったテストに近い内容もShift-Leftされる。

• Architecture quality（アーキテクチャの品質）
  • Scalability analysis（スケーラビリティの静的分析）
  • Performance/stress testing（パフォーマンステスト）
  • Reliability testing & analysis（信頼性テストと分析）
  • Maintainability（メンテナンス性）
• Configuration quality（構成リソースの品質）
  • Configs “as-code”（コード化された構成リソース）
  • Unit test configurations（構成リソースのユニットテスト）
  • Equivalence testing（同等性テスト）
  • Rollback testing（ロールバックのテスト）
• Early Monitoring（早期の監視）
  • Unit test monitoring configs（監視リソースのテスト）
  • Monitoring in test（テストの監視）

TestOps Shift-Right

よりユーザ利用に近い領域がShift-Rightの対象になっている。

• Chaos Engineering（カオスエンジニアリング）
  • Contolled failure simulation（制御された障害シナリオの挿入によるシステムの信頼性のテスト）
  • Reliability analysis（信頼性分析）
• A/B and Canary Tests & Synthetic Transactions（A/Bテスト、カナリアテスト、Synthetic Transactions）
  • Testing in prod（本番環境でのテスト）
  • Rollback testing（ロールバックテスト）
  • User simulations（トランザクションのエミュレーション）
  • Tests as monitoring probes（監視プローブによるテスト）
• Predictive Ops Insight（ユーザの行動予測）
  • Extract test intelligence from prod data（本番データからのテスト知見の抽出）
  • CX analystics（カスタマーエクスペリエンスの分析）

コメント・シェア

ドラッグ＆ドロップで引数を渡してプログラムを実行するバッチファイル

実行したいプログラムのあるフォルダーに以下の様なバッチファイルを作成し、そのショートカットをデスクトップに作成。

1
2
3
4

cd /d %~dp0
実行したいプログラム %*
cd
pause

引数に渡すファイルをショートカットにドロップすることで、対象のプログラムに引数を渡して実行できる。

バッチパラメーター

バッチファイルのパラメーター処理は call /? で確認することができる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

C:\Users\<user>>call /?
バッチ プログラムを別のバッチ プログラムから呼び出します。

CALL [ドライブ:][パス]ファイル名 [バッチパラメーター]

  バッチパラメーター   バッチ プログラムで必要なコマンド ライン情報を指定します。

コマンド拡張機能を有効にすると、CALL は次のように変更されます:

CALL コマンドは、CALL のターゲットとしてラベルを受け付けるようになります。
構文は、次のとおりです:

    CALL :ラベル 引数

指定された引数で新しいバッチ ファイル コンテキストが作成され、指定
されたラベルの次の文に制御が渡されます。バッチ スクリプト ファイルの
最後に 2 回到達することによって、2 回 "終了" する必要があります。
1 回目に最後に到達したときには、制御は CALL 文の次の行に返されます。
2 回目に、バッチ スクリプトが終了します。バッチ スクリプトから "戻る"
ための GOTO :EOF 拡張機能の説明については、GOTO /? と入力してください。

また、バッチ スクリプトの引数参照 (%0、%1 など) の展開は、次のように
変更されました:


    %* バッチ スクリプト内では、すべての引数 (%1、%2、%3、%4、
        %5 など) を参照します。

    バッチ パラメーター (%n) の置換は拡張されました。次のオプション構文
    を使うことができます:

        %~1         - すべての引用句 (") を削除して、%1 を展開します。
        %~f1        - %1 を完全修飾パス名に展開します。
        %~d1        - %1 をドライブ文字だけに展開します。
        %~p1        - %1 をパスだけに展開します。
        %~n1        - %1 をファイル名だけに展開します。
        %~x1        - %1 をファイル拡張子だけに展開します。
        %~s1        - 展開されたパスは、短い名前だけを含みます。
        %~a1        - %1 をファイル属性に展開します。
        %~t1        - %1 をファイルの日付/時刻に展開します。
        %~z1        - %1 をファイルのサイズに展開します。
        %~$PATH:1   - PATH 環境変数に指定されているディレクトリを検索し、
                       最初に見つかった完全修飾名に %1 を展開します。
                       環境変数名が定義されていない場合、または
                       検索してもファイルが見つからなかった場合は、
                       この修飾子を指定すると空の文字列に展開されます。

    修飾子を組み合わせて、複合結果を得ることもできます:

        %~dp1       - %1 をドライブ文字とパスだけに展開します。
        %~nx1       - %1 をファイル名と拡張子だけに展開します。
        %~dp$PATH:1 - PATH 環境変数に指定されているディレクトリを
                       検索して %1 を探し、最初に見つかったファイル
                       のドライブ文字とパスだけに展開します。
        %~ftza1     - %1 を DIR の出力行のように展開します。

    上の例の %1 と PATH は、他の有効な値で置き換えることができ
    ます。%~ 構文は有効な引数の数によって区切られます。%~ 修飾子
    は %* と同時には使用できません。

バッチファイルの挙動

ドラッグ元とドロップ先のパスを展開する

%0 にはドロップされるバッチファイルのフルパス、%1 にはドロップするファイルのフルパスが入る。
%~dp0 にはバッチファイルの存在するフォルダーのフルパス、%~dp1 はドロップするファイルのフルパスが入る。

1
2
3
4
5

echo %0
echo %~dp0
echo %1
echo %~dp1
pause

1
2
3
4
5
6
7
8
9
10
11
12
13
14

C:\Users\<USER>\Desktop>echo "C:\Users\<USER>\Desktop\test.bat"
"C:\Users\<USER>\Desktop\test.bat"

C:\Users\<USER>\Desktop>echo C:\Users\<USER>\Desktop\
C:\Users\<USER>\Desktop\

C:\Users\<USER>\Desktop>echo C:\Users\<USER>\Desktop\test.txt
C:\Users\<USER>\Desktop\test.txt

C:\Users\<USER>\Desktop>echo C:\Users\<USER>\Desktop\
C:\Users\<USER>\Desktop\

C:\Users\<USER>\Desktop>pause
続行するには何かキーを押してください . . .

ドロップ先のパスに移動してから実行する

%~dp0 でドロップ先のフォルダーに移動する。
%* は %1 以降のパラメーターを示している。

1
2
3
4

cd /d %~dp0
echo %*
cd
pause

1
2
3
4
5
6
7
8
9
10

C:\Users\<USER>\Desktop>cd /d C:\Users\<USER>\Desktop\

C:\Users\<USER>\Desktop>echo C:\Users\<USER>\Desktop\test.txt
C:\Users\<USER>\Desktop\test.txt

C:\Users\<USER>\Desktop>cd
C:\Users\<USER>\Desktop

C:\Users\<USER>\Desktop>pause
続行するには何かキーを押してください . . .

バッチファイルのショートカットにドロップした場合

バッチファイルがC:\workにあり、デスクトップ上に作成したショートカットへドロップした場合。
%0 はバッチファイルの場所を指す。

1
2
3
4
5
6
7
8
9
10

C:\work>cd /d C:\work\

C:\work>echo C:\Users\<USER>\Desktop\test.txt
C:\Users\<USER>\Desktop\test.txt

C:\work>cd
C:\work

C:\work>pause
続行するには何かキーを押してください . . .

コメント・シェア

The “Works on My Machine” Certification Program

さぁ、あなたもこれで”Works on My Machine”認証をとろう

• The “Works on My Machine” Certification Program

1. Compile your application code. Getting the latest version of any recent code changes from other developers is purely optional and not a requirement for certification.
2. Launch the application or website that has just been compiled.
3. Cause one code path in the code you’re checking in to be executed. The preferred way to do this is with ad-hoc manual testing of the simplest possible case for the feature in question. Omit this step if the code change was less than five lines, or if, in the developer’s professional opinion, the code change could not possibly result in an error.
4. Check the code changes into your version control system.

認定Developerの声

そりゃ動かないことだってあるさ　でも俺のマシンでは動いたんだ

動かないことだってあります

“俺のマシンでは動いた”なんて簡単には言わないよ

言いたいことも言えない……

私のマシンでは動いたのよ、顧客の問題ね

そう顧客の問題

Devでは快適だったわ、Opsの問題ね

そりゃ運用が悪いに決まっています

私のマシンでは動いた！さぁ本番に行こうか

決断の時

ありえない！僕のマシンでは動いたんだ

ありえないなんて事はありえない

・・・ああ我々が君のマシンで動かすよ　―Dockerの誕生である

キミのためにDockerは生まれた

ぼくのコンテナーでは動いたんだ

美しいDevOpsの世界

turnoff.us

もう一度言ってみろ・・・

言えるものならな！

Pulp Fiction (1994) “Say what again! I dare you, I double dare you”

コメント・シェア

Magic Quadrant for Cloud IaaS

WorldWide

• Amazon AWS, Google Cloud, Alibaba Cloud and now Microsoft Azure – Why does Salesforce want to run its software on all of them?

Japan

• 日本におけるクラウドIaaSのマジック・クアドラント

マーケットシェア

AWS、Azure、GCPへの集約が進んでいる。

• canalys Global could infrastructure market Q4 2019 and full year 2019

主要プロバイダーに集約が進む

• Amazon, Microsoft, Google and Alibaba Strengthen their Grip on the Public Cloud Market

過去10年間のエンタープライズ系の支出

データセンターは停滞しているが、クラウドの伸びが顕著。

• The Decade’s Megatrends in Numbers – Part 1

過去10年間のエンタープライズ系のSaaSマーケット

SaaSの成長も著しいが、まだソフトウェアマーケットの23%程度。

• The Decade’s Megatrends in Numbers – Part 2

コラボレーションツール

コラボレーションツールもオンプレミスは停滞～減少方向で、クラウドの利用が増加。

• The Decade’s Megatrends in Numbers – Part 3

コメント・シェア

Centralized Workflow

• ATLASSIAN Bitbucket Comparing workflows - Centralized Workflow

Subversionの使い方を踏襲する。
中央リポジトリを使用して、プロジェクトへの変更の単一エントリーポイントとして使用する戦略。小規模プロジェクト向け。

• 開発者は中央リポジトリのメインブランチ（たとえばorigin/master）のみ使う

Feature Branch Workflow

• ATLASSIAN Bitbucket Comparing workflows - Git Feature Branch Workflow

すべての機能開発をメインブランチではなく専用のブランチで行う戦略。
このカプセル化により、複数の開発者がメインのコードベースに影響を与えることなく特定の機能開発を行うことができる。
これはプルリクエストの活用にもつながっている。

• 開発者は機能ブランチ（たとえばorigin/issue-xxxxx）をつかう
• 機能（feature）ブランチをメインブランチ（たとえばorigin/master）へpushする

Gitflow Workflow

• A successful Git branching model
• A successful Git branching model (翻訳)
• A successful Git branching model (翻訳)
• ATLASSIAN Bitbucket Comparing workflows - Gitflow Workflow

Feature Branch Workflowを基に厳密なプロジェクトリリースを中心に設計された厳密な分岐モデルを定義したもの。大規模プロジェクト向け。
メインブランチ（master）と開発（develop）を中心にサポートブランチとして機能（feature/topic）ブランチ、リリース（release）ブランチ、メンテナンス（hotfix）ブランチを使う。

• 公式リリース用のmasterブランチ（公式リリース履歴を格納）
• 開発用のdevelopブランチを（機能の統合ブランチ）
• 機能（feature）ブランチはdevelopを親ブランチとして分岐する
• developブランチを公開する場合releaseブランチを作成する（リリース履歴としてmasterにバージョン番号タグで記録）
• リリースが完了したらreleaseブランチはmasterブランチとdevelopブランチにマージさせる
• releaseブランチは機能追加を行わずメンテナンスのみを行うブランチになる
• バグ修正はhotfixブランチとしてmasterから分岐して行い、masterとdevelopにマージする

Forking Workflow

• ATLASSIAN Bitbucket Comparing workflows - Forking Workflow

開発者が独自のリポジトリを持つ戦略。パブリックオープンソースプロジェクト向け。
開発者は独自のリポジトリにpushし、プロジェクトの公式リポジトリはメンテナーのみがpushできる。
公式リポジトリへのマージはプルリクエストを使う。

GitHub flow

• Understanding the GitHub flow
• GitHub Flow

定期的なデプロイが必要なプロジェクト向けの軽量のブランチベースのワークフロー。
Feature Branch Workflowと基本的には変わらないが、メインブランチへのマージはプルリクエストを使う。

• 開発者は機能ブランチ（たとえばorigin/issue-xxxxx）をつかう
• 機能（feature）ブランチをメインブランチ（たとえばorigin/master）へpushするためにプルリクエスト

GitLab flow

• GitLab Flow
• GitLab Flow (翻訳)
• A New Git-Based Workflow

Issue Tracking Systemを統合した仕組み。
GitLab flowは機能（feature）ブランチをマージするたびに本番環境へデプロイすることを想定しているが、環境によってはリリース時間はコントロールできない。
そこで、デプロイしたコードを反映させたproductionブランチを使用する。

• コード変更は必ずIssueとして登録して機能ブランチとリンクする
• GitHub flowのように機能ブランチをつかい開発する
• メインブランチ（master）は開発環境（srtage）へデプロイする
• プリプロダクション環境へのデプロイはメインブランチからpreproductionブランチへのプルリクエストで行う
• プロダクション環境へのデプロイはpreproductionブランチからproductionブランチへのプルリクエストで行う

gitworkflows

• gitworkflows - An overview of recommended workflows with Git
• gitworkflows - An overview of recommended workflows with Git (翻訳)

Git本家推奨のワークフロー。

• 変更は小さな論理的ステップに分割する（git-blameやgit-bisectで調査・解析を容易にする）
• メンテナンスリリース用のmaintブランチ
• 機能リリース用のmasterブランチ
• 機能リリースに向けたトピック安定化のためのテスト用のnextブランチ
• 含めるには時期尚早なコミット用の統合用のpu（proposed updates）ブランチ
• maint -> master -> next -> puの親子関係
• 機能リリースはmasterブランチからトピックブランチを作成する（pu -> next -> masterでマージ）
• メンテナンスリリースはmaintブランチからトピックブランチを作成する（next -> maintでマージ）
• masterブランチはmaintブランチのスーパーセットでなければならない（maint -> masterでマージ）
• 機能リリース統合後、統合用のnextブランチやpuブランチはmasterの先端へと巻き戻し（reset）もとのnext上に生き残っていたトピックブランチを使って再構成（historyがきれいになる）
• 巻き戻しと再構成はnextブランチに関しては関する公式アナウンスをすべき（puブランチは使い捨て）

Trunk Based Development (TBD)

• Trunk Based Development
• Trunk-based Development vs. Git Flow
• Escape from Merge Hell
• DevOps tech: Trunk-based development

各機能を個別のブランチで開発し、安定した後にのみマージするFeature Branchingとは異なりトランクで開発し、リリースごとに分岐を保持するRelease Branchingの戦略。
小規模で頻繁なマージを行うことで、マージの複雑さを軽減し、コードを最新の状態に保つ。

• 各開発者は自分の作業を数時間で終わる程度の小さなバッチに分割
• メインブランチであるトランク（メインライン）にマージは少なくとも1日に1回（場合によっては数回）の頻度で行う
• リリースブランチで行われたバグ修正などはできるだけ早くトランクへマージする
• 小規模で頻繁なマージを行うことで、イベントのマージの複雑さを軽減し、コードを最新の状態に保つ

コメント・シェア

Git

• git –everything-is-local

Git vs centralized source code control systems

• GitSvnComparison

A summary of differences

• GitはSubversionより速い
• Subversionはリポジトリのサブツリーのみチェックアウトできるが、Gitは履歴を含むリポジトリ全体のクローンを作成する
• GitのリポジトリはSubversionよりもはるかに小さい
• Gitは完全分散型で設計されており、開発者はローカルで制御できる
• GitブランチはSubversionのブランチよりシンプルでリソース負担が少ない
• Gitブランチはすべての履歴を持つ
• Gitはブランチおよびマージイベントのより良い監査を提供する
• Gitのリポジトリファイルは壊れにくく、修復も簡単
• Subversionはリポジトリのバックアップが簡単（Gitはリポジトリ内のフォルダーを分散可能なため）
• Gitリポジトリクローンが完全なリポジトリバックアップにできる
• SubversionのUIはGitより習熟している
• Subversionは連番のリビジョン番号を使用するので、バージョンのウォークスルーが簡単（GitはSHA-1ハッシュを使う）

Git’s Major Features Over Subversion

• Distributed Nature
  • ユーザが完全なリポジトリデータのコピーを持つ（Subversionは中央リポジトリしか持たない）
• Access Control
  • 他のユーザにCommitアクセス権を与える必要がない（いつ誰から何をMergeするか）
• Branch Handling
  • Subversionではブランチは扱いにくい
  • Gitのブランチはすべてのユーザが日常的に使用するコアコンセプト
• Performance (Speed of Operation)
  • PushとFetchを除くすべての操作はローカルのため高速
• Smaller Space Requirements
• Line Ending Conversion

コメント・シェア

Pro Git

Git公式で公開されているPro Git。

• Pro Git (en)
• Pro Git (ja)

1.1 Getting Started - About Version Control

Local Version Control Systems

ディレクトリで整理するアプローチは一般的だが、問題も多い。

• RCS

多くの人々が使っているバージョン管理手法は、他のディレクトリ（気の利いた人であれば、日時のついたディレクトリ）にファイルをコピーするというものです。 このアプローチはとても単純なので非常に一般的ですが、信じられないほど間違いが起こりやすいものです。 どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。

Centralized Version Control Systems (CVCs)

中央管理型のバージョン管理システム。

• CVS、Subversion、Perforce

もし中央データベースのあるハードディスクが破損し、適切なバックアップが保持されていなければ、完全に全てを失ってしまいます。プロジェクトの全ての履歴は失われ、残るのは個人のローカル・マシンにたまたまあった幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）ぐらいです。 ローカルVCSシステムも、これと同じ問題があります。つまり、一つの場所にプロジェクトの全体の履歴を持っていると、全てを失うリスクが常にあります。

Distributed Version Control Systems (DVCs)

分散管理型のバージョン管理システム。

• Git、Mercurial、Bazaar、Darcs

あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。 クローンは全て、実際は全データの完全バックアップなのです。

1.3 Getting Started - What is Git

Snapshots, Not Differences

従来のバージョン管理システムはファイルを基本とした変更差分を扱う。

概念的には、他のシステムのほとんどは、情報をファイルを基本とした変更のリストとして格納します。

Gitはコミットの状態をスナップショットとして扱う。このデータ構造の違いがブランチの扱いの違い大きく影響している。

Gitはデータをミニ・ファイルシステムのスナップショットの集合のように考えます。 Gitで全てのコミット（訳注：commitとは変更を記録・保存するGitの操作。詳細は後の章を参照）をするとき、もしくはプロジェクトの状態を保存するとき、Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り（訳者注：意訳）、そのスナップショットへの参照を格納するのです。 効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。 Gitは、むしろデータを一連のスナップショットのように考えます。

Git Has Integrity

SHAで照合されるのでファイル破損を心配しなくていい。

Gitの全てのものは、格納される前にチェックサムが取られ、その後、そのチェックサムで照合されます。 これは、Gitがそれに関して感知することなしに、あらゆるファイルの内容を変更することが不可能であることを意味します。 この機能は、Gitの最下層に組み込まれ、またGitの哲学に不可欠です。 Gitがそれを感知できない状態で、転送中に情報を失う、もしくは壊れたファイルを取得することはありません。

ハッシュ値ベースの管理

Gitはファイル名ではなく、ファイル内容のハッシュ値によってGitデータベースの中に全てを格納しています。

Git Generally Only Adds Data

コミットした内容を変更するのはめんどくさい。

Gitで行動するとき、ほとんど全てはGitデータベースにデータを追加するだけです。 システムにいかなる方法でも、UNDO不可能なこと、もしくはデータを消させることをさせるのは困難です。 あらゆるVCSと同様に、まだコミットしていない変更は失ったり、台無しにできたりします。

The Three States

ローカル操作する上でこのthe Three Statesのイメージを理解する必要がある。

Gitは、ファイルが帰属する、コミット済、修正済、ステージ済の、三つの主要な状態を持ちます。 コミット済は、ローカル・データベースにデータが安全に格納されていることを意味します。 修正済は、ファイルに変更を加えていますが、データベースにそれがまだコミットされていないことを意味します。 ステージ済は、次のスナップショットのコミットに加えるために、現在のバージョンの修正されたファイルに印をつけている状態を意味します。
このことは、Gitプロジェクト（訳者注：ディレクトリ内）の、Gitディレクトリ、作業ディレクトリ、ステージング・エリアの三つの主要な部分（訳者注：の理解）に導きます。

2.2 Git Basics - Recording Changes to the Repository

Recording Changes to the Repository

Tracked/Untrackedも意識しつつ状態のライフサイクルを理解する。

作業コピー内の各ファイルには追跡されている(tracked)ものと追跡されてない(untracked)ものの二通りがあることを知っておきましょう。 追跡されているファイルとは、直近のスナップショットに存在したファイルのことです。これらのファイルについては変更されていない(unmodified)」「変更されている(modified)」「ステージされている(staged)」の三つの状態があります。 追跡されていないファイルは、そのどれでもありません。直近のスナップショットには存在せず、ステージングエリアにも存在しないファイルのことです。 最初にプロジェクトをクローンした時点では、すべてのファイルは「追跡されている」かつ「変更されていない」状態となります。チェックアウトしただけで何も編集していない状態だからです。
ファイルを編集すると、Git はそれを「変更された」とみなします。直近のコミットの後で変更が加えられたからです。変更されたファイルをステージし、それをコミットする。この繰り返しです。

3.1 Git Branching - Branches in a Nutshell

Branches in a Nutshell

コミットを繰返すとポインターが自動的に進んでいく。

最初にコミットした時点で、直近のコミットを指す master ブランチが作られます。その後コミットを繰り返すたびに、このポインタは自動的に進んでいきます。

masterブランチも他と変わらない。慣習的に意味を持つだけ。

Git の “master” ブランチは、特別なブランチというわけではありません。 その他のブランチと、何ら変わるところのないものです。 ほぼすべてのリポジトリが “master” ブランチを持っているたったひとつの理由は、 git init コマンドがデフォルトで作るブランチが “master” である (そして、ほとんどの人はわざわざそれを変更しようとは思わない) というだけのことです。

HEADは現在の作業ブランチへのポインターを意味している。

Git は、あなたが今どのブランチで作業しているのかをどうやって知るのでしょうか? それを保持する特別なポインタが HEAD と呼ばれるものです。 これは、Subversion や CVS といった他の VCS における HEAD の概念とはかなり違うものであることに注意しましょう。 Git では、HEAD はあなたが作業しているローカルブランチへのポインタとなります。 今回の場合は、あなたはまだ master ブランチにいます。 git branch コマンドは新たにブランチを作成するだけであり、 そのブランチに切り替えるわけではありません。

ブランチの切替で作業ディレクトリのファイルも切り替わる。

気をつけておくべき重要なこととして、Git でブランチを切り替えると、作業ディレクトリのファイルが変更されることを知っておきましょう。 古いブランチに切り替えると、作業ディレクトリ内のファイルは、最後にそのブランチ上でコミットした時点の状態まで戻ってしまいます。 Git がこの処理をうまくできない場合は、ブランチの切り替えができません。

3.2 Git Branching - Basic Branching and Merging

Basic Branching and Merging

マージコミットによってブランチを統合する。

単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から新たなスナップショットを作成し、それを指す新しいコミットを自動作成します。 これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。
マージの基点として使用する共通の先祖を Git が自動的に判別するというのが特筆すべき点です。 CVS や Subversion (バージョン 1.5 より前のもの) は、マージの基点となるポイントを自分で見つける必要があります。 これにより、他のシステムに比べて Git のマージが非常に簡単なものとなっているのです。

Basic Merge Conflicts

同じ部分を変更している場合はうまくマージできず、コンフリクトになる。

同じファイルの同じ部分をふたつのブランチで別々に変更してそれをマージしようとすると、Git はそれをうまくマージする方法を見つけられないでしょう。
Git は、標準的なコンフリクトマーカーをファイルに追加するので、ファイルを開いてそれを解決することにします。 コンフリクトが発生したファイルの中には、このような部分が含まれています。

1
2
3
4
5
6
7

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

これは、HEAD (merge コマンドを実行したときにチェックアウトしていたブランチなので、ここでは master となります) の内容が上の部分 (======= の上にある内容)、そして iss53 ブランチの内容が下の部分であるということです。 コンフリクトを解決するには、どちらを採用するかをあなたが判断することになります。 たとえば、ひとつの解決法としてブロック全体を次のように書き換えます。

1
2
3

<div id="footer">
please contact us at email.support@github.com
</div>

このような解決を各部分に対して行い、>>>>> の行をすべて除去します。 そしてすべてのコンフリクトを解決したら、各ファイルに対して git add を実行して解決済みであることを通知します。 ファイルをステージすると、Git はコンフリクトが解決されたと見なします。

補足（Visual Studio Codeのコンフリクト処理）

Visual Studio Codeではコンフリクト状態をどうするか選択の処理が自動挿入される。

3.4 Git Branching - Branching Workflows

Long-Running Branches

慣習的によく使われるdevelopブランチなどのこと。

Git では簡単に三方向のマージができるので、あるブランチから別のブランチへのマージを長期間にわたって繰り返すのも簡単なことです。 つまり、複数のブランチを常にオープンさせておいて、それぞれ開発サイクルにおける別の場面用に使うということもできます。 定期的にブランチ間でのマージを行うことが可能です。

Topic Branches

個別の改修で作成するトピックブランチのこと。

一方、トピックブランチはプロジェクトの規模にかかわらず便利なものです。 トピックブランチとは、短期間だけ使うブランチのことで、何か特定の機能やそれに関連する作業を行うために作成します。 これは、今までの VCS では実現不可能に等しいことでした。 ブランチを作成したりマージしたりという作業が非常に手間のかかることだったからです。 Git では、ブランチを作成して作業をし、マージしてからブランチを削除するという流れを一日に何度も繰り返すことも珍しくありません。

3.5 Git Branching - Remote Branches

Remote Branches

クローンすると自動で origin/master が作成される。master同様 origin に機能的な特別な意味はない。慣習的な物としてはフォークしたプロジェクトのフォーク元として upstream などがある。

リモート参照は、リモートリポジトリにある参照（ポインタ）です。具体的には、ブランチやタグなどを指します。 リモート参照をすべて取得するには、git ls-remote [remote] を実行してみてください。また、git remote show [remote] を実行すれば、リモート参照に加えてその他の情報も取得できます。 とはいえ、リモート参照の用途としてよく知られているのは、やはりリモート追跡ブランチを活用することでしょう。
リモート追跡ブランチは、リモートブランチの状態を保持する参照です。 ローカルに作成される参照ですが、自分で移動することはできません。ネットワーク越しの操作をしたときに自動的に移動します。 リモート追跡ブランチは、前回リモートリポジトリに接続したときにブランチがどの場所を指していたかを示すブックマークのようなものです。
ブランチ名は (remote)/(branch) のようになります。 たとえば、origin サーバーに最後に接続したときの master ブランチの状態を知りたければ origin/master ブランチをチェックします。 誰かほかの人と共同で問題に対応しており、相手が iss53 ブランチにプッシュしたとしましょう。 あなたの手元にはローカルの iss53 ブランチがあります。しかし、サーバー側のブランチは origin/iss53 のコミットを指しています。
Git の “master” ブランチがその他のブランチと何ら変わらないものであるのと同様に、 “origin” もその他のサーバーと何ら変わりはありません。 “master” ブランチがよく使われている理由は、ただ単に git init がデフォルトで作るブランチ名がそうだからというだけのことでした。 同様に “origin” も、git clone を実行するときのデフォルトのリモート名です。 たとえば git clone -o booyah などと実行すると、デフォルトのリモートブランチは booyah/master になります。
手元での作業を同期させるには、git fetch origin コマンドを実行します。 このコマンドは、まず “origin” が指すサーバー (今回の場合は git.ourcompany.com) を探し、まだ手元にないデータをすべて取得し、ローカルデータベースを更新し、origin/master が指す先を最新の位置に変更します。

Pushing

ローカルで作成したブランチはPushでリモートに同期する。

ブランチの内容をみんなと共有したくなったら、書き込み権限を持つどこかのリモートにそれをプッシュしなければなりません。 ローカルブランチの内容が自動的にリモートと同期されることはありません。 共有したいブランチは、明示的にプッシュする必要があります。

Tracking Branches

リモートに紐づいたブランチのこと。

リモート追跡ブランチからローカルブランチにチェックアウトすると、“追跡ブランチ” というブランチが自動的に作成されます(そしてそれが追跡するブランチを`‘上流ブランチ’’といいます)。 追跡ブランチとは、リモートブランチと直接のつながりを持つローカルブランチのことです。 追跡ブランチ上で git pull を実行すると、Git は自動的に取得元のサーバーとブランチを判断します。

Pulling

リモート側の変更を取り込む。

git fetch コマンドは、サーバー上の変更のうち、まだ取得していないものをすべて取り込みます。 しかし、ローカルの作業ディレクトリは書き換えません。 データを取得するだけで、その後のマージは自分でしなければいけません。 git pull コマンドは基本的に、git fetch の実行直後に git merge を実行するのと同じ動きになります。 先ほどのセクションのとおりに追跡ブランチを設定した場合、git pull は、 現在のブランチが追跡しているサーバーとブランチを調べ、そのサーバーからフェッチしたうえで、リモートブランチのマージを試みます。
一般的には、シンプルに fetch と merge を明示したほうがよいでしょう。 git pull は、時に予期せぬ動きをすることがあります。

3.6 Git Branching - Rebasing

Rebasing

リベースでコミットメッセージをきれいにする。

別の方法もあります。 C3 で行った変更のパッチを取得し、それを C4 の先端に適用するのです。 Git では、この作業のことを リベース (rebasing) と呼んでいます。 rebase コマンドを使用すると、一方のブランチにコミットされたすべての変更をもう一方のブランチで再現することができます。
最終的な統合結果には差がありませんが、リベースのほうがよりすっきりした歴史になります。 リベース後のブランチのログを見ると、まるで一直線の歴史のように見えます。 元々平行稼働していたにもかかわらず、それが一連の作業として見えるようになるのです。
リモートブランチ上での自分のコミットをすっきりさせるために、よくこの作業を行います。 たとえば、自分がメンテナンスしているのではないプロジェクトに対して貢献したいと考えている場合などです。 この場合、あるブランチ上で自分の作業を行い、プロジェクトに対してパッチを送る準備ができたらそれを origin/master にリベースすることになります。 そうすれば、メンテナは特に統合作業をしなくても単に fast-forward するだけで済ませられるのです。

The Perils of Rebasing

公開リポジトリにプッシュしたコミットをリベースしてはいけない

Rebase When You Rebase

改変不可派

あなたのリポジトリにおけるコミットの歴史は、実際に発生したできごとの記録 だと見ることもできます。 これは歴史文書であり、それ自体に意味がある。従って、改ざんなど許されないという観点です。 この観点に沿って考えると、コミットの歴史を変更することなどあり得ないでしょう。 実際に起こってしまったことには、ただ黙って 従う べきです。 マージコミットのせいで乱雑になってしまったら? 実際そうなってしまったのだからしょうがない。 その記録は、後世の人々に向けてそのまま残しておくべきでしょう。

履歴整理派

コミットの歴史は、そのプロジェクトがどのように作られてきたのかを表す物語である という考えかたです。 最初の草稿の段階で本を出版したりはしないでしょう。また、自作ソフトウェア用の管理マニュアルであれば、しっかり推敲する必要があります。 この立場に立つと、リベースやブランチフィルタリングを使って、将来の読者にとってわかりやすいように、物語を再編しようという考えに至ります。

中庸派

一般論として、両者のいいとこどりをしたければ、まだプッシュしていないローカルの変更だけをリベースするようにして、 歴史をきれいに保っておきましょう。プッシュ済みの変更は決してリベースしないようにすれば、問題はおきません。

5.1 Distributed Git - Distributed Workflows

Centralized Workflow

リポジトリを共有し、開発者が自分のブランチを作成して平行開発するスタイル。

中央管理型のシステムでは共同作業の方式は一つだけです。それが中央集権型のワークフローです。 これは、中央にある一つのハブ (リポジトリ) がコードを受け入れ、他のメンバー全員がそこに作業内容を同期させるという流れです。 多数の開発者がハブにつながるノードとなり、作業を一か所に集約します。
二人の開発者がハブからのクローンを作成して個々に変更をした場合、最初の開発者がそれをプッシュするのは特に問題なくできます。 もう一人の開発者は、まず最初の開発者の変更をマージしてからサーバーへのプッシュを行い、最初の開発者の変更を消してしまわないようにします。 この考え方は、Git 上でも Subversion (あるいはその他の CVCS) と同様に生かせます。そしてこの方式は Git でも完全に機能します。
また、この例は小規模なチームに限った話ではありません。Git のブランチモデルを用いてひとつのプロジェクト上にたくさんのブランチを作れば、何百人もの開発者が同時並行で作業を進めることだってできるのです。

Integration-Manager Workflow

各開発者がリポジトリを持ち平行開発するスタイル。

Git では複数のリモートリポジトリを持つことができるので、書き込み権限を持つ公開リポジトリを各自が持ち、他のメンバーからは読み込みのみのアクセスを許可するという方式をとることもできます。 この方式には、「公式」プロジェクトを表す公式なリポジトリも含みます。 このプロジェクトの開発に参加するには、まずプロジェクトのクローンを自分用に作成し、変更はそこにプッシュします。 次に、メインプロジェクトのメンテナーに「変更を取り込んでほしい」とお願いします。 メンテナーはあなたのリポジトリをリモートに追加し、変更を取り込んでマージします。そしてその結果をリポジトリにプッシュするのです。

Dictator and Lieutenants Workflow

各開発者がリポジトリを持ち平行開発するスタイルの大規模パターン。

複数リポジトリ型のワークフローのひとつです。 何百人もの開発者が参加するような巨大なプロジェクトで採用されています。有名どころでは Linux カーネルがこの方式です。 統合マネージャーを何人も用意し、それぞれにリポジトリの特定の部分を担当させます。彼らは副官 (lieutenant) と呼ばれます。 そしてすべての副官をまとめる統合マネージャーが「慈悲深い独裁者 (benevalent dictator)」です。 独裁者のリポジトリが基準リポジトリとなり、すべてのメンバーはこれをプルします。

5.2 Distributed Git - Contributing to a Project

Commit Guidelines

コミットメッセージをきれいにする。

コミットメッセージについてのちょっとした注意点をお話しておきましょう。 コミットに関する指針をきちんと定めてそれを守るようにすると、Git での共同作業がよりうまく進むようになります。 Git プロジェクトでは、パッチの投稿用のコミットを作成するときのヒントをまとめたドキュメントを用意しています。Git のソースの中にある Documentation/SubmittingPatches をごらんください。
余計な空白文字を含めてしまわないように注意が必要です。 Git には、余計な空白文字をチェックするための簡単な仕組みがあります。コミットする前に git diff –check を実行してみましょう。おそらく意図したものではないと思われる空白文字を探し、それを教えてくれます。
コミットの単位が論理的に独立した変更となるようにしましょう。 つまり、個々の変更内容を把握しやすくするということです。
すべての変更を同時に追加しさえすれば、一度にコミットしようが五つのコミットに分割しようがブランチの先端は同じ状態になります。あとから変更内容をレビューする他のメンバーのことも考えて、できるだけレビューしやすい状態でコミットするようにしましょう。 こうしておけば、あとからその変更の一部だけを取り消したりするのにも便利です。
最後に注意しておきたいのが、コミットメッセージです。 よりよいコミットメッセージを書く習慣を身に着けておくと、Git を使った共同作業をより簡単に行えるようになります。 一般的な規則として、メッセージの最初には変更の概要を一行 (50 文字以内) にまとめた説明をつけるようにします。その後に空行をひとつ置いてからより詳しい説明を続けます。 Git プロジェクトでは、その変更の動機やこれまでの実装との違いなどのできるだけ詳しい説明をつけることを推奨しています。
メッセージでは命令形、現在形を使うようにしています。 つまり “私は○○のテストを追加しました (I added tests for)” とか “○○のテストを追加します (Adding tests for,)” ではなく “○○のテストを追加 (Add tests for.)” 形式にするということです。 Tim Pope が書いたテンプレート (の日本語訳) を以下に示します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

短い (50 文字以下での) 変更内容のまとめ

必要に応じた、より詳細な説明。72文字程度で折り返します。最初の
行がメールの件名、残りの部分がメールの本文だと考えてもよいでしょ
う。最初の行と詳細な説明の間には、必ず空行を入れなければなりま
せん (詳細説明がまったくない場合は空行は不要です)。空行がないと、
rebase などがうまく動作しません。

空行を置いて、さらに段落を続けることもできます。

  - 箇条書きも可能

  - 箇条書きの記号としては、主にハイフンやアスタリスクを使います。
    箇条書き記号の前にはひとつ空白を入れ、各項目の間には空行を入
    れます。しかし、これ以外の流儀もいろいろあります。

Forked Public Project

フォークの作法。

まずはメインリポジトリをクローンしましょう。そしてパッチ用のトピックブランチを作り、そこで作業を進めます。 このような流れになります。
rebase -i を使ってすべての作業をひとつのコミットにまとめたり、メンテナがレビューしやすいようにコミット内容を整理したりといったことも行うかもしれません。
ブランチでの作業を終えてメンテナに渡せる状態になったら、プロジェクトのページに行って “Fork” ボタンを押し、自分用に書き込み可能なフォークを作成します。 このリポジトリの URL を追加のリモートとして設定しなければなりません。ここでは myfork という名前にしました。
今後、自分の作業内容はここにプッシュすることになります。 変更を master ブランチにマージしてからそれをプッシュするよりも、今作業中の内容をそのままトピックブランチにプッシュするほうが簡単でしょう。 もしその変更が受け入れられなかったり一部だけが取り込まれたりした場合に、master ブランチを巻き戻す必要がなくなるからです。メンテナがあなたの作業をマージするかリベースするかあるいは一部だけ取り込むか、いずれにせよあなたはその結果をリポジトリから再度取り込むことになります。
自分用のフォークに作業内容をプッシュし終えたら、それをメンテナに伝えましょう。 これは、よく「プルリクエスト」と呼ばれるもので、ウェブサイトから実行する (GutHub には Pull request を行う独自の仕組みがあります。詳しくは GitHub で説明します) こともできれば、 git request-pull コマンドの出力をプロジェクトのメンテナにメールで送ることもできます。
自分がメンテナになっていないプロジェクトで作業をする場合は、master ブランチでは常に origin/master を追いかけるようにし、自分の作業はトピックブランチで進めていくほうが楽です。そうすれば、パッチが拒否されたときも簡単にそれを捨てることができます。 また、作業内容ごとにトピックブランチを分離しておけば、本流のリポジトリが更新されてパッチがうまく適用できなくなったとしても簡単にリベースできるようになります。

コメント・シェア

hexo-toc

hexo-tocプラグインを使用する。

• Hexo
• hexo-toc

Install

npm install hexo-toc --save

Configuration

TOCを有効にする

_config.ymlに以下を追記する。

1
2
3
4
5
6
7
8
9

toc:
  maxdepth: 3
  class: toc
  slugify: transliteration
  decodeEntities: false
  anchor:
    position: after
    symbol: '#'
    style: header-anchor

Page configuration

目次をおきたい位置に`

目次

1. hexo-toc
2. Install
3. Configuration
4. Page configuration

`を記述する。

目次サンプル

コメント・シェア