![https://www.freia.jp/taka/blog/windows-native-ssh-client/index.html](https://cdn-ak-scissors.b.st-hatena.com/image/square/16b5d57ad5a843211053eb582df0d25a7d7a46e8/height=288;version=1;width=512/https%3A%2F%2Fwww.freia.jp%2Ftaka%2F_images%2Fgit-pull-with-windows-ssh-client.png)
はじめに こんにちは、会員管理システムSMOOSYの開発と運用を担当している大橋です。 エンジニアの主な仕事は、システムやサービスを作ることです。そしてどのシステムでもたくさんの文言が使われます。小規模なシステムなら使われる文言を画面や機能ごとのソース(定数クラスなど)の中で定義することもありますが、規模の大きいシステムであれば、それら全てを外部のプロパティファイルにまとめるという管理方法がよく使われています。アトラスもこの方法を使ってメッセージを管理しています。 一般的なメッセージ管理の仕組み 今時のシステム開発はGitHubなどを使ってバージョン管理をしているケースが多く、システム自体が多言語に対応することもあります。例えば、日本語と英語に対応している場合、message_ja.propertiesとmessage_en.propertiesの2つのファイルを用意する必要があります。さ
概要 GitHub上のPull Request(以下、PR)をレビューする際に、そのPRを実際に動かして挙動を確認したい場面がある。しかしながらPRのHEADが最新のmaster(=マージ先ブランチの内容)を反映しているとは限らない。つまり本来であれば動作確認のためにローカルにPRのHEADにチェックアウトして、自分でマージコミットを作る必要があるが、実はリモートがGitHubであれば既にマージ先ブランチの内容を反映したマージ済みブランチを作ってくれている。しかし通常ではそこにアクセスしないようになっているので、そこにアクセスできるようにしたい。 変更内容 Git config を変更する .git/config を編集し、 remote ブランチの fetch するものの中に以下の行を追加する。 [remote "origin"] url = git@github.com:windyak
GitHubにIssueとPull Requestのテンプレート機能がつきました。("Issue and Pull Request templates" - GitHub)とても便利な機能なので、みなさんも使ってみてください。 ※本記事は公式の日本語ドキュメントが作成される前に作成され、メンテナンスされていません。ぜひ公式ドキュメントの方をご覧ください。 ▼ 「公式ドキュメント:テンプレートを使用して便利な Issue やプルリクエストを推進する」 ---- 以下いつか消します ----- ファイル配置場所 リポジトリ直下、もしくは.githubフォルダーへ特定の名前がついたファイルを配置することで、Issueを作成するときや、プルリクエストを行うときの説明テキストのテキストエリアに、自動でテキストが挿入されます。 ISSUE_TEMPLATE.md - Issueを作成するときのテンプレ
そういうのを昔どっかで聞いて、ネタじゃないの?とか思って居たんですが、ふとさっき思い出して、試してみたら、普通にcheckoutできた。 % svn checkout https://github.com/masasuzu/resume A resume/branches A resume/trunk A resume/trunk/README.md Checked out revision 5. commitもできる。 % svn commit -m 'cpan => CPAN' Authentication realm: <https://github.com:443> GitHub Password for 'masasuzu': Committed revision 8. なるほど。ちゃんと反映されてる https://github.com/masasuzu/resume/comm
株式会社オズビジョンの@terra_yuccoです。 本日、いつものように貯まっているPull Requestを見ようとGitHubの画面を見たところ、 Discussionの見え方が違い「?」と思っていました。 そこでチームメンバーから「GitHubのレビュー機能がめっちゃパワーアップしました。」と 共有されたGitHubのリリースノート?を読んだので、Tipsを共有します。 Tips Pull Requestに対して、総評という形でReviewを書けるようになった Reviewには以下の種別を付けられる Comment: 軽微な指摘、コメント Approve: 承認 Request Change: 修正依頼 Request Changeが付いたPull Requestは、AdminもしくはRepository Owner以外は、 修正しないとMergeできない Pull Request
結論 ここに書いてある 注意事項 だいぶ懐かしい記事ですが…突然、「Diffに表示しないなんてGitHubの価値を損なうものだから記事を非公開にするべきだ」というご指摘をいただいたので、念のため追記。 Diffに表示しない、ってことは当然PRにも見えません。 レビューされない怪しいコードが紛れ込むリスクを抱えることになります。 せいぜい自動生成分だけを非表示にして、CIの中で再生成、差分が出ないチェックを入れるなど、ガードの手は考えておいたほうが良いでしょうね。はい。ご利用は計画的に。 背景 mockeryだったり、swagger-codegenだったり、go-bindataだったり… GitHub上に自動生成されたコードを載せている場合、PRやcommitの詳細画面でDiffが邪魔になることがあります。 .gitignoreでそもそも自動生成コードをリポジトリに載せない generate
基本的な機能はみんなほぼ同じ。 GitHubのissueをかんばんボードとして表示してくれるサービス。 ZenHub.io 特徴 GitHubサイトに拡張機能として埋め込まれるのでGitHubとの統一感がある FileUpload機能を強化してくれる +1ボタンが設置可能になる 価格 個人/非商用/OSSは無料 Organizations単位での課金 1-5users : $25/month 6+users : $5/user/month 26+users : $3.75/user/month Codetree 特徴 この中で一番後発のサービス 複数リポジトリのissueをまとめて表示できる 専用のシンプルなビュー OrganizationsやProjectは独自に作成して、GitHubのリポジトリを紐付けるような使い方 価格 3users, 15projects : $24/month
ProductIntroducing unlimited private repositoriesWe couldn’t be more excited to announce that all of our paid plans on GitHub.com now include unlimited private repositories. GitHub will always be free for public and open source… We couldn’t be more excited to announce that all of our paid plans on GitHub.com now include unlimited private repositories. GitHub will always be free for public and open
なつねこメモ主にプログラミング関連のメモ帳 ♪(✿╹ヮ╹)ノ 書いてあるコードは自己責任でご自由にどうぞ。記事本文の無断転載は禁止です。 2016/04/02 GitHub のリポジトリをユーザー間で移動するGitHub のリポジトリを、例えば、プライベート用アカウントから仕事用アカウントへと、 移動させたい場合などの方法です。 移動元のアカウントを @A、移動先のアカウントを @B とします。 また、移動するリポジトリを TestRepository とします。 まず、@A/TestRepository にアクセスし、[Settings] > [Collaborators] にて、 @B を collabotator として追加します。 リポジトリ名と移動先のアカウント名を訊かれるので、入力します。 この場合は、リポジトリは TestRepository 、アカウント名は B です。 入
FuelPHP 1.7.3をインストールしようとすると以下のようにトークンを聞かれることがあります。 Could not fetch https://api.github.com/repos/fuel/auth/git/refs/heads?per_page=100, please create a GitHub OAuth token to go over the API rate limit Head to https://github.com/settings/tokens/new?scopes=repo&description=Composer+on+<servername>+2015-06-26+0933 to retrieve a token. It will be stored in "/home/<username>/.composer/auth.json" for fut
[GitHub] 公開鍵登録の際に、Permission denied (publickey). が出続ける場合の対応 (vagrantからsshする場合の注意も)GitGitHubVagrant $ cd ~/.ssh $ ssh-keygen -t rsa -C "your_email@example.com" Generating public/private rsa key pair. # Enter file in which to save the key (/Users/you/.ssh/id_rsa): github_id_rsa(ここは任意) Enter passphrase (empty for no passphrase): (ここも任意) # Enter same passphrase again: (ここも任意) $ ssh-add ~/.ssh/id_rsa
まず、クリックしてみてください Issue作成はこちら GitHubのIssueは、URLにparamsを渡すことで、デフォルトのvalueが入れられます。 ※paramsの渡し方は、/issues/new?title=test&body=contentのようにします。 バグ報告はこちらとかアイディア投稿などのリンクをREADMEなどに置き、みんなそれに従ってIssueを作成してもらいましょう。 指定できるparams 指定できるパラメーターは以下です。 params一覧 title body assignee labels milestone ※ラベル、マイルストーンはcontributorsのみ使用可能 文字列のエスケープ URLに入力するので、改行コードなどをエスケープする必要があります。 文字 エスケープ後
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です! 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
ラクスルの利根川です。 ラクスルも最近の多くのテック系企業のようにソースコードの管理にgithubを使っています。 ラクスルがgithubに来るまで raksul.com をオープンして間もない2011年10月からソースコードの管理をgitにて行っておりましたが、2013年12月に「コードレビューとかプルリク運用とかそろそろしたいよね」とgitlabを使用していました。 ただ、過去の1万以上のcommitのせいか、当社だとgitlabの挙動が正直安定していなかった(が、その修正にpull requestを送る程の余力は無い)のもあり、当社でもgithubにてソースコードを管理することになりました。 githubへ移行する時 1.Sign UPする githubの価格表に記載がありますが、当社の場合は10 private repositories で足りるので、bronzeをsign upし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く