GitHubに画像ファイルを保存してREADME.mdで表示する方法
GitHubのレポジトリページにはREADME.mdの内容が表示されますが、その中に画像を表示したい場合どうするのがよいでしょうか？ GitHub上にその画像をアップロードして参照できれば、ローカルや他のWebサイトで画像ファイルを管理する必要がなくなります。今回はGitHubのWikiページを利用する手順をメモします。 手順1 GitHubにレポジトリを作成します通常の手順でレポジトリを作ります。 ここでは yukisovというユーザ名で、web-sindan-crawler(.git)という名前のレポジトリを作ったとします。 手順2 このレポジトリに対するWikiレポジトリをローカルにcloneしますGitHubのWikiページは1つのレポジトリになっています。元のレポジトリ名の末尾を”.git”から”.wiki”に変えた文字列がこちらのレポジトリ名になります。 Wikiレポジトリをロ
Gitのリモートブランチと追跡ブランチは違うよ - kaeruspoon
remotes/origin/masterがリモートブランチのすべてであるように見えます。 このとき、サンフランシスコの同僚がリモートリポジトリに新しいブランチをpushしていたとします。このことをいつ知ることができるのでしょうか。 git branch -a コマンドを何回叩いても、現れるのは上記の通りorigin/masterのみです。 つまり、git branch -a コマンドはリモートブランチの一覧を表示しているわけではないのです。 では何を表示しているのかというと、リモートブランチの情報を持っているローカルリポジトリの中の特殊なブランチの一覧を表示しているのです。この特殊なブランチ、つまり追跡ブランチですが、これ自体はローカルに存在しているのでローカルブランチの一種であるといえます。そのため、最新のリモートリポジトリの状態なんて知らないのです。 最新のリモートリポジトリの情報を
1つのgitリポジトリに複数の作業ディレクトリを作る - Qiita
（commit or stash + checkoutすらめんどいことだって、あるんですよ・・） そもそもリポジトリと作業ディレクトリの違いって？ gitリポジトリには、コミットされている内容やブランチなどの全ての情報がつまっています。一方で作業ディレクトリは、リポジトリ内のあるcommitの内容を、ファイルとして書き出したものになっています。 git-new-workdirコマンド gitリポジトリに紐づく新たな作業ディレクトリを作成します。 ただし、デフォルトでPATHが通っていません。Fedoraあたりなら /usr/share/doc/git-1.7.10.2/contrib/workdir/git-new-workdir に、homebrewなら /usr/local/Cellar/git/1.7.12.4/share/git-core/contrib/workdir/git-n
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Git で複数ブランチを同時に扱いたいなら git-new-workdir が便利
Git で管理してるレポジトリーで、いくつかのブランチを別々の場所にチェックアウトしたいことがある。 たとえば GUI なツールでブランチ間の比較したい 同時に実行して比較しつつテストしたい ブランチ間でファイルをコピーしたい ドキュメントの生成結果を別ブランチで管理したい といったときに、必要になる。 ブランチの個数だけ clone しちゃえば用は足りそうなんだけど、でかいレポジトリーだったら時間もディスク容量ももったいない。 git-new-workdir を使うべきでしょう！ 先日、「git-new-workdir を使えばワーキング ディレクトリーを複数を作れて便利」と書いてあるブログを読んだ。 git-new-workdir が便利 - #生存戦略 、それは - subtech git-new-workdir の usage を見てたら、別ブランチのワーキング ディレクトリー作成
【git】分かりやすく！mergeは「合流」、rebaseは「付け替え」!
gitのコマンドって、コマンド名だけでは動作が想像できないものが多いですよね…。けど、勉強していく中で呪いのように見かける言葉。 『rebaseすんなし』 ﾄﾞﾕｺﾄｰ？ってことでまとめ。 pull = fetch + merge（rebase）! まず。 gitの主な動作はpush・fetch・merge・rebaseで出来ます。 push rebase pullはー？っていうと、fetch して mergeする = pull。 ちなみに、fetch して rebase する = pull --rebase。 要するに、pullは使わなくてOK！ってことです。 使わなくていい理由はこちらの記事が分かりやすかったです。ご参照ください。 Git pullを使うべきでない３つの理由 mergeするとどうなるの？ mergeは2種類ある！その1・・・Fast-Forward topicブランチは
今さら聞けないgit pushコマンド - Shoichi Matsuda's diary
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 （これ以降の記事中のリモートは全てoriginとします。） このコロンは何？？ リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか？ 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
zshでgitのコマンドやブランチ名を補完できるようにする | qnyp blog
zshでのgitコマンドの入力補完を設定する方法はいくつかあるようですが、最近はgitのソースツリーにcontrib/completion/git-completion.zshというものが含まれているので、今回はそれを利用する手順を紹介します。 設定を行うと、以下のようにコマンドやリモートリポジトリ、ブランチ名の補完ができるようになります。 今回、動作を確認した環境は以下の通りです。 Mac OS X 10.8.3 zsh 5.0.2 git 1.8.2.3 zshとgitをHomebrewでインストールしている場合は、zshの設定を行うだけで作業完了です。git 1.8.2.2に含まれる補完定義ファイルとgit 1.8.2.3に含まれるそれとでは結構違いがあるようなので（コミットログ）、gitはできるだけ最新版にアップデートしておきましょう。 Homebrewを使っていない場合は、補完定
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
Gitでリモートリポジトリを巻き戻す - tmtms のメモ
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
zshのターミナルにリポジトリの情報を表示してみる · けんごのお屋敷
zshのターミナルに今いるパスのリポジトリの情報を表示してみることにします。最終目標はこんな感じ。 ブランチ名を表示 全てコミットされてきれいな状態であれば緑色 addされていないファイルがあれば+マークをつけて赤色 commitされていないファイルがあれば!マークをつけて黄色 ちなみにこの記事に書いてあることは zsh のバージョンが 4.3.10 以上に限って有効です。 さて、これを実現するには vcs_info というものを使います。以下のような記述を ~/.zshrc に追加します。 # この行は現在のパスを表示する設定です。ブランチを表示して色をつける設定とは関係ありません RPROMPT="%{${fg[blue]}%}[%~]%{${reset_color}%}" autoload -Uz vcs_info setopt prompt_subst zstyle ':vcs_i
zshでGitのブランチ名をプロンプトに表示する / LiosK-free Blog
2011-05-09 カテゴリ: その他のプログラミング タグ: Tips Linux Zsh 車輪の再発明 トラックバック Git zshのプロンプトに、Gitのブランチ名を表示させたくなった。 ちょうど、↓の図のような感じに。 bashではgit-completion.bashで定義される__git_ps1を使って、例えば↓のような感じで書いていたけど、 # Show git branch name if [ -n "$(type -t __git_ps1)" ]; then PS1='\u@\h \w$(__git_ps1)\n\$ ' fi zshではvcs_infoという関数を使って実現するらしい。 vcs_infoはGitに限らず、各種のVCS (Version Control System)に対応しているようなので、一度設定しておけばCVSやSubversion、Mercur
2012-05-29
メモ（5.5） general_log = 1 general_log_file = /var/log/mysql/general.log log_error = /var/log/mysql/error.log slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 github に push するときに，ユーザー名とパスワードを聞かれて面倒 How do I ensure Git doesn't ask me for my Github username and password? "git config -l" で表示される，"remote.origin.url" を書き換える（'https' から始まっていた） $ git config remote.origin.ur
GitHub と homesick を使って複数 Mac 間で dotfiles を同期する | DevelopersIO
複数 Mac 間で、.vimrc や .zshrc などの設定ファイル（dotfiles）の同期って面倒くさいですよね。 dotfiles の管理には、GitHub とシェルで管理したり、Dropbox を使ったりあるようですが、 最近 homesick という gem を教えてもらい、簡単に管理することができたので、私はコレを使っています。 用意するもの GitHub のアカウント Mac *1 homesick のインストール homesick は gem install で簡単にインストールできます。 $ gem install homesick rbenv を使ってる場合は、rehash しておきましょう。 $ rbenv rehash GitHub に dotfiles リポジトリを作成 GitHub にリポジトリを作成します。 先ずは、ローカルに dotfiles ディレクトリ
DotfilesをGitHubで管理する
最後の更新が 1 年以上前とは。。。気を取り直して、WordPress のバージョンも最新版に上げ、Nilminiという良い Theme も見つけ、技術メインで再びいろいろ発信しようということで更新してみます。 最初はライトなものから。メインのテキストエディタをJeditからMacVimへ移行しようか検討していて、その過程で.vimrc を複数環境で同期するために GitHub（github.com/lowply）を使い始めました。その時のメモ。 vim 本体まず vim 用の.vimrc、MacVim 用の.gvimrc。それから、プラグインをpathogenで管理することにしたので.vim ディレクトリを。プラグイン管理にvundleも使ってみたけど複雑になりすぎるので好きじゃないです。使いこなせてないだけなのかもしれないけど。 2012/2/12 追記：vundle をしっかり調べて
そろそろしっかりvimを使う。dotfilesのgithub管理とvundleの導入。 - 南極の図書館
vimを使い始めて暫く経つのだが、なかなか初心者レベルを抜けられない。 そろそろしっかりvimを使ってみようと思う。 聞いたところ、dotfiles(.vimrcなど)はgithubで管理すると便利らしい。 また、vimのpluginはvundleで管理するのがナウいらしい。 今回はこの二つを実際に行ってみる。 なお、dotfilesはWindowsとMacで共有する。 目次 ・vundleとは ・目的と方針 ・dotfilesの管理とvundleの導入 ・vundleを利用したプラグインのインストール vundleとは そもそも、vundleとは何か。 簡単に言うと、vimのpluginを管理するpluginである。 RubyのBundlerに影響を受けたらしい。（個人的にこれがポイント高かった。） 特徴は、pluginを.vimrcで管理すること。 .vimrcに必要な情報を書いておけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
続続・イラストでわかるgit入門の入門：checkoutをする
Git で常に除外したい設定を .gitconfig で設定する方法
クマーの目覚まし時計 【GitHub】ユーザーネームの変更、リモートリポジトリの切り替え