git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
翻訳におけるgit/githubの使い方ふりかえり - 不悔必省
gitは一人では多少使ってたが、コラボレーションは初めてだったので、いろいろ変なことをしていたようだ。id:nekopや、id:tokobayashiと話した結果を元に使い方をまとめてみる。これは、このやり方がいいんじゃないかな？と思っていることなので、間違ってるかもしれない。次のファイルの編集はこれに従ってやってみて、おかしなところがあれば変更する。 1. fork 今回のマスターリポジトリは、arquillian/arquillian.github.com。これをforkする。 2. clone forkしたら自分のアカウントにleathersole/arquillian.github.comができたので、これをローカルにclone git clone git@github.com:leathersole/arquillian.github.com.git cd arquillian.
アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい！ - ザリガニが見ていた...。
アリスとボブのGitシリーズが本になりました！ アリスとボブのGit入門レッスン アリスは迷っていた。現状のshowメソッドは固定されたメッセージしか出力しないが、理想的にはユーザーの条件によって変化させたいと。 しかし、その機能を実装するためには結構な大改修になってしまう。果たして今の自分の技術でちゃんと完了させることが出来るだろうか？この機能追加をやるべきか、このままにするか...。 アリスはこの修正が失敗に終わった時のことを考えて、ボブに連絡しておくことにした。「失敗したらごめんね。」と。（なんて無責任なアリス...。） 連絡を受けたボブは、アリスの機能追加には大賛成。ボブ：「ただし、新しいブランチを追加して、そこで作業くれ。」と。アリス:「ブランチ？？？」 アリスはブランチを理解できていないが、とりあえず、ボブに説明された手順をそのままやってみることにした。アリス：「習うより、慣れ
ウノウラボ Unoh Labs: 秘伝のペケペケrcをつぎたす仕事
こんにちは。murahashi です。 秘伝のペケペケrcの継ぎ足し方―あるいはbashrc, vimrc, screenrc それぞれについて別の場所のファイルを読み込む方法、再読み込みする方法―をまとめました。 どこかからコピペしてきたドットファイルを継ぎ足し継ぎ足しで自分に合わせた設定をつくり、それをいろんなところに持ちまわっている人は多いと思います。どうせならということで github や bitbucket や coderepos に公開している人もいるでしょう。 私も dotfiles という1ディレクトリにファイルをまとめて github にpush、使いたい場所でgit cloneして ~/dotfiles/.bashrc へのシンボリックリンクを ~/.bashrc に置いて「やったー」と喜んでいました。 ただ、この方法だとサーバの環境によって変えたい部分が出てきたとき
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
Island Life - gitのワークフロー
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...ループを使わずに1から100までMore... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチ
gitだからこそできるチケット駆動開発のやり方 - kunitの日記
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
今更ですがgit入門 - プログラミングノート
ふとiPhoneのサンプルコードとか入れておくと便利かなと思い、使ってみたくなったので環境を整えてみました。 インストール gitのサイトからv1.6.2.3のソースを取得してインストール。 $ tar zxvf git-1.6.2.3.tar.gz $ mv git-1.6.2.3 /usr/local/src $ cd /usr/local/src/git-1.6.2.3 $ ./configure --prefix=/usr/local/git $ make $ sudo make install githubに登録 アカウントは少し前に作っていたのでssh関連から。 1. public key を登録 アカウントページからpublic keyを登録します。public keyは以前作っていたものをそのまま利用しています。さくらサーバでsvn+sshを利用する方法(Linux/Mac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://prevs.io/
ChangeLog を支える英語
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。