依存リポジトリ管理でのsubmodule/subtree/subrepoの使い分け - Qiita
依存ライブラリを利用する場合RubyGemsやらCocoaPodsといったツールで万事解決するケースがほとんどだと思いますが、たまーにGitに上がっているライブラリを直接自分のリポジトリに追加しないといけない場合もあったりします。 こういった時に使うGitのサブコマンドそれぞれの特徴と使いどころをまとめてみました。 一番スタンダードな外部リポジトリ追加方法です。たぶん大抵の依存管理ではこれを使えば十分でしょう。git-submoduleを利用すると、外部リポジトリのコード自体は自プロジェクトの管理下に取り込まれず、リポジトリの特定コミットへの参照情報のみが登録されます。外部リポジトリのcommit hashへのポインタが追加されるようなイメージです。 $ git submodule add git@github.com:Alamofire/Alamofire.git $ git diff
ブランチ名にissue番号を使う - Qiita
仕事ではタスク管理にGithub issueを使っていて、最近はブランチを作る際にfeature/1234といったように名前にissue番号を使うようにしています。最初はどのissueに関連したブランチなのか分かりやすくしたくて始めたんですが、CLIツール・alias設定を組み合わせて以下のフローも楽に行えるようになりました。 テンプレートを使ってissueリンク付きプルリクエストを作る プルリクエストを作成する際は必ず対応するissueへのリンクを貼るという運用を行っているんですが、ブランチ名にissue番号を入れておくことでこれがコマンド一発で完結できるようになりました。やり方は下記の記事を参考にさせてもらいました。 GitHub Issueはテンプレート化で、綺麗に書かせる！ - Qiita [alias] pull-request = "!hub browse -- compare
Githubの特定ブランチにpushした時だけhookでjenkinsビルドする - Qiita
hookを使ってるとリポジトリへpushしてすぐにjenkinsをビルドできて便利だけど、どのブランチにpushしてもhook URLが呼ばれてちょっと不便。 例えばdevelopブランチにpushされた時だけ、hookでdevelopのビルドジョブを実行する、みたいな事がやりたくて調べてみた。 やり方 自前のgitリポジトリだと.git/hooksで特定ブランチへのpush時だけhookする設定が書けるけど、Githubでは同じような事ができないので Jenkins側で受け取ったhookがどのブランチへのpushによるものかを判定してみる。手順は以下のとおり。 hook受取り用ジョブの作成 ビルドジョブとは別でGithubからhookを受け取る専用のジョブを用意しておく。 ジョブはパラメータ付きビルドにしておき、下のように payload という名前でパラメータを受け取れるようにする。デ
zshの履歴でコマンド実行時刻を見れるようにする - Qiita
historyコマンドで-dを指定するとコマンドを実行した時刻が表示できる。年月日も見たい場合は-f。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
