もうFTPを利用することは止めて、Gitを使おう。そのほうがメリットが多いよー 2014.02.26 | この方法お勧めです！ | 覚えておきたい どもどもパープルことメガネこと大串です。 最近なにかと涙もろくなりまして、ちょっと身近な人のBlogとか読むだけでも熱いものがこみ上げたりしています。こういうことって今後も増えていくんでしょうね。母親がやたらめったらテレビに向かって泣いていたのも頷ける今日このごろです。 さてGitHubシリーズですね。前回は GitHubをつかって共同開発！ サイトのデザインリニューアルしました !という記事を書きました。もちろん今も共同開発は続いておりまして、次のマイルストーンは月末を予定しております。達成率は25%ですが、なんとなかるでしょう。。。たぶん。。おそらく。 そしてきょうの本題ですね。タイトルの通り、FTPをやめてgitでファイルの送信受信もして

ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える

git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ

タイトルは大目に見てください><。 本内容は危険な操作を伴うのでくれぐれも自己責任でお願いします。 間違いもあったら指摘ください。 ローカル編 自分のローカル環境だけで閉じていて、他の人への影響がない場合に有効です。 リモートにプッシュしちゃってる時は、他人への影響が発生するので危険です。 やらかし１：コミットメッセージに禁止ワード入ってて人生やめたい時 コミットメッセージを修正するのは簡単です。 ファイルの追加なんかもできちゃいます

今日からはじめるGitHub ～ 初心者がGitをインストールして、プルリクできるようになるまでを解説 エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ソースコードの管理はできていますか？ ファイルを修正するときに、修正前のソースコードをhoge.php.bakのようなバックアップファイルとして残し、開発環境をゴミだらけにしていませんか？ エンジニアであれば、チーム開発ではもちろんのこと、個人開発でもGitを用いてバージョン管理していきたいもの。今回は、GitやGitHubをはじめて使う人に向けて、導入から初歩的な使い方までを解説します。 ここではGitの詳細な仕組みには触れません。GitやGitHubを利用したことのない人が、Gitを

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

注意 この記事は、2014年に投稿されたものです。 時代は変わっても運用におけるベースは大きくは変わっていませんが、投稿としては古い内容ですのでご注意下さい。 未だにストックなど多くいただきますので注意事項として、追記させていだきます。 以下本文です。 はい、今更かもしれませんが。俺としてはGitを扱う上で結構重要だと思っている commitやpushの頻度 について書きたいと思います。はじめに断っておきますが技術的なテクとかの話ではないです。ほとんどが 言われてみれば当たり前じゃん 程度の内容だと思って下さい。 ですが、flowとか運用方法 とか gitを使いこなすちょっとしたテク なんかより重要だと思っているのは俺だけでしょうか...？ どの単位でコミットしたりプッシュしていますか？ みなさん、どのような単位でコミットしたりするようにしていますか？未だに 適当にやってる みたいな人がい