このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
![dfltweb1.onamae.com – このドメインはお名前.comで取得されています。](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f3c177ce898ec11ec5480ead6a71b061bbf6c44/height=288;version=1;width=512/http%3A%2F%2Fplus.appgiga.jp%2Fwp-content%2Fuploads%2Ffiles%2F2015%2F02%2Fgithub-webapp_01.jpg)
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は本人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 この記事では、私のいくつかのプロジェクト(仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書かず、ブランチ戦略とリリース管理についてだけ述べよう。 以下では、
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. (英語勉強しないと..) 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 (仕事でDeprecateとか滅多に使わんし) 同僚に聞きつつ10つあげてみた. 以下列挙 (例は実際の同僚やOSS上でのコミットメッセージです.) Add *A to *B AをBに加える
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 (2014年12月17日追記) 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど!と思ったコメントをもとに少し修正・加筆してみました。 (2022年1月4日追記) 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細) 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 (多すぎても悩むので
ベーシックでは、Gitを使ったバージョン管理システムを導入しています。一部のプロジェクトでは先行して導入していたものの、全社的にはまだまだ…といったわけで、よくGitコマンドについて質問されるので、ここで軽くまとめておきたいと思います。 普段は git add / commit / push / pull しかしてない…っていう人向けです。 addしたファイルを取り消す $git reset HEAD ファイル名 更新内容自体は取り消さず、addしてインデックスに登録するのを取り消します。 更新したファイルの更新内容を取り消す $git checkout ファイル名 commitする前限定です。 他ブランチの特定のコミットだけマージしたい $git cherry-pick コミットID とても便利なコマンドですが、cherry-pickを多用するような運用スタイルになっていたら問題なので、
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハー
インストール方法から参考リンクまで。 自分の勉強ついでに、Tigについて基本の すべてをまとめてみました。 合わせて読みたい 【おすすめ】MacのFinderをカスタマイズする魔法のコマンドたち 【おすすめ】これからWebする人はここ読んどけ(HTML/CSS/JS/Ps/Ai.etc) 【おすすめ】Qiitaを使い倒す方法一覧 Tigとは 定義 Tig is an ncurses-based text-mode interface for git. It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands. 要
Gerritを利用して拙作のLhazをオープンソース化してから,1年が過ぎようとしています。ここで,Gerritの良い点,悪い点をまとめます。GitHubやSourceForgeを使用した経験はないので,他の開発プラットフォームと比較した結果ではありません。運用中のレビューサイトはこちらになります。 良い点 gitが身についた Gerritはgitベースですので,gitの使い方が身につきました。add, commitなどの基本的なコマンドはgitのみの運用でも身につくかと思いますが,Gerritではpushやコンフリクトの解決にrebaseが必要だったりして,やや進んだ使い方が身につきます。また,Lhazの開発では,zlib等の外部ライブラリを使用しており,mergeも使ったりしました。 ブランチがGerrit上で可視化されるのも良いと思います。具体的には,zlib等をmasterブランチ
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある(Rails製)。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
git log で変更者、変更日時等の変更履歴が表示されますが、変更されたファイル名を表示するには --stat, --numstat, --name-status, --name-only などで知ることができます。 % git log --stat commit 801fe8c4bd09f91bb2172640c4857acc52f89135 Author: Yuumi Yoshida <yy@ey-office.com> Date: Sun Aug 3 12:15:30 2008 +0900 バグ対応 upload.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit 609aa81ec0a489cdac4cb2398918758f609a47e4 Author: Yuumi Yoshida <yy@ey-
SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) GitクライアントのSourceTreeソースツリーは無料で使えるGitアプリケーションとして人気があります。「SourceTreeの基本的な使い方はバッチリ! だけど、まだまだ使っていない機能があるなぁ」なんて人も多いのではないでしょうか? そんな人へオススメの知っておくと便利な機能を5つ紹介します。 ※本記事は2024年4月現在のmacOS 14.4.1、SourceTree 4.2.7で解説しています。Windows版のSourceTreeでも同じ手順で利用できます。 はじめに - SourceTreeとは? SourceTreeはGit / MercurialのGUIクライアントで、Atlassian社から無償で提供されています。Windows
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
こんにちは、gumiの奥田です。 この前は、gitについてとコマンドを紹介しました。 今回は、知っていると便利なコマンドをご紹介したいと思います。 ログの確認 $ git log ログを表示します $ git log -2 ログを2件表示します $ git log --since=2.hours 最新2時間のコミットを表示します コミットの打ち消し revertコマンドは、打ち消すコミットを消去するのではなく、パッチを当て新たにコミットすることで、 打ち消すコミットをなかったことにします。打ち消されるのは、指定したコミットによる変更だけです。 打ち消そうとするコミット以降のコミットには影響がありません。 1. 追加した箇所のコミットを調べ、ハッシュを確認します。 $ git log commit ba4959244138c28b9db76c615ded02761bf65477 Author
git rm 使い方 ワークツリーとインデックスからファイルを削除する file.txt を削除するには git rm file.txt とする。このとき、ファイルは削除されてワークツリーからなくなり、 インデックスに削除の情報が追加される。 また、拡張子 .txt のファイルを削除するには git rm *.txt とする。このときに、*.txt にマッチするがリポジトリに登録されていないファイルが あるときには fatal: pathspec 'test4.txt' did not match any files というようなエラーが出る。 これは「–ignore-unmatch」オプションをつけると無視してくれる。 git rm --ignore-unmatch *.txt 再帰的にディレクトリを削除する ディレクトリ dir の中のファイルを再帰的に削除するには git rm -r
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く