Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の3つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる!massageじゃない、messageだ!マッサージを作ってどうする! 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
このエントリでは、Gitが提供するマージのための機能の内、主なもの4つ、真のマージ、リベース、ファストフォワードマージ、チェリーピック について図解する。 ここでマージとは、とあるブランチのコミットが入れた修正を別のブランチに取り込むこととする。 この記事を事前に読んでGitのオブジェクトモデルを理解しておくと分かりやすいかもしれない。 ここで説明するマージは全てローカルリポジトリ内のブランチを操作対象とする。 真のマージ 真のマージは、複数のブランチでそれぞれ開発が進んでいて、つまりそれぞれのコミットグラフが伸びている場合に、それらの修正を統合するときに実行する。 マージするブランチはいくつでも指定できる。 基本的なコマンドはgit merge <ブランチ(複数可)>。 操作に成功すると、マージ後のプロジェクトの状態を表すコミット(マージコミット)が作られ、カレントブランチの先頭に追加さ
最初に なんとなくでも使用できるGitですが実はとても奥深く複雑な構造をしています。 そんなGitを使い始めた時ほぼ全員が思う「HEAD」とは何者なのか説明したいと思います。 また合わせて「Branchとは」「detached HEADとは」についても話します。 先に結論ファーストで話しますと 今自分が作業している場所を示すポインタ Branchとは 開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機能 detached HEADとは HEADがBranchを指していない状態のこと そして僕自身以前までブランチとはなにか聞かれた場合、下図のようなイメージを持っていました。 そしてこれは誤った認識です。 この記事はMake IT アドベントカレンダー9日目の記事として寄稿しています! 明日は @wh1tecat が投稿する予定です。 楽しみですね(笑) Branchとは まずG
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
会社でRedisを使っているサービスがあり、そのメンテナーになった。RedisがIn-Memory Databaseということは知っていたのだが、その他の特徴や操作方法などまったくわからないので、チュートリアルを中心に手を動かしながら学んだことをまとめていく。またNode.jsからRedisにアクセスする方法もあわせて紹介する。 Redis の特徴 Redisはメモリー上にデータを保存するKey-Value型のNoSQLデータベースのひとつ。用途はデータベースだけにとどまらず、キャッシュやメッセージブローカーとしても利用される。 In-Memory Database RedisはIn-Memory Databaseなので、On-Disk Databaseと比べ非常に高速に動作する。ちなみにIn-Memory DatabaseとOn-Disk Databaseの違いは以下のとおり。 インメモ
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
この記事を読んだ、またはGitのオブジェクトモデルを理解していることを前提に、Gitの git rebase というコマンドについて説明する。 このコマンドは、コミット履歴を改変できるGit特有のコマンドで、分かり辛いGitコマンドの中でも最も分かり辛い部類のものだ。 Gitの最後の関門と言えよう。 けど、それだけに使いこなせばとても便利なものでもある。 git rebaseがもつたった一つの機能 git rebaseにはいろんなオプションがあって、ちょっと調べただけだと、コミットを移動する機能とコミットを修正する機能の二つがあるように見えるかもしれないが、実際は単一の機能しかないシンプルなコマンドだ。 その機能とは、指定した範囲のコミットが含む変更を、別に指定したコミットのコードベースに適用するというもの。 コマンドの基本形は次のようなものだ。 このコマンドは、bugfixから辿れるコミ
git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
こちらはラスベガスで開催された AWS re:Invent2019のセッション The right AWS network architecture for the right reason #NET320 のレポートです。 Transit Gateway/PrivateLink などの新サービス登場や 既存サービスのアップデートとともに、 AWSにおけるネットワーク構成の選択肢は増え続けています。 本セッションは、今のAWSにおけるネットワーク構成が網羅されている 良いセッションでした。 本ブログでは、このセッションで出てきた AWSネットワークアーキテクチャ パターンを紹介 していきます。 資料 セッション動画 目次 項目が多いので以下に目次を作成しています。 目次のリンクから気になるアーキテクチャを参照ください。 シングルVPC、マルチVPC フラットネットワーク アーキテクチャ (
この記事は MERPAY TECH OPENNESS MONTH の 13日目の記事です。 こんにちは、メルペイ ソフトウェアエンジニアの laughngman7743 です。 メルペイではマイクロサービスにおけるデータストアのデータや、アプリケーションのログを有効活用できるような基盤づくりをデータプラットフォームチームとして行っています。 データプラットフォームではラムダアーキテクチャに基づき、スピードレイヤとして Cloud PubSub と Cloud Dataflow を利用した仕組みに加え、バッチレイヤとして Cloud Composer と Cloud Dataflow を利用した仕組みを構築しています。 この記事ではバッチレイヤのアーキテクチャについてご紹介します。 スピードレイヤのアーキテクチャについては 「GCPでStreamなデータパイプライン始めました」 を参照くださ
Cityカラムが英語表記へ統一 Temperatureカラムは摂氏(℃)へ統一 Dateのカラムは、タイムゾーンをUTCに固定し、YYYY-MM-DDフォーマットへ こうしてDataが整理されてInformationになることで、「最高気温を比較すると、UTC 11月15日の時点ではPalo Altoの方が高かったが、12月5日の時点では東京の方が高かった」といった事実を見ることができるようになります。このInformationから導き出される傾向や規則性を導出されたものが、DIKWピラミッドにおけるKnowledgeになります。そして頂点であるWisdomは、導き出されたKnowledgeに基づいて人により下される判断のことそのものを示します。 Data Engineeringの仕事は、このDataを過不足無く蓄えること、DataからInformationへの変換・蓄積する作業がメインと
LINEを支えるプロジェクトマネジメント&アジャイルの専門家組織「Effective Team and Delivery室」の取り組みと戦略 Project Management & Agile全社横断組織の戦略と事例 #1/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Project Management & Agile全社横断組織の戦略と事例」に登壇したのはLINE Effective Team and Delivery室 室
GCPで完結させたゲームプラットフォームのアーキテクチャ 開発期間は短くしつつ、自由度を失わないための工夫 これが新しいデザインパターン - mspoを支えるGCP&Looker 2019年11月18日、グーグル・クラウド・ジャパン合同会社にて「第9回 Google Cloud INSIDE Games & Apps」が開催されました。ゲーム業界で活躍するインフラ、サーバーアプリケーションエンジニア、テクニカルリーダーを対象に開催される本イベント。今回は、GCPを活用するさまざまな企業が集まり、最新の活用事例を語りました。プレゼンテーション「これが新しいデザインパターン - mspoを支えるGCP&Looker」に登壇したのは、アイレット株式会社代表取締役社長の齋藤将平氏と、ガンホー・オンライン・エンターテイメント株式会社CTOの菊池貴則氏。ガンホーの子会社であるmspo株式会社
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く