オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ
codic - デベロッパーのためのネーミング辞書
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
タイトルは大目に見てください><。 本内容は危険な操作を伴うのでくれぐれも自己責任でお願いします。 間違いもあったら指摘ください。 ローカル編 自分のローカル環境だけで閉じていて、他の人への影響がない場合に有効です。 リモートにプッシュしちゃってる時は、他人への影響が発生するので危険です。 やらかし１：コミットメッセージに禁止ワード入ってて人生やめたい時 コミットメッセージを修正するのは簡単です。 ファイルの追加なんかもできちゃいます
【使い過ぎるとカッコ悪い】 IT業界のルー語 BEST40-Six Apart ブログ｜オウンドメディア運営者のための実践的情報とコミュニティ
どの世界にも業界用語というものがありますが、IT業界の人がやりがちなのがカタカナ用語の多用です。 「アライアンスによるインタラクティブかつウィンウィンなスキームでステークホルダーにコンプライアンスを云々・・・」等、やり過ぎるとルー語的になってしまい、相手に「意味がわからない」とか「カッコつけてるの？」と不快感を与えかねません。 ちなみに私事ですが、先日、妻から用事を頼まれたとき、 「土曜はちょっとタイトだわ。日曜ならいいけど、リスケでOK？じゃあ、それでアサインしといて。え、毎週するの？だったらルーチンタスクにしとくほうがよくね？」 って返事したら、 (*｀Д´*) 「日本語で言え！わざわざ横文字にすんな」 （#^ω^） 「“カタカナ用語使いこなすオレ、かっけー”とか思ってるでしょ？」 と、さんざん毒づかれてしまいました。 というわけで、IT業界で使用頻度の高い（と思われる）カタカナ用語
先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra
英語コミットコメントに使えるオシャレフレーズ集
英語コミットコメントに使えそうなオシャレフレーズを聞いたので、これを使ってドヤ顔コミットをしたくてやれるチャンスを虎視眈々と狙う毎日です v, x, g, z とかこのへんが入ってる単語だとなんかカッコ良さ増す。 tweak とかデザイナーにはだいぶ便利。 単語 意味
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
GitHub上の実際のコミットメッセージやIssueのやりとりをみて、チートシート作りました。 共通的なこと コミットメッセージやIssueのタイトルは、主語省略し、1文で書き行末ピリオドは付けない 動詞は現在形・過去形のどちらも同じくらいの頻度で見られるが、どちらかに揃える。 コミットメッセージを書く Japanese English
ChangeLog を支える英語
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
〔提案に対して〕いいと思う；問題ないと思う；〔コードレビュアーが、問題ないコードに対して〕レビュー終了；（コードの）承認
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 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
はじめましてこんにちは、今年新卒でKRAYに入社しました亀井と申します。 会社のみなさんからは「あさちゅん」と呼ばれております。どうぞよろしくお願いします。 突然ですが、みなさん使ってますか？ Git。 KRAYではバリバリ活躍してるGitですが、 「よくわからない……」と頭を抱えてる方も多いですね。 わたしも抱えてます。 正直、KRAYに入社するまでターミナルを使ったことすらなく、 Gitも入社してから使いだしたので初心者もいいところです。 そんなわたしが1日約200回×3ヶ月ターミナルでGitコマンドを打ち続けて やっとわかってきた、Gitの「これなんで？」を解説します。 主にGit初心者、Gitについて理解を深めたい人向けです。 もくじ なんでcommitする前にaddしなきゃいけないの？ ブランチってなんのために分けるの？ HEADってなんなの？ 消したファイルもコミットしなきゃい
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
2012年08月16日08:00 by oklahomer 「私がFacebookで働いていて嫌いな10個のこと」が面白い カテゴリ小ネタ 15日の14時過ぎにFacebookの開発ディレクターが「現役社員がこんなことを書くなんて信じられない」というコメント付きでシェアしていた「Ten Things I Hate About Working at Facebook（私がFacebookで働いていて嫌いな10個のこと）」という記事が面白かったので共有です。 いきなりニュースフィードに流れてきたので、IPO後の初業績報告だとかIPO以来の幹部入れ替わりが話題になってるから社内はピリピリしてんのかなぁ、まだエイプリルフールじゃないしなぁと思いつつ帰宅してジックリ読んだわけですが、読んでみて納得です。考えてみたら、本当にマズい内容だったら開発ディレクターが拡散したりしませんよね。 以下、本文和訳で
（第10話 歩きスマホにご用心｜もっとマンガで分かる！Fate/Grand Order） 前回転生トラックについてまとめたが、調べているうちにフィクションでのトラックの描かれ方が気になった。というのもweb小説に限らず、フィクションの世界ではトラック事故が非常に多いからだ。 例えば今期のアニメだと『亜人』と『僕だけがいない街』は、トラックの事故がきっかけで物語が動いていく。他にもなかったかと調べたら結構あったので、全てを網羅するのは不可能だが、最近のものを中心に印象的だった事故を幾つかに分類していく。 web小説以外のトラック事故 能力発動系 悲劇系 キャラ退場系 ギャグ・コメディ系 いつから衝突事故が描かれ始めたのか なぜ漫画やアニメのキャラクターはトラックに轢かれるのか まとめ web小説以外のトラック事故 能力発動系 キャラクターが特殊能力を発揮、顕現、あるいは能力説明する際にトラッ
GitHubだけで超高機能なスライド資料が作れる「GitPitch」の使い方を徹底解説！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、ブラウザ上のGitHubでMarkdown（マークダウン）ファイルを作成し、そのまま超高機能なスライド資料に変換してくれるサービスのご紹介です！ もちろん、自分でMarkdownファイルを用意してpushするだけでもOKなのですが、今回はコンソール画面などは使わずにすべてブラウザだけで完結できる方法をご紹介致します。 【 GitPitch 】 ■「GitPitch」の基本的な使い方！ それでは、実際に簡単なスライド資料を作ってみましょう！ まず最初に、自分のGitHubアカウントでログインし、新規のリポジトリを作成しましょう！ 「① リポジトリ名」は好きな名前を付けてください。 画面下にある「② チェックボックス」をONにしてから「③ Create repository」ボタンをクリックしましょう。 すると、自動的に「README.md
データを眺めるのが好き 収集している情報 実現方法 データから分かった知見(?) 今後 年末なので、今年買ってよかったものに引き続き、今年やってみてよかった習慣について書いてみたいと思います。 データを眺めるのが好き 昔からデータを眺めるのは好きだったんですが、今年の5月くらいから自分に関するデータをとにかく収集してみました。可視化することで何か有益な視点だったり、生活の改善点が見つかるのではないか、という目的です。色んなデータを集めまくった結果、以下のようなグラフができあがります。ちょっと画像が小さいですが、毎日の歩いた歩数や体重、気温、録画した番組名、自宅マシンの負荷状況などが載っています。 収集している情報 上の画像ではとりあえずBlogに上げれるようなデータしか見せていないですが、収集している情報としては以下のようなものがあります。使用しているスクリプトで公開できるものはgithu
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
bitbucketの使い方
With best-in-class Jira integration, and built-in CI/CD, Bitbucket Cloud connects developer workflows from planning to incident management. Join millions of developers who choose to build on Bitbucket.
図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
会社の同期で毎週勉強会をやっていて、自分が発表する番だったので最近使ってるCLIツールについてまとめてみた。 hub github/hub プルリクエスト作成などGithub上での作業をコマンドラインから。会社ではGH:Eでプルリクベースの開発スタイルなので毎日使っている。最近はhubのGo実装でghというのもあるみたいだけど、こっちはまだ試していない。 GitHubユーザーのためのhubコマンド - Qiita tig jonas/tig コミットログ等の閲覧を楽にしてくれる。仕事ではSourceTreeも使ってるんだけど、やっぱりメインの作業はターミナル上だし、log・diff・stashあたりがgitコマンドよりはるかに見やすくて手放せない。 ~/.tigrc に以下のような設定をしておけば、historyで選択しているcommitのGithubページをすぐ開くこともできて便利。 t
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います（9つでも多いよ！というツッコミは受け付けません！）。 【コマンド その１】 git clone 【コマンド その２】 git log 【コマンド その３】 g
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
gitにおけるコミットログ/メッセージ例文集100
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
プログラミングでよく使う英単語のまとめ【随時更新】
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
Gitでやらかした時に使える19個の奥義 - Qiita
Vagrant - naoyaのはてなダイアリー
GitHub English Challenge Cheat Sheet - Qiita
英語のコメントや issue で頻出する略語の意味 (FYI, AFAIK, ...) - Qiita
Git初心者が絶対に覚えておくべきコマンド - idesaku blog
Git初心者に捧ぐ！Gitの「これなんで？」を解説します。
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC
Gitのコミットメッセージの書き方 | POSTD
開発フロー研修 @ Wantedly - Qiita
コミットメッセージの書き方 - 2012-02-21 - ククログ
「私がFacebookで働いていて嫌いな10個のこと」が面白い
なぜ漫画やアニメのキャラクターはトラックに轢かれるのか - カトゆー家断絶
今年よかった習慣: ライフログ収集および可視化 - yasuhisa's blog
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
人間らしいGitのエイリアス | POSTD
Gitコミットメッセージの7大原則 - rochefort's blog
gitとプルリクエストに関して思うことまとめ - Qiita
さいきんのターミナル開発環境 - 面白コンテンツ探求日記
Linus Torvalds 氏の理想の git 運用と GitHub
Git submodule の基礎 - Qiita
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド - akiyoko blog
Gitのベストプラクティクスっぽいもの - Sexually Knowing