GitHub - rhysd/git-brws: Command line tool to open repository, file, commit, diff, tag, pull request, blame, issue or project's website in browser for various repository hosting services.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Git: The Beginner's Guide to Understanding Core Version Control Concepts
Git is a vital tool in the toolbelt of any developer. For example, just the other day I was able to fix a major problem I had pushed to production (totally my fault) in about 20 minutes. This would have probably taken me days to fix without Git. For those just starting to learn dev - don’t skip learning (and actively using) Git. Yesterday I was able to fix a major problem I pushed to production in
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
GitHub のプルリクエストを fetch しとくと便利 - HWPS別館
GitHub や GHE を使って多人数で開発していると，プルリクエストを横断して試す必要が頻繁に発生すると思います． プルリクエストを次々に試したり，#30 と #31 をマージした結果を試したい！なんてケースもあるのではないでしょうか． GitHub では git ls-remote すれば分かるように，プルリクエストの番号と対応したブランチがリモートに存在しているので，これを取得してみます． .git/config に追記（あるいは git remote add とかで適当に） [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ（丸投げ）: https://gist.github.com/3342247 git fe
Better Commit Messages with a .gitmessage Template
It can be tough for your team to know exactly why they need the changes you’re proposing in a pull request. What if we could give them more context? There’s an episode of The Weekly Iteration where a simple trick was mentioned. After adopting it myself, I have noticed my co-workers commenting on how useful these messages have been in providing context. The trick is simple. Split your PR message in
GitHubのPull Requestのレビューコメントをコマンドラインから取得するツール
get-github-pr-review-commentsというシンプルなCLIを作りました。 GitHubでPull Requestを出して、そこへレビューコメントを書いて、それを反映というのを繰り返すと思います。 そのときに、レビューコメントの位置をソースコードの位置で探すのが毎回大変でした。 （特に文章をPRしてるときは細かいtypoをレビューコメントで印を付けて直すみたいなことがよく起きるので、位置が見つけにくい) get-github-pr-review-commentsは次の事を行うCLIです。 指定したCommitShaを含むPull Requestを取得 ブランチのshaとかでいい Pull Requestについているレビューコメントを取得 実際のファイルパス:行数 + レビューコメントを出力 VSCodeやWebStormなど大体のエディタはファイルパスをクリックしてジャ
Githubで特定のディレクトリだけをチェックアウトする方法 - 亀岡的プログラマ日記
Github、ようやく開発の本物のレポジトリとして扱えるようになってます。いやぁ、ほんと、楽。 色々とはかどります。 とはいえ、最初にレポジトリの構成を間違ってしまうと、開発終盤になって、「このブランチのこのディレクトリだけちょっと見れるようにしておきたいなぁ・・・」と思うことは有ります。うっかりデザインデータを特定レポジトリのディレクトリに突っ込んじゃった、とか。 そんな時、「このディレクトリ以下をチェックアウト」ってできればなぁ、と思うんですが、残念。svnならまだしも、gitはできないんですよねぇ。。。 「"Git"hubといったな？あれは嘘だ。」 んで。まぁ有名な話として、これがありますよね。 そう、Githubはsvnチェックアウトできるんです。ということは・・・、特定のディレクトリ以下を引っ張ってくることだって、もちろん可能です。 えー、でも今更svnつかうのー？ 我々には、g
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
Git submoduleの押さえておきたい理解ポイントのまとめ - Qiita
みなさんgitのsubmoduleって理解して使ってますか？ 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか？ 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
「追跡ブランチ」って言うのやめましょう - Qiita
TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか？ origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡するリモート追跡ブランチ (remote-tracking branch)である origin/master はローカルの master
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - marionebl/commitlint: Moved to https://github.com/conventional-changelog/commitlint
tips/README.md at master · git-tips/tips
GitHub - git-town/git-town: Additional Git commands for easier branch management and support for stacked changes
angular.js/CONTRIBUTING.md at master · angular/angular.js
Use IntelliJ or WebStorm as your git diff tool (even on Windows) (Example)
GitHub - jayphelps/git-blame-someone-else: Blame someone else for your bad code.
Git2.5のアップデート内容について - Qiita
sorry