タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

gitに関するkohkimakimotoのブックマーク (5)

  • Gitコミットメッセージの7大原則 - rochefort's blog

    タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま

    Gitコミットメッセージの7大原則 - rochefort's blog
  • Gitでやらかさないための事前予防策 - Qiita

    Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある

    Gitでやらかさないための事前予防策 - Qiita
  • Gitのコミットメッセージの書き方 - Qiita

    Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 (2014年12月17日追記) 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど!と思ったコメントをもとに少し修正・加筆してみました。 (2022年1月4日追記) 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細) 日語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 (多すぎても悩むので

    Gitのコミットメッセージの書き方 - Qiita
  • git pushでバーチャルホスト設定やデプロイを自動で行う | Basicinc Enjoy Hacking!

    ランチを手軽に切れるのが魅力なGitちゃん。 ただ、Webアプリケーションとして、気軽に切った先進的で先鋭的で危ない感じのその新ブランチを他の人に動作を確認してもらうのは、ちょっと面倒。 開発者ならpullってdiffって見ろよって感じなんだけど、営業さんだったりディレクターさんだったりだとブラウザで確認できなくちゃね。というわけで、開発サーバにバーチャルホスト切って、サブドメインとかで設定するわけなんだけど、それが手間。 ブランチは気軽に切れるのに、環境は気軽に作れない。 post-receive を使おう Gitにはpost-receiveという強力な仕組みがあるので、これを使います。 $git push origin new-branch って新ブランチをリモートリポジトリにpushしたら、http://new-branch.example.com/ ってサブドメインで閲覧できるよ

    git pushでバーチャルホスト設定やデプロイを自動で行う | Basicinc Enjoy Hacking!
  • git の運用指針 - Cube Lilac

    ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが(ただのコミットマシーン状態)、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。 前提 まず始めに、現在のプロジェクトの状況は下記のようになっています。 開発は 1 人のメインコミッタ(私)と数人のサポートコミッタ(アルバイト等)で行われる メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態 サポートコミッタに対しては、基的に 1 機能(1 チケット)を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあ

    git の運用指針 - Cube Lilac
  • 1