gitでローカルブランチにmasterなんて（普通は）要りません - Qiita
理由 GitHubやGitLabなどのおかげで、リモートで直接masterにマージできるようになった。 どうしても、という時以外ローカルのmasterブランチで作業する必要はないはずです。 間違えてmasterを壊してしまうリスクが更に減る ローカルのmasterブランチをメンテするコストが減る 地味なメリットに聞こえるかもしれませんが個人的にはありがたいので最後のものを詳しく説明します。 Gitの仕様上、ローカルのmasterブランチはリモートのmasterブランチを更新しても自動的には更新されません。 現状、git checkout masterしてからgit pullしないと更新できないはずです（他にも方法はありそうな気がしますが割愛します）。 この方法、一瞬でもmasterにチェックアウトしなければならないため、チェックアウトする前のブランチとローカルのmasterの差が大きい場合
dockerのコンテナの自動起動をsystemdにて行う際の注意点について
Dockerコンテナの自動起動（ホストOS起動時にDockerコンテナを自動的に起動する）を行う場合、通常はDockerコンテナに設定する再起動ポリシー（restart policy）を利用していると思います。 再起動ポリシーは、Dockerデーモンが起動した際の各Dockerコンテナのふるまいを定義します。これを利用することでDockerコンテナを自動的に起動させることが可能です。 しかし、お使いのLinuxがSystemdを使ってシステムを管理するディストリビューションである場合、サーバで稼働するサービスはSystemdを使って各種管理を行うことが多いと思います。 その場合、Dockerコンテナで提供しているサービスもSystemdで起動停止したいと思われている管理者の方がいらっしゃるかもしれません。 Docker公式サイトで調べたところ、その方法が載っていましたので早速試してみました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
