Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
@yuku_t Qiitaに載ってた GitHub Cheet Sheet 入門Git コンフリクト発生時の問題 もとの状態がよくわからなくなるとき merge.conflictstyle もとの祖先を表示さす git stash save pop indexしたものがstashされる --all --inclide-untracked --keep-index(index treeをそのまま残す) 全く新しいworking directoryがほしい git-new-workdir シンボリックリンクを貼ってくれるところがgit cloneと違うところ。 編集もstashも同期される。 diff-highlight git-core/contrib git diff & apply $ git diff -w | git apply --cached w 空白文字 cached inde
複数のリポジトリがあった時に、それをまとめた親レポジトリを作り、各レポジトリをサブディレクトリとしてまとめてしまう方法。 ファイルとして保存するだけじゃなく、ちゃんとコミットHistoryも保存される。一つにまとめたものを後で切り出すこともできる。 これでリポジトリ数の削減が可能になるので、GithubのPrivateリポジトリ数の上限などにお悩みの人は是非お試しを。現在、頻繁に使っているものをまとめてしまうのはおすすめしないが、古い使われてないものを歴史ごとアーカイブするのには持ってこいだと思う。 以下では、 $ACCOUNT = githubのアカウント名 $REPO = サブディレクトリに移したいレポジトリ名 $ARCHIVE = 複数リポジトリをまとめておくアーカイブ用親リポジトリの名前 とする。 複数リポジトリをまとめたアーカイブ用gitリポジトリをローカルに作成
GitHub トレーニングチームから学ぶ Git の内部構造のノートです。 曖昧なところもあるので、間違いがあったら教えてください！ http://connpass.com/event/3808/ Graphs, Hashe, and Compression, Oh My! 登壇者：@matthewmccull Hashesについて 従来の CVCS （集中バージョン管理システム）のリビジョン番号は連番。 SVN はサーバーにデプロイした時点でリビジョン番号1と設定される。 Git は SHA1 をつかっている。40桁の16進数のフィンガープリントがついてる。これは理論上は重複しない大きさ。こうすることで単純で強固な DVCS （分散バージョン管理システム）がつくれる。 新しいファイルを追加すると、.git/objects/55/7db03de...(SHA1 finger print)
GitHubにはコードの断片を管理したり人に見せたりブログに貼付けたりするのに便利なGistってのがあります。 通常の使い方では、ブラウザで貼付けたりとかすると思うのですが、GistもGitのリモートリポジトリなので、クライアントから使う事も出来ます。 ……ってのはGistにも普通に書いてるんですけどね。 Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. とりあえずやってみます。 色々やってみる まず適当に作ります。 GitHubはお金払わないとプライベートなリポジトリは作れないのですが、Gistだ
上記の記事でmsysをインストールする方法も紹介しています。msysにはls,cp,mvといったlinuxコマンドが入っており、Windowsでvimfilerやvimshellを動作させるために必要です。 Macの場合 事前にXCodeをインストールしておきます。XCodeにgccが含まれています。 下記コマンドでコンパイルします。 cd ~/.vim/bundle/vimproc/ make -f make_mac.mak vimproc/autoload/vimproc_mac.so が作成されていればコンパイルは成功です。 Linuxの場合 gccをインストールします。ほとんどのLinuxではデフォルトで入っているのではないでしょうか。 下記コマンドでコンパイルします。 cd ~/.vim/bundle/vimproc/ make -f make_unix.mak vimproc/
ヒノキ花粉アレルギーの疑いが浮上したhakoishiです。 さて、今回はGitHubでリポジトリをプロジェクトページとして公開する手順のご紹介。 ユーザーページ（http://(アカウント).github.io/）は作っていなくても良いようです。 さて、手順。 ページとして公開したいリポジトリで 「gh-pages」という名前のブランチを作ります。 図はGitHub上で作成していますが、もちろん作業コピー上での作成、プッシュで問題ありません。 そして、下記のURLにアクセス。 http://(アカウント).github.io/(リポジトリ名)/ ※アカウントが「basha-log」、リポジトリ名が「sitetest」なら http://basha-log.github.io/sitetest/ になります。 （アカウントは架空のものです） おや。早すぎたようだ。 10分ほどかかるそうなので
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
github で git diff from..to を表示する - #生存戦略 、それは - subtech で text/plain な diff が表示される。.. じゃなくて ... 。 http://subtech.g.hatena.ne.jp/secondlife/20121225/1356421602 github のコミットページ URL は、実は凄く良く出来ている。 例えば pull request のページ Add each Gem bundled data pointer in mrb_state by masuidrive - Pull Request #605 - mruby/mruby - GitHub Showing 17 changed files with 183 additions and 36 deletions . Show Diff Stats H
10月のRails案件でgitを使って、相変わらずのgit力の無さを痛感したので、覚えているうちにそん時やったことを復習しとくよ。ちなみにGitの操作は全部IntelliJから行ってます。途中、コマンド叩くことあるかなと思ってたけど、そんな事無かった。IntelliJのgitサポートは意外にあなどれない。:-) 復習につかったリポジトリは、片平堂（id:yuichi_katahira）作Androidアプリの「つぶのみ」をforkしたヤツ（GitHub - masanobuimai/tsubunomi）。大分前にforkして、からかい半分でKotlin化して飽きたままになってた。forkした自分が飽きているウチに本家の片平堂版は改修を続けてコミットグラフが伸びてていろいろ都合がよかったのが選んだ理由（片平堂さま、大変失礼しました＆ありがとうございます。 愚かしい事に、forkした自分のリポ
先日（※1）、「.gitconfigの書き方や、gitのTipsについてワイワイ情報交換しましょう！」という趣旨で社内勉強会が開催されました。題して「天下一.gitconfig大会」。ここに我こそはと、5名の強者がネタをエントリしました。 業務後の時間にもかかわらず、いろんな部署から20人以上が参加。社内で最も大きな会議室が、ほぼいっぱいに。 「さいきょうの.gitconfig」（天野 祐介） 「jenkins先生にライブラリの更新をお願いする」（田中 裕一） 「おれさまの.gitconfigでぎっとぎとにしてやんよ」（佐藤 鉄平） 「git のよくある誤解 No.1 rebase について」（山本 泰宇） 「rebase すべき時とその作法」（星野 喬） 天野が、.gitconfigのベストプラクティスを探求していたら、いつの間にかシェルのベスト環境を構築していた……というオチで笑いを取
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
