GPG鍵を作って運用し、Git(hub)やMercurialで自分が書いたコードに署名をする - kuenishi's blog
自分が書いたコードに署名をしておくことはプログラマの常識であり基本動作です（かくいう私もメールは署名してないけど…）。なので私も一人前のプログラマになるべく、自分が書いたコードに署名をするようにしてみた。 GPG 鍵を作ったり準備したり GnuPGのインストール@MacOS $ sudo port install gnupg 鍵をつくります。有効期限は2年間。もし秘密鍵が漏れた場合でも、2年経てばほとぼりが冷める。 $ gpg --gen-key gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent p
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
コミットメッセージのルール - Opacities
2014-11-22 コミットメッセージのルール 開発でGit(Github)を利用している時、コミットメッセージは後からログを見返すときにとても大切なものだけど、 普段適当に記述しているのもあって、改めてルールを書くことにした。 コミットの粒度 コミットの粒度では、何かしら一つの作業を終えたら・・・という粒度でコミットすることにする。 具体的には ある範囲のUIを実装した時 何かしらのコードを削除した時 バグを潰した時 など、比較的作業単位で細かくコミットするようにする・ コミットメッセージの内容 1行目 / 内容の要約 例 modify serarch button for product menu 2行目 / 空行 空行にする理由としては、可読性や要約と内容を分離するためにある。 3行目 / 本文 実際に何をやったのかを書く。長すぎるのもダメなのでだいたい60字ぐらいでまとめるよ
gitworkflowについての雑感 - 放牧日記
誰得UNIX-Blog: git-flowでもgithub flowでもない、Git本家推奨のワークフロー http://t.co/WC3NmN0Yy3 @troter の熱い解説を待とう— V (@voluntas) 2014, 2月 2 振られたので。詳しい内容はリンク先をどぞー。 gitworkflow 日本語訳 git reset 特徴的というか、僕が「やっぱgitらしいなー」と思ったのは、git reset <branch>を積極的に利用している点です。 gitworkflowでは4種類の統合ブランチを用意していますが、そのうち2種類が使い捨てのブランチというのが面白いです。 maint - メンテナンスリリースはここから。時折masterへマージする。 master - 機能リリースはここから。 next - 使い捨て。機能リリース(masterからのリリース)後にgit re
Linus君がボクを後継者に指名した理由 - Gitメンテナー 濱野 純氏
今やソースコード管理システムの標準となっている「Git」（関連記事）。作者のLinus Torvalds氏から指名され、メンテナーとして責任を負っているのが現在米国のGoogle本社に勤務する濱野純氏だ。濱野氏に、メンテナーを引き継いだ経緯、Googleでの仕事などについて聞いた。 Gitコミュニティはどのように活動しているのですか。 本体の開発は、デザインからコードレビューまで、すべてGitメーリングリストで行っています。最近のリリースには、それぞれ60人から80人程による変更が入っていますが、常に活動している主要な開発コミュニティ参加者、と言えるのは10人程度です。 開発者でない人たちで#git IRCチャネルとか、stackoverflowなどでエンドユーザーのサポートをしてくれる人たちの数はもっと多いと思います。この人たちも、Gitコミュニティの重要な仲間です。 Gitコミュニティ
iOS開発でGitを利用する際のTips - blog.ishkawa.org
ちょっと今更な感じもありますが、iOS開発でGitを使うときのTipsを紹介します。 Gitそのものの使い方は理解している前提のもとで書きます。 バージョン管理する対象 Xcodeのプロジェクトにはバージョン管理する上で結構余計なものが入っています。 Gitで管理すべきでないもの Xcodeの作業データ Xcodeのプロジェクトは.xcodeprojですが、こいつ自身はディレクトリになっていて project.pbxproj project.xcworkspace xcuserdata というファイルが入っています。このうち、Gitで管理するべきものはproject.pbxprojです。 その他のものはXcodeの状態(グループを開いてるかなど)を管理しているものなので、 プロジェクトのバージョン管理対象としては適切ではありません。 ビルドデータ xcodebuildコマンドを実
コンフリクトした xib ファイルを上手にマージする - Qiita
本稿では、 Git でブランチをマージした際にコンフリクトした xib ファイルの衝突解決手順を解説する。 追記： Xcode 5 から導入された新しい xib フォーマットではコンフリクトが起こりにくくなっている。また、コンフリクトした場合に手作業で xib ファイルを編集することも、以前のフォーマットと比べれば容易になっている。本稿では以前のフォーマットを使っていることを前提に話を進める。 ステップ0：コンフリクトの解決をあきらめる Xib ファイルをテキストエディタで編集してコンフリクトを解決しようなどと考えてはいけない（変更がごく小規模な場合を除く）。コンフリクトした xib ファイルは捨てて素直に作り直すのがよい。ただし、記憶を頼りに変更を再現する必要はない。 Xib ファイルの要素は コピー&ペーストできる ので、変更点の移植は比較的簡単にできる。 ステップ1：ベースにする x
リリース先輩というIRCボットを作った - 鳩舎
こんにちは、皆さんgit使いこなしてますか？僕は全然です。 ところでgit個人的に使う分にはいいですけど、会社の許可取るのとかは大変ですよね。できる限りSVNで管理したい。 ということでとあるチームではgitで基本的にソースコードを管理して、デプロイ時はsvnに置く、というようなことをしています。なんだか二度手間な感じもしますが、まぁやっておけばいいのであればやっておきましょう。 ところがどっこいgit-svnはとてもめんどくさい。めんどくさいしgitに慣れきった人間はsvnでコミットすることができない。できないなら機械に任せよう。 ということでどうせ毎回同じ事をするので「リリース先輩」というIRCボットを作って、先輩によろしくやってもらうことにしました。 リリース先輩 IRCで rosylilly: release_senpai: 先輩、リリースの準備お願いします！ release_se
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
小規模チームでのGithub利用開発 - Mandy Code
気づくと1週間経っている恐怖(´ω｀) いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。 僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。 ベースはgit-flow Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。 一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。 そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。 リリースまではmasterと
ScalaでGithubクローンを作り始めた - 新・たけぞう瀕死の日記
職場ではここ数年Trac + Mercurialを使っているのですが、リポジトリを作成したりユーザを追加するのに毎回サーバ上でスクリプトを叩いたりするのが面倒なのと、SourceTreeを使えばチームメンバーのみんなも直感的に使えそうなのと、あとTracよりもGithubのほうがIssueやWikiが使いやすいということでGithubクローンへの移行を検討しています。 IssueとWikiは必須なので、消去法でGitLabを試しているのですが、インストールがなかなか面倒な上にバグも多いとのこと。GitblitはJavaベースらしく導入は簡単らしいのですが、これはリポジトリビューアのみでIssueやWikiなどの機能は備えていないようです。 しかしこの手のツールってなんで揃いも揃ってRubyとかPythonのようにインストールの面倒なもので実装されてるんでしょうか。Javaで実装されていれば
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
gitの小ネタ - 桜花な日々
git使ってて気になったことのまとめ。 自分のための備忘録 文字化け git diffなどで文字化けするときは以下の設定を行えばいいようです。 % git config --global core.pager "lv -c" http://d.hatena.ne.jp/takihiro/20100523/1274567613 git pullができない git pullしようとして以下のメッセージが出る場合。 Enter passphrase for key '/home/**/.ssh/id_rsa': You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
Jenkinsで外部パラメータで与えたブランチを対象にビルドできるようにしておくと凄惨性あがって墓ドル - ( ꒪⌓꒪) ゆるよろ日記
テストが終わるまでの時間で書いてみる。 Jenkinsでジョブを実行させるときに、外部パラメータで任意のブランチを対象にビルドできると墓ドル。 例えば、自分のローカルブランチをマージするまえに、テストが通るか確認したい場合とか。 そんなのローカルでテストすりゃーいいじゃんって言われるかもしれないが、 テスト全部通すのに時間が掛かるようになってると、とりあえずCIに実行を投げておいてあとで確認するほうがずっと効率がいい。 F.Y.I: Building github branches with Jenkins ジョブの設定 「ビルドのパラメータ化」にチェックをつけて、以下のようにbranchって名前のパラメータを設定しておく。 「ソースコード管理システム」で「Branches to build」のところに、設定したパラメータである"$branch"を入れておく。 ジョブの設定は以上。上記の方
目からうろこ！日本一わかりやすくGitの本質を解説してみた · DQNEO日記
Gitの本質は「コミットオブジェクトのチェーン」 コミットには親子関係がある。 子は親を参照している。 子の名前（＝コミットハッシュ値)が特定できれば先祖をたどれる。 コミットオブジェクトがチェーンのようにつながっているので、「コミットオブジェクト・チェーン」と理解しましょう Gitとは、コミットオブジェクトのチェーンなのです。 （専門的には「オブジェクトグラフ」と言います） ブランチとは枝のことではない ほとんどの初心者が勘違いしていますが、ブランチとは「枝」のことではありません。 ブランチの正体は「立て看板」です。 「ラベル」といってもよいでしょう。 それは、コミットオブジェクトにつけられらた「別名」のことです。 下記の図でいうと、"branchX"とはコミット"C"を指します。 「アメリカ大統領」という言葉と「バラク・オバマ」という言葉は、同一人物を指しますよね？ まさにそれといっし
ウノウラボ Unoh Labs: git-svn駆け込み寺
こんにちは。murahashiです。 gitやgit-svnを使うにあたり、試したことや引っかかったことについて、yukiのエントリ ウノウラボ Unoh Labs: subversionリポジトリでもgitが使えるgit-svn のつづきを書いてみました。 Q. ブランチ名を長くしてしまったので手打ちするのが大変です A. bashでgitコマンドを補完します gitのコマンド補完は git-completion.bash が便利です。 fedoraにyumでgitを入れた場合には下記場所にあります。 /usr/share/doc/git-VERSION/cntrib/completion/ 自分の見える場所にgit-completion.bashがなければ、インストール済みのgitと同じversionのgitのソースをダウンロードします。 cntrib/completion/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 開発効率をUPする Git逆引き入門: 松下雅和, 船ヶ山慶, 平木聡, 土橋林太郎, 三上丈晴: 本
英語コミットコメントに使えるオシャレフレーズ集
layer8.sh