ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
手元のアプリでなんとなくERBを使っていたのですが、 Haml使いたくなったので、置換してみました。 dhl/erb2haml: Simple script to bulk covert ERB files in a Rails app to Haml 使い方 Gemfileに突っ込んでbundleすれば、以下のrakeタスクが実行できるようになります。 rake haml:convert_erbs # Perform bulk conversion of all html.erb files to Haml in views folder rake haml:replace_erbs # Perform bulk conversion of all html.erb files to Haml in views folder, then remove the converted html
変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 ```diff:余談...diffのシンタックスハイライト初めて使ったけど良い感じですね $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます Please enter the commit message for your changes. Lines starting with '#' will be ignored, and an empty message aborts the commit. On branch commit-v You are currently bisecting, started from branch 'test-git-bisect'. Changes to be committed: #
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
複数人でgitリポジトリを管理しており、ほかの誰かがリモート上のあるブランチを削除した場合 ローカルリポジトリ上で git branch -r とやると、消されたはずのブランチが出てきてしまう。 さらに、ここで git push origin :deleted_branch とやってみても error: unable to delete 'deleted_branch': remote ref does not exist error: failed to push some refs to '/tmp/remote.git という感じでエラーが出てしまう。 こんな時は git remote prune origin というコマンドをたたいてやると、リモートの状態を再度取得してくれる。 ちなみに、pruneというのは取り除く、とか切り取る、とかそんな雰囲気の単語らしいので リモート上で削除
Every project and team is different. Repository Hosting lets you choose the repository system that is right for your project. Subversion Hosting: the industry standard successor to CVS, Subversion is the perfect system for small teams looking to get up and running quickly. Git Hosting: the distributed version control system that is taking the development world by storm, Git has a slightly higher l
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました GitHubでは人気のあるリポジトリをGitHub Trending repositoriesとして紹介しています。世界中の開発者が注目しているだけあって、流行の技術であったり、逆にずっと定番となって使われ続けているソフトウェアも出てきたりします。 今回紹介するgit-trendはGitHub Trending repositoriesとリストアップしてくれるCLIツールです。わざわざWebページを開かずに手軽にチェックできるようになります。 git-trendの使い方 git-trendのインストールはRubygemsで簡単にできます。 $ gem install git-trend 後はコマンドを叩くだけです。こんな感じで一覧が返ってきます。–no-descriptionとつけ
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
はじめに さだまさしさんの作る曲の魅力とは何でしょうか？ もちろんメロディもすばらしいのですが、やはり歌詞のすばらしさを挙げる人が多いのではないでしょうか。 この時期に聴く「遥かなるクリスマス」とか本当にいいですよね。 というわけで、さださんの魅力のひとつである歌詞をファン以外の人にも伝えるためのgit sadaコマンドを作ってみました。 こうなります gitのコミットメッセージがすべて「北の国から」の歌詞に変わります。 実際にgit-lfsのforkで試しにやってみました。 あたかも「北の国から」の歌詞の魅力が海外の方にも伝わったように見えますね。 やり方 .git/configにこんな感じでエイリアスを設定します。 たったこれだけでgit sadaコマンドが使えるようになります。
皆さん、tigコマンドを活用していますか？ tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細（diff view）が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
Git - Book 読み終えたメモを残そうとしたら、 私が読んでいたのは第1版で、2014年に第2版が出たことを先ほど知って 少しショックを受けています。 Git2.0対応しているらしいですが、まぁ基本そこまで違いはないはずなので 初めて知った点などをメモしておきます。第2版はそのうち読むかも。 結構な量があるので、とりあえずGit触りたい人向けではないですが、 Gitを正しく知るという点では、是非とも読んでおいて損はないでしょう。 何しろ無料ですし。 知らなかったことなど commitに近いタグとそのタグからのコミット数、sha1の一部を使った名前を作成 git describe トリプルドット git log master...experiment # experimentからはたどれるが、masterからはたどれない全てのcommit (masterに含まないexperimentロ
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中に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のcommit直前に自動でrubocopによるスタイルチェックが行われるように設定します。 なぜスタイルチェックが必要なのか GitFlowあるいはGitHub Flowにのっとり複数人で開発する場合、Pull Requestベースのコードレビューが重要です。 Pull Requestでは実装が仕様を満たしているか、クラスやメソッドの設計が適切か、ナレッジを共有できているか、といった観点から、議論を交わし、チームとしてコードを良くしていきます。 その際に、 「1行の長さが長過ぎませんか？」 「classとdefの間にスペースが開いています」 「1メソッド内での分岐やメソッド呼び出しが多すぎます」 と言った、コーディング規約についての議論があると、下手をすると宗教戦争になり、生産性が高いとは言えません。 事前にコーディング規約を決めていても、つい油断して規約違反のままコミッ
以前、われわれは、いかにして変更点を追うかという内容で発表しましたが、 その時書き忘れてたことの補足的な記事です。 GitHubでのChangeLogの扱いについての話 このスライドは、ChangeLogから詳細を追う方法を知ることで、転じて分かりやすいChangeLogを書くことができるようになるのではという話でした。 スライドでは、ChangeLogの追い方としてBabel 5.3.0を例としてどうやって、このChangeLogから詳細を見ていくかについて話していました。 このBabelのChangeLogの問題点としては、変更点については書かれているのですが具体的にどういう変更だったのか、また関連するIssue/Pull Requestへのリンクがないため、ChangeLog単体では詳細がわからないという問題があったので例としていました。 Babelを例に見ると、変更した内容を1行の
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 （これ以降の記事中のリモートは全てoriginとします。） このコロンは何？？ リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか？ 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
