タグ

gitに関するfield_combatのブックマーク (28)

  • layer8.sh

    This domain may be for sale!

  • WordpressをGitで管理する - Tatsuquito

    Wordpressそのものやインストールしたプラグインは頻繁にアップデートされるので、割とまめに対応しなければならない。また、カスタマイズする箇所が増えて来ると、どこを変えたか?わからなくなってくるので、バージョン管理の仕組みを入れてコードを管理したほうが良い。 バージョン管理の中ではGitが一番簡単そうなので、いろいろ調べてみたが、意外とWordpressの管理に使っている情報が少なかった。やってみると簡単にできる上、お客さん向けにステージング環境を提供するのに便利なので、自分の環境の作り方をまとめてみる。 自分の開発環境を図にするとこんな感じ: Macbookの上で走らせているVMWareにUbuntuで開発環境をたて、そこでWordpressのカスタマイズをしている。カスタマイズの対象となるWordpressのコードはCoresever上にあるGitのリモートレポジトリに格納され、U

    WordpressをGitで管理する - Tatsuquito
  • こわくない Git

    「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。Read less

    こわくない Git
    field_combat
    field_combat 2012/11/22
    よくわからず使ってってことがよくわかった
  • 【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC

    追記:たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記2(2011/11/07):commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ | ├─ 一人で使ってるよ |   | |   ├─ 手元に変更を取り戻したいよ(1)(そうだね、add忘れだね派) |   |

    【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC
  • git - 簡単ガイド

    アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト

  • GitHubへpull requestする際のベストプラクティス - hnwの日記

    みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、

    GitHubへpull requestする際のベストプラクティス - hnwの日記
  • 【翻訳】Gitをボトムアップから理解する

    John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます: http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。(詳しくは記事内の最初にも書いてあります) 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git

    【翻訳】Gitをボトムアップから理解する
  • A successful Git branching model を翻訳しました

    Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書

    A successful Git branching model を翻訳しました