gitに関するbokuwebのブックマーク (5)
-
Git の merge は、﹁2つのブランチの共通の親を探し、そこから merge されるブランチのコミットを順に merge するブランチに適用﹂していくものだ。 では、次のようなときどうするか。 ケース 上の画像において、それぞれのコミットは以下の通りである。S‥分岐元のコミット M, G‥マージコミットR‥マージコミット︵M︶の revert コミット A, B, C, D‥通常のコミット 上記グラフができるまでの流れは、 マージを行う︵Mコミットが作られる︶ 先のマージはまだ早かったと気づき、 revert する︵Rコミットが作られる︶ しばらく経ち、マージしても良くなったので再度マージを行う︵Gコミットが作られる︶ という感じだ。 さて、このときGコミットには、A、B、C、Dの4つのコミットが適用されていて欲しい。 しかし実際には、CとDの2つだけしか適用されない。 なぜなら
-
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowはPR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
-
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか? 今後、この呼び出しを変更したり削除したりしても安全でしょうか? // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
-
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。C言語学習教材としてのGitGitと同じものをゼロから作って何の意味があるのか?と思いますよね。 私がこの再発明をやり始めた動機は﹁C言語を書けるようになりたい﹂でした。 実際に途中までやってみたところ、C言語がチョットデキるようになったGitの内部構造に詳しくなった というメリットが得られました。C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
-
Gitを使ってはいるものの、しっかり理解できていないので分かりやすそうな記事などを集めました。多分同じような感覚の人は少なからずいると思うので参考になれば幸いです。 記事 ︻Git入門者向け︼イメージで理解するGitコマンド事始め | きのこる庭 ﹁工場﹂に見立てて、gitinit, git add, git commit, git status, git log, git branch, git checkout, git merge, git clone, git pull, git push, gitfetchを解説されています。 絵がかわいくてわかりやすい。git入門 (全22回) - プログラミングならドットインストール 説明不要、みんな大好きドットインストールの﹁git入門﹂︵全22回︶です。 イラストでわかる!git入門の入門 : アシアルブログ アシアルブログより﹁イ
-
1