作りたいもの: 1歩ずつミッションをクリアすることでGitの使い方を覚えられるゲーム - 西尾泰和のはてなダイアリー
増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったので早速やってみました。2つ目。 1歩ずつミッションをクリアすることでGitの使い方を覚えられるゲーム なんちゃらVille系のゲームはどうして人の心をとらえるのか？ 「小さい粒度のミッションが提示されて、それを達成すると次のミッションが表示される仕組み」は、頻繁に「達成感」という報酬を与えることで人の心をとらえるのだろうか？ そういえば僕が昔書いた、対話的インタプリタで1歩ずつ操作しながらPythonを覚えるコンテンツも評判が良かったなぁ。だったらgitの使い方も、1歩ずつ対話的にミッションをクリアしながら学べるようにしたら面白いんじゃないか？ 学習ユーザのユースケース 実は既にgithubにおいてあったりする。一応遊べ
rebaseのイメージ - プログラマの思索
@yusuke_kokuboさんのつぶやきでrebaseのイメージがようやく分かったのでメモ。 【元ネタ】 Twitter / @akipii: とても分かりやすい RT @yusuke_kokubo: ブランチのmergeは2つのブランチが合流するのに対して、 rebaseは一方のブランチがもう一方のブランチに(分岐元から派生した分を)吸収するようなイメージをしてる Rebaseとトピックブランチ: プログラマの思索 mergeは衝突がなければ、派生ブランチをtrunkへ取り込んでくれるが、衝突があれば、マージしてくれない。 rebaseは、trunkへ派生ブランチで育てたパッチを合流するように取り込んでくれる。 つまり、rebaseはtrunkの履歴を壊さず、その履歴の上に派生ブランチの履歴を取り込んでくれる。 「入門Git」にもrebaseについて詳しく解説されている。 trunkに
git-pull、git-pull --rebaseをめぐる冒険＋コンフリクトした場合の作業 - satoko's blog - s21g
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 git-pullで私なりの解釈で aha！が来たのでメモします。 これからは git-pull --rebaseにしよー 下記をそのままという感じなのですがｗ http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。) Here's a tip for keeping up
gitoliteはどうやってユーザを判別しているか - SELECT * FROM life;
ちょっとしたコネタの紹介 gitリポジトリを複数人で共有する時に、AさんはこのリポジトリにコミットできるがBさんはダメ、といった風にアクセス制御をしたくなるが、それを実現するソフトウェアでgitoliteというモノがある。 gitoliteを`host`に`git`というユーザ名でインストールし`reponame`というgitリポジトリを登録すると`ssh://git@host:reponame.git`でアクセス制御をすることができる。 当然ながらこれは`host`に`git`というユーザ名でSSH接続することを意味する。 で、不思議なのはgitoliteは一体どうやってユーザの判別をしているのか、ということだ。 なんせgitoliteはサーバ上にインストールされているのだから、gitoliteから見たらどのアクセスも`git`というユーザなのだ。どうやってgitoliteは「このアクセ
git config --add receive.denyCurrentBranch ignoreはどう危険なのか - 西尾泰和のはてなダイアリー
git config --add receive.denyCurrentBranch ignoreをやるとどう危険なのか。一言で言うと「ある人が行った実装を、別の人が無意識に削除してコミットする」という事態を引き起こす。これが危険じゃなくて何なんだ。 まずローカルで実験用のリポジトリを作ってみよう。fという名前のリポジトリを作って、READMEをおく。今は中身は空っぽだ。 $ git init f Initialized empty Git repository in /Users/nishio/tmp//f/.git/ $ cd f f$ touch README f$ git add README f$ git commit -m "initial" [master (root-commit) ce6d7d5] initial 0 files changed, 0 insertions
Gitのベストプラクティクスっぽいもの - Sexually Knowing
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を使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
Movable Type のコード管理についてまとめてみました-Six Apart ブログ｜オウンドメディア運営者のための実践的情報とコミュニティ
やっと暖かくなってきて桜もチラホラと咲き始めましたね。こんにちわ、シックス・アパートの高山です。 さて、今回はMovable Type に限らずですが、開発の根幹と言えるコード管理についてお話をしたいと思います。 ご存じの方も多いかと思いますが、Movable Type は現在 github 上で開発が行われています。（セキュリティ・フィックスの際には、社内のgitサーバでひっそりと開発が行われます。）gitに移った事を期にブランチ管理のやり方も変えています。 ちなみに、現時点でのブランチはこうなってます。 % git branch -a remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/develop-backuprestore remotes/origin/feature-assetdr
【翻訳】あなたの知らないGit Tips
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
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
SubversionからGitへ移行するときの問題について簡単に語る
SubversionからGitへ移行するときに起こる問題についてちょっと語りました。
mercuiralを使いながらgithubのpull requestを取り込む方法 - 放牧日記
http://partake.in/events/95ab571f-c477-43dd-8d96-396d3b670b6f:title=の成果発表です。 先日あるmercurialリポジトリのミラーリポジトリをgithubに作成したところ、開発がgithubに移ってしまうという(mercurial使い的には)ショッキングな出来事がありました。mercurial使いはいろいろ肩身が狭いですね。 それもこれも、「mercuiralを使いながらgithubのpull requestを取り込む方法」についてのノウハウが共有されていないことに問題があります。今後、二度と悲劇を繰り返さないために考察してみました。 想定する構成 考察した結果です。 bitbucket-and-github urlは次の通り central repository https://bitbucket.org/troter/
git初心者向けのTipsなど - os0x.blog
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
Gitリポジトリの中からFIXMEやTODOがあるファイルをvimで一気に開く - SELECT * FROM life;
FIXMEとTODOが記述されているファイルを全部開く $ vim `git grep -l -e TODO --and -e FIXME` FIXMEかTODOが記述されているファイルを全て開く $ vim `git grep -l -e TODO -e FIXME` 追記： id:takuya_1st さんに教えてもらいました vim に -p オプションを付けることで、複数のファイルを同時に開いた時に、それぞれをタブで開くことができるので以下のようにすると、TODOかFIXMEがあるファイルをgitレポジトリから探し、一つ一つをタブで開くことになります。 $ vim -p `git grep -l -e TODO -e FIXME` ちなみに、タブは:tabnext, :tabpreviousで移動できるのですが、いちいち打つのが面倒なので僕は nnoremap <space>t :
git rebase --ontoが便利すぎる件 - maeda.na@はてな
使用バージョン % git --version git version 1.5.4.3 ヘルプから抜粋 % git rebase --helpのヘルプから抜粋すると、 Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase --onto. First let's assume your topic is based on branch next. For example feature developed in topic depends on some functionality which is found in next.
あまり知られていないGitのTips - アジャイルSEを目指すブログ
思い浮かんだGitのTipsを列挙してみました。 gitのコマンドをで補完する git-completion.bash を入れると、でコマンドの補完が効くようになります。 また、PS1の設定を行うと現在のブランチ名が常にbash上に表示されるようになります。 （Windowsの場合、msysgit は標準で入ってます） contrib/completion/git-completion.bash - GitHub インストール方法（引用） # To use these routines: # # 1) Copy this file to somewhere (e.g. ~/.git-completion.sh). # 2) Add the following line to your .bashrc/.zshrc: # source ~/.git-completion.sh # # 3)
SCMBootCamp in Tokyo 2 を振り返って - 彷徨えるフジワラ
※ 2011/11/27 追記あり 時間枠中は、Twitter のタイムラインを見ている暇が無かったので、togetter でのまとめを元に、落穂拾い的に tweet された質問／疑問に答えることに。 まとめて頂いた @shinyaa31( id:absj31 ) 氏に感謝！(※ @shinyaa31氏自身のまとめはこちら) そして、改めて主催の id:kyon_mm 氏に感謝！ 基調講演枠での tweet 講演内容は好評だったようで一安心。 SCM ツール世代分類に関して: (@oota_ken) ClearCaseはClearCaseはClearCaseは まぁ多分、「ClearCase も忘れないであげてください」ニュアンスだとは思うけど、一応答えておく事に(笑)。 私自身、ClearCase を触ったことが無いので、『パターンによるソフトウェア構成管理』に記載された情報ベースで見る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - seesaa/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントをシーサーの社内用にアレンジ中。
A successful Git branching modelから重要なとこを抽出 - Qiita
Accueil