The Best Solution to Merge Your CodeMergify is a complete solution combining efficiency and customization. Mergify adapts to the way your team works and let you define your own rules. Why should you use Mergify to merge your pull requests?
2019年7月にGitHubにマージしたブランチが自動削除される機能が入ったためこの記事は内容の非推奨です。 Automatically delete head branches of pull requests - GitHub Changelog ブランチの自動的削除を管理する - GitHub Docs 以下は古い記述 前置き マージ済のブランチは基本的に消しても問題ないので、GitHub上には進行中のブランチだけがあるきれいな状態に保ちたいところ。 PRをマージした後にブランチを消すボタンが出るんですが、チームで開発してるとどうしても消し忘れる人が1人はいるので 1CircleCIで定期的に消すようにしました 前提 GitHub CircleCI 2.0 準備 GitHubにpushするための権限が必要なので「Settings -> Checkout SSH keys」でuser
地味に便利なものから慣れるとなくてはならないものまで、GitHubを見やすく・使いやすくしてくれる拡張機能を紹介します。 ここではすべてChromeの拡張機能として紹介していますが、中にはその他のブラウザでも利用可能(主にFirefoxのアドオン)なものもあるので、それらは併せて紹介している各拡張機能のGitHubページなどから辿ってください。 以下で紹介している拡張機能の一部は、プライベートリポジトリでも利用できるようにするなどの理由でアクセストークンを設定する必要があります。 入力する旨が表示されたり各拡張機能の紹介ページに設定方法として記載もされていますが、ほとんどの場合は「Developer settings」から移動した先で「repo」を選択して作成し、出力されたコードを設定欄に記述します。 GitHub File Icon screen shot by GitHub File
Here's what makes GitLocalize a great fit for GitHub-based localization projects: Your repository is the single source of truth. GitLocalize tracks changes in both the source and translated documents and pulls them into the project. Translations added on GitLocalize are sent to the repository via a pull request. Have existing translations that need to be imported? No problem! Those will be synced
皆さんこんにちは. 現在はfluctにてfluct DRという広告配信システムの開発を行っております, 大関です. GitHub上でのチーム開発では, レビューの依頼や, CIが通ったことを確認した上でのPull Requestのマージといった複数の作業が発生しますが, これらはGitHubのUIを複数回クリックする必要があり, 非常にストレスフルな作業です. 本稿では, こうした定形作業を自動化するbotとしてpopukoを開発・導入することで, 我々開発者のストレスを軽減するとともに, より堅牢かつフィードバックの多い開発が実施できるようになった事例を紹介します. GitHubでの開発はとてもクリック操作が多い 前段でも述べたように, GitHubを用いたチーム開発においては, 数多くの定形作業が存在します. コードレビューの可能な人を探してレビューを依頼する, 依頼の度に対象者をAs
@hisaichi5518 .tigrc とかで設定して、閲覧している commit をキーボードショートカットで開けるようにしておけば、commit のページに Pull Request へのリンクが含まれていそう— ホームページビルダー (@r7kamura) 2017年2月7日 ツイッターでボソっと言ったら、良い感じのアドバイスをもらったので、雑に会社のGHEだけ対応するかと思って対応した。 hub インストールして .tigrc に以下を追加して、コミットログ見てるときに shift+pを押せば、コミットページに飛ぶので、そこからプルリクへ遷移出来る。 bind generic P @sh -c 'hub browse -- commit/%(commit)'直接プルリクに遷移したいと思って頑張ろうとしたけど、複数プルリクがあるとかめんどくてこれが一番かなと思った。 追記: git
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
「間違ったコミットをリモートにpushしちゃった!取り消したい!」ってときの操作。上イメージのようにgithubに誤ったpushをした場合を想定して解説してみます。 下記コマンド打つ。 HEAD~2は「直前の2つのコミットを修正対象とする」という意味になります。3つ前のコミットを取り消したい場合はHEAD~3としてください。するとこんな画面が出てくる。 取り消したいコミットを削除して保存します。この場合、2行目のコミットが誤りなので2行目を削除して保存します。うまくいくとこんなメッセージ。
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか?私はダメです。ごめんなさい。(´・ω・`) WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model(有志の方による日本語訳)にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
Gitで間違ったコミットをリモートリポジトリに push してしまった後に、それを無かったことにするには、リモート側での作業が必要だと思っていたのですが、ローカルからの操作でもできることがわかったので備忘録的に書いておきます。 次の状態にあるとします。アルファベットはコミットだと思ってください。 リモート: A-B-C master ローカル: A-B-C-D masterローカルで変更を加えてDの状態になっています。 git push すると次のようになるのですが、 リモート: A-B-C-D master ローカル: A-B-C-D masterここで、D は間違いだったと気づきました。 リモートリポジトリの master のバックアップ用のブランチを作ります。これは必須ではありませんが、念のため。 % git push origin master:master_bakこれで次の状態に
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
「Working In Progress」な WIP Pull Request という概念を知ったのでメモ。 【元ネタ】 Github を使って雑誌原稿を書く - naoyaのはてなダイアリー git commit --allow-empty を使った WIP PR ワークフロー - Qiita WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog github を用いた開発フロー テンプレート pull request を利用した開発ワークフロー // Speaker Deck 「Working In Progress」な WIP Pull Request とは、ソースの
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く