オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
git switchとrestoreの役割と機能について - Qiita
先日8/16にGitバージョン2.23.0がリリースされました。 今回の目玉機能と言えば、新しいコマンド git switch と git restore ですね！ 本稿ではこちらの2つに絞ってどういう役割・位置づけの機能なのか英語ソースの引用も含めてご説明します。 TL;DR ブランチの変更は git switch ファイルの変更は git restore 今まで通り git checkout は使える 新機能は「実験的機能」なので今後変更の可能性あり 新機能が追加された背景 Highlights from Git 2.23によると、 git checkout に出来ることがあまりに多いため（ブランチ操作のほか、indexされたファイルの復旧、履歴上のファイルの取得など）、役割を明確に分けるためのコマンドが追加されたとのことです。 It turns out git checkout ca
Gitで巨大プロジェクトを扱うときに少し便利なupdate-ref｜TechRacho by BPS株式会社
ビルドに時間がかかる（数十分～数時間以上）プロジェクトを扱うときに役立つかもしれない、Gitの小ネタです。 Gitには git help しても出てこない（ git help -a すれば出る）便利なコマンドがたくさんあり（※）、そのうちの1つ update-ref のご紹介です。 ※他には例えば update-index --assume-unchanged なども有名ですね。 どんなときに欲しくなるか こんな感じの、あるヘッダファイルに多数のソースファイルが依存するプロジェクトがあったとします。 repos |- common.hpp |- source1.cpp |- source2.cpp |- source3.cpp |- source4.cpp |- source5.cpp |- ... まずは master ブランチにいます。 $ git status On branch m
GitHub にパスワードとかセンシティブなファイルを push してしまったときの対処法 - Qiita
すればすぐ何もなかったことにできます。 が！そこで気付かずに GitHub へ git push してしまった！こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、__パスワードの書き換えやトークンの無効化__を施しましょう。 （この時点でもう何もなかったことになってない気がする） git の履歴から該当のファイルを消す git reset と git filter-branch 2つの方法があります。 git reset (2015-12-29
CUIで見やすい git コミットグラフ: git-foresta 作った - Qiita
なぜ作ったか ターミナルでの git 操作に tig を愛用してます。素晴らしいツールなんですが、マージが入り組んでくるとコミットグラフの線が途切れてしまったり、結構見るのがしんどくなります。tig と併用する目的で、入り組んだマージ履歴を見やすく表示可能な、テキストベースのコミットグラフ表示ツールを探していました。 そんな時、 Jan Engelhardt 氏が作った git-forest を見つけました。入り組んだマージ履歴も見やすく表示できるコミットグラフはいい感じなんですが、ハッシュ・日付・作成者・ブランチ名などの表示方式がイマイチに感じ、コードをいじっているうちに元とは結構違う見た目になりました。これを周囲の人にも使ってもらったところ「見やすい」と評判が良く、せっかくなので公開することにしました。 サンプル（スクリーンショット） というわけで、さっそくサンプルをご覧ください。まず
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
Gitの.git/objectsの中身を追ってみる - kk_Atakaの日記
あらすじ この記事は Git Advent Calendar 2013 の 14 日目の記事です。 12 日目: @ton1517さん - gitのサブコマンドを自分で作る - ton-tech-ton 13 日目: @horimislimeさん - git mergeでコンフリクトが発生するか前もって調べる方法 - Qiita [キータ] 14 日目: ここ 15 日目: kyanroさん - git - rebase 直後に、自分が修正していたファイルが変更されたかどうかを調べる - Qiita [キータ] とりあえず 12 日目へつなげておきますね。 最近 Subversion を使うことが多く、めっきり Git を使っていないので、復習として .git/objects の中身を追ってみた。 参考 Pro Git 9章 Git - Gitの内側 アリスとボブのGit入門レッスン Ch
あまり知られていない便利なGitサブコマンド4選 - Qiita
この記事について Livesense(その2) Advent Calendar7日目の記事です。 6日目はI/OスケジューラがMySQLにどの程度影響するのか確認してみると、Simplenote でブックマークレットで GitHub Flavored Markdown (GFM)でした。 はじめに Git便利ですよね。 触り始めた当初は、git status、git add、git commit、git logくらいしか使ってませんでした。 いろんなサブコマンドに興味を持ち始めたのは、git rebaseを知ってからだと思います。 CVSやSubversionからGitに移った私としては、git rebase -iにより気軽にコミットの順番を入れ替えたり、メッセージを変更できることに衝撃を受けた記憶があります。 今回は、あまり知られてないけど(個人調べ)、知っておくと何かと役立つサブコマン
tigrc(5)
set variable = value bind keymap key action color area fgcolor bgcolor [attributes] source path You can permanently set an option by putting it in the ~/.tigrc file. The file consists of a series of commands. Each line of the file may contain only one command. Commands can span multiple lines if each line is terminated by a backslash (\) character. The hash mark (#) is used as a comment character.
やけに丁寧なtigの設定ガイド（表示制御編） - Qiita
はじめに コマンドラインで利用できるgitブラウザとして人気のtigですが、 使っていくうちにデフォルトの挙動では物足りなく感じ、.tigrcを利用したカスタマイズをしたくなってきます。 .tigrcをいじると色々なカスタマイズができますが、一度に多くの設定を書いてしまうと、 何が変わったかわかりづらかったり、変更の利点が曖昧になる時もあると思います。 そこで本記事では、.tigrcに関して筆者がオススメする4つの表示制御設定を紹介します。 ただ設定を紹介すると設定4行とコメントだけで終わるので、 スクリーンショットでbefore/afterを比較したり、オススメ理由を書いていきます。 なお、表示されているリポジトリは、本稿執筆時点で筆者が個人的に気になっているプロダクトである favico.js のmasterブランチです。 「やけに丁寧だね！」と読者からコメントをいただけるような内容に
git 差分を見る - Qiita
### 前回コミット(HEAD)からの差分 ```sh git diff HEAD ``` ### ステージングエリアとHEADとの差分 ```sh git diff --staged git diff --cached ``` ステージングエリアというのはaddしたファイル群のことですね。ちなみに--staged と --cachedは同じ結果。お好きな方をどうぞ <br> ~~~ コミット ~~~ ### 自分がしたコミットを確認 ```sh git log -p --name-only (修正したファイル一覧) git log -p (変更内容差分, ファイル名を引数で渡すと単体で指定可) git log -p --ignore-space-change (スペースや改行で差分が見づらいとき) ``` <br> ~~~ マージ先(master)に切り替える(```git checko
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Git Undo エイリアスを定義する | POSTD
(注：2017/06/22、いただいたフィードバックを元に翻訳を修正いたしました。) このような経験はありませんか？「ローカルのコミットをし過ぎてしまったことに急に気づいて ローカルコミットを書き直している最中 、rebaseしすぎてしまい、自分が思い描くような履歴になっていなかった」。どうですか？ 私はあります。そのような時、「ただ CTRL + Z で開始時に戻れればいいのに……」と思います。もちろん、決してそんなに単純ではありません。 GUI でさえもです。 そんな絶望的な瞬間を経験することがあったので、 git undo コマンドを独自に作成する決心をしました。以下に私のアイデアと、そこに行き着くまでの過程を紹介したいと思います。 Reflog Gitのundo操作を行うために私が最初に目を付けたのは、reflogです。「 reflogとは何だろう？ 」と思うかもしれませんね。Gi
[Git]GitのpullをFast-Forward onlyにする
Git の pull / merge が --no-ff だと 自分の Mac と会社の Mac で wada811/dotfiles を更新/同期していると 以下の画像のようにマージコミットが増えていってコミットグラフも分岐してしまいます。 ただ異なる環境で編集しているだけなのに このように本質的でないコミットが増えていくのは本意ではありません。 git pull --ff-only で実行すれば良い上の例では確かにそうです。 しかし、 Brewfile + Homebrew + Homebrew-caskで Mac の環境構築をする | DevAchieve で書いた HomeBrew / HomeBrew-cask の更新では brew upgrade で内部的に git pull が実行されるので、 オプションを付けることができません。 個人的な設定により Non Fast-for
git push -f を捨てよ、--force-with-leaseを使おう - ちぎっては投げるブログ
japan.blogs.atlassian.com そもそもforceで上書きするなという話もあるが、master/develop以外の作業ブランチでは、developにマージリクエストを出す前に、すでにpushしているコミットを綺麗にrebaseするためにpush forceすることはある。 最初から綺麗なコミット単位のみをpush出来ればいいのだが、翌日急に休んだときに誰かが引き継げるようにとか、ローカルのデータが吹っ飛ぶ可能性を考えてバックアップの意味でpushするとか、諸々の理由をつけて作業がきちんと完結していない状態でpushすることもある。もちろん、そんなことをするのは作業ブランチ限定で、developやmasterには仮コミットはpushしてはいけないし、あとで消す仮コミットであることがわかるようにコミットログを書いておくのが良いと思う。 そうしたわけで、push -fをする
git push `--force-with-lease`はいつも安全？ - Qiita
git push --force-with-leaseはgit push --forceと違って、他の人がpushしていたら良い感じにコケてくれるので安全、という話を聞き、さっそく使っています。 git push --force でなく git push --force-with-lease を使う - valid,invalid --force considered harmful; understanding git's --force-with-lease - Atlassian Developers ただ、ちょっとだけ注意しないとな、と思ったところがあるので書き残しておきます。 前提 git 2.6.4で確認 最後にfetchしたタイミングでの一致を保証する man git-pushを見るとこんな記述があります。 --force-with-lease alone, without
チーム開発に必要なGitコマンドを神速で習得しよう！
すみません、タイトルは釣りです。書籍『入門git 』と『もっと早く知りたかった！ Gitが鬼のようにわかるスライド厳選7選』、『Gitがこわくて触れられなかったけど、このスライドで理解出来るようになったよGitサイトまとめ』紹介のスライドを読んで、理解したことをまとめるためにこの記事を書きました。今までは個人でしかGitを使っていなかったので、チーム開発に必要なGitコマンドを少しでも理解できるように頑張ります！ (05/13 08:45) githelpを追加 🐡 Gitの基本的な開発スタイルについて From イラストでわかる！git入門の入門 Gitの基本的な開発スタイルは次のとおりです。 (1) gitの開発ではローカルで使う個人リポジトリとチームで使う共有リポジトリを用いる (2) 共有リポジトリに push すると個人リポジトリのこれまでのコミット内容を送れる (3) pul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - OctoLinker/OctoLinker: OctoLinker — Links together, what belongs together
What are the differences between git remote prune, git prune, git fetch --prune, etc
Jenkinsでgitリポジトリ上の特定のファイルが変わってたら何かしたいとき - Qiita
