UpdatePanelで囲っている、もしくはTrigger指定しているのになんでPostBackするの、という時にはClientIDModeをチェックする。
ClientIDMode=Staticだと、コントロールのIDが一意に特定できず(ViewStateに保管されたIDと一致しない？)PostBackしてしまうことがあるようだ。なので、AutoIDなどにする。
特に、子要素を持つコントロール(ｘｘｘリスト、GridViewなど)は注意が必要。
マスターページなどを使っている場合IDにプレースフォルダのIDが付加されたりするのでClientIDMode=Staticを使いたくなる。なのでこの仕様はちときつい・・・
2012年11月28日水曜日
2012年11月25日日曜日
作業の流れで覚える Git コマンド
Gitのコマンドについて、大体の作業の流れに沿ってまとめました。GitHub想定。
*プロキシ環境の場合
ユーザ認証なし
$git config --global http.proxy http://proxy.server.com:port
ユーザ認証あり
$git config --global http.proxy http://user:pass@proxy.server.com:port
設定結果の確認
$git config --get http.proxy
参考サイト：ssh over proxyでgithubをアクセスする（Windows）
○初期設定編
*ユーザー名/メールアドレスの設定
git config --global user.name "Suzuki Taro"
git config --global user.email taro@example.com
*エディタの変更
git config --global core.editor notepad
*改行コードの扱い
大体GitHub上にあがっているのは改行コードLFなので、Windowsの場合以下の設定をしておくとチェックアウト時LF - >CRLF、コミット時CRLF->LFの変換を自動で行ってくれる。
git config --global core.autocrlf true
Mac/Linuxの場合はCRLFが混じっていると困るので、チェックアウト時CRLFをLFに換えてくれる設定をしておくとよい。
git config --global core.autocrlf input
*プロキシ環境の場合
ユーザ認証なし
$git config --global http.proxy http://proxy.server.com:port
ユーザ認証あり
$git config --global http.proxy http://user:pass@proxy.server.com:port
設定結果の確認
$git config --get http.proxy
参考サイト：ssh over proxyでgithubをアクセスする（Windows）
○通常時編
1.ソースをとってくる(forkした後の自分のリポジトリから～というイメージ)
git clone git@xxxxxxxx.git
2.ソースの編集後、リポジトリに追加
git add .
3.コミット
git commit -m "メッセージ"
4.リモートにアップロードするため、リモートを追加
git remote add リモート名(originなど) master
5.リモートに送信
git push リモート名 master
○初めてのpull Request編
1.通常時編と同様。リポジトリをフォーク＋クローン
2.ブランチを作成 ※決してmasterで作業しない。
git checkout -b (ブランチ名)
ブランチ名はxxSpikeなどSpikeをつけたりdevelopとしたり・・・といろいろあるようだが、見たところ修正点がわかれば何でもいい感じだ
3.fork元のリポジトリを変更追尾用のupstreamとして登録しておく
git remote add upstream git://ｘｘｘｘｘｘ.git
4.ブランチで作業(git add / git commit)
5.fork元を更新し、元リポジトリで更新が行われていないか確認
git checkout master
git pull upstream master
マスターブランチに移動して、pullで更新するそのあと自分のブランチに戻り、差分確認。
git checkout myBranch
git diff master
横着する場合は、リモートのブランチと直接比較する方法もある。元リポジトリのmasterブランチと現在のブランチの差分を比較している。
git diff upstream/master
万が一変更が行われていた場合、rebaseなどを使用し対応。ここは細かい話になるため、その他の詳細記事を参照。
6.pull Request
元リポジトリの差分を取り込んでおり、自分の変更点はbranchにまとまっている！となれば、githubにpushし、その後pullRequestを行う(これは画面から行う)。
git push origin ブランチ名
※originはGitHubのリモート
事前にコミットまとめなさいよ、という話があるかもしれない。実際そうしたほうがいいが、マージをする際に取り込むブランチ上のコミットはまとめることができるので、そこまでするかなという気もする（タイプミスとかは確かにアレだが・・・）。
まとめる場合、rebaseを使用する。こちら を参考。
なにより、小さく速くやる、ということがpull Requestでは重要と思う。
○あるある編
*gitignoreを追加するのを忘れたので、直前の git add . を全部取り消したい
git rm -r --cached .
*git addでの変更内容を事前に確認したい
git status もしくは
git diff --cached
※ファイルの一覧でいいんだよ！という場合は
git diff --cached --name-only
--cachedってなんなの？という場合こちらを参考。
*コミットメッセージに誤字脱字。修正したい
git commit --amend -m "(新しいコミットメッセージ)"
git commit --amend で、単純にコミットの取り消しになる。
*コミット先を間違えた。取り消したい
git reset HEAD^
上記に引き続きとても分かりやすい記事があるのでこちらを参考。みんなHEADとかインデックスとか何言ってんの？という場合にもとても良いです。
*削除したファイルがgit addで追加されない
git add -u
を実行
git add -u
を実行
Scala Lift を Heroku で稼働させる
えらく苦労したが、ScalaのLiftをHeroku上で動かせた。
○前提インストール
Scala (やたら重い気がするが気のせいか？)
SBT Scalaにおけるビルド/パッケージ管理ツール
Lift 今回は下記のGitリポジトリに含んでいるのでダウンロードの必要はないが、一応
後はHerokuツールともちろんGit。Heroku自体へのGitを使用したデプロイの方法はいろいろと解説されているので、ここでは詳しく触れません。
WindowsではSSHキーの作成がめんどいと感じるかもしれませんが、GitをインストールすればGit Bashからssk-keygenを使用できるため、こちらでキー生成を行えばわざわざPuttyなどからやらなくて済みます。
Liftのスタートアップスクリプトはbashで書かれていてコマンドプロンプトからうまく動かなかったりするので、なにかコマンドを実行する際はGit Bashを使うことをお勧めします。
○方法
さっさといこう！ということでGitHubからcloneで。
lift_basic_heroku
こちらのリポジトリをcloneして、あとはReadmeの通りに行けばHerokuへデプロイできると思います。
○前提インストール
Scala (やたら重い気がするが気のせいか？)
SBT Scalaにおけるビルド/パッケージ管理ツール
Lift 今回は下記のGitリポジトリに含んでいるのでダウンロードの必要はないが、一応
後はHerokuツールともちろんGit。Heroku自体へのGitを使用したデプロイの方法はいろいろと解説されているので、ここでは詳しく触れません。
WindowsではSSHキーの作成がめんどいと感じるかもしれませんが、GitをインストールすればGit Bashからssk-keygenを使用できるため、こちらでキー生成を行えばわざわざPuttyなどからやらなくて済みます。
Liftのスタートアップスクリプトはbashで書かれていてコマンドプロンプトからうまく動かなかったりするので、なにかコマンドを実行する際はGit Bashを使うことをお勧めします。
○方法
さっさといこう！ということでGitHubからcloneで。
lift_basic_heroku
こちらのリポジトリをcloneして、あとはReadmeの通りに行けばHerokuへデプロイできると思います。
登録:
投稿 (Atom)