Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
Frontrend Vol.6 powered by CyberAgent, Inc. http://frontrend.doorkeeper.jp/events/6907 で発表したプレゼン資料です。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
github(というよりgit)使っている方は結構な数いらっしゃると思います。 私もそのうちの一人ですが、正直「addしてcommitしてpushするだけ」です、はい。 branchとかmergeとかfetchとかあの辺がいまいちわからない情弱です。 あんまりこの辺をまとめて書いた記事が見当たらなかったのでまとめることにしました。 基本的にはgithub:helpの要約だと思ってくださればよいかと思います。 レポジトリを作る レポジトリ gitで作ったレポジトリは./.git以下に全てのcommitなどが保存されます。gitはさらにリモートでレポジトリを持つことができ、これの一つがgithub repositoryになります。 レポジトリの作り方: $ mkdir ~/Hello-World # "Hello-World"ディレクトリを作ります $ cd ~/Hello-World # 作
mirahを最初にインストールした時に、 git://github.com/headius/mirah.git の方から持ってきてて、あとから git://github.com/mirah/mirah.git の方が最新なことに気づいて、別にそのまま新たにcloneしてくればいいんですが、 originを変えれないのかな?と思ったのでメモ。 **追記** @murachue さんより教えていただきまして、 % git remote set-url origin <新しいリポジトリURL> が普通とのこと。明らかにこっちのほうが自然なかんじですね! @murachue さんありがとうございます!! 使用した感じは以下のとおりです。 regina% git remote -v origin git://github.com/headius/mirah.git (fetch) origin gi
ちょっと今更な感じもありますが、iOS開発でGitを使うときのTipsを紹介します。 Gitそのものの使い方は理解している前提のもとで書きます。 バージョン管理する対象 Xcodeのプロジェクトにはバージョン管理する上で結構余計なものが入っています。 Gitで管理すべきでないもの Xcodeの作業データ Xcodeのプロジェクトは.xcodeprojですが、こいつ自身はディレクトリになっていて project.pbxproj project.xcworkspace xcuserdata というファイルが入っています。このうち、Gitで管理するべきものはproject.pbxprojです。 その他のものはXcodeの状態(グループを開いてるかなど)を管理しているものなので、 プロジェクトのバージョン管理対象としては適切ではありません。 ビルドデータ xcodebuildコマンドを実
このブログをご覧のみなさん、こんにちは。 git commit を実行後にコミットをやり直したり、コミット自体を取り消す方法を調べたので、調査した手順をメモとして残しておきます。 起因 現在、主催している総武線沿線読書会で『アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)』を対象書籍として読んでいます。 この書籍の中で『読書リスト (Reading List) 』という節があり、その中で自分の読書リスト (Reading List) を作成し、読んでいる書籍を記入、公開して、最新状態に常に更新し続けましょうというものがありました。それを切欠に以下で読書リスト (Reading List) を公開しました。 が、初回のコミット時に initial commit. というコメントでコミットしていました。後になって、このコメントを修正
平素よりイベントカレンダー+ログをご利用いただき、誠にありがとうございます。 イベントカレンダー+ログは「IT・製造業・ビジネス関係のイベント(セミナー・展示会・勉強会・コンテスト・Webイベントなど)を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー+ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年6月30日(火)15:00をもちましてイベントカレンダー+ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
「 www.eiplab.com 」のページは、ドメインが無効な状態です。 ウェブサイト管理者の方はこちらから変更・更新を行ってください。 「 www.eiplab.com 」is Expired or Suspended. The WHOIS is here.
Branching in Git is one of my favorite features. If you have used other version control systems, it's probably helpful to forget most of what you think about branches - in fact, it may be more helpful to think of them practically as contexts since that is how you will most often be using them. When you checkout different branches, you change contexts that you are working in and you can quickly con
If the images do not work, you can try the Non-SVG version of this page. SVG images have been disabled. (Re-enable SVG) This page gives brief, visual reference for the most common commands in git. Once you know a bit about how git works, this site may solidify your understanding. If you're interested in how this site was created, see my GitHub repository. Also recommended: Visualizing Git Concepts
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら: http://mislav.uniqpath.com/2010/07/git-tips/ (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意:いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます: brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
こんにちは。ドワンゴの荒木です。 弊社若手エンジニア鳥居みゆっきと一緒に技術を学ぶ生放送「みゆっき☆Think」! 第9回のテーマは「はじめて学ぶバージョン管理とGit」 放送内で使用されたスライドと、みゆっきノートを公開します。 放送内で使用された資料はこちら↓ みゆっき☆Think#9「はじめて学ぶバージョン管理とGit」 View more presentations from techtalkdwango みゆっきノートはこちら↓ みゆっきノート#9「はじめて学ぶバージョン管理とGit」 View more presentations from techtalkdwango 見逃された方は、 チャンネルのアーカイブ動画で視聴いただけますので、是非ご覧下さい! また、ニコニコ生放送のタイムシフト視聴について、 ニコニコ生放送の録画不具合の為、タイムシフト動画が途中
追記:たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記2(2011/11/07):commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ | ├─ 一人で使ってるよ | | | ├─ 手元に変更を取り戻したいよ(1)(そうだね、add忘れだね派) | |
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く