git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
gitで別のリポジトリにpushする - masartz->log(type=>'hatenablog')
通常git push は git cloneしてきたリモートリポジトリに対して打つ事が多いので、 git push とか git push origin master くらいしか打ったことがありませんでした。 とある対応で、my/hoge.gitのリポジトリで作業したあと、最終的にpublic/moge.gitのリポジトリとして公開したいという 場面があり、git merge あたりを軽く眺めたんですが、結局 init commitなので手動コピー -> git add , commit , push でも いいかというアナログ手抜き対応をしちゃいました。 すかさず突っ込みを貰い、非常にシンプルな正解を教わりました。。 my/hoge.git をcloneしたディレクトリで、↓の1行で一発 git push [リポジトリ名] master （ 前述の例だと git push git@rep
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
Git管理ツール「SourceTree」で差分ファイルを抜き出す方法 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
どうもです、お久しぶりです、はやちです✌(´ʘ‿ʘ｀)✌ ここ最近DMMのブラウザゲーム「刀剣乱舞」にハマってしまいましてひたすら刀狩りをしております( ˇωˇ )＜おじいちゃんこない そんなことはどうでもいいですね。 今回は、Git管理ツール「SourceTree」を使用して昔のファイルと作業したファイルの差分を抜き出す方法をご紹介いたします( ˘ω˘)☝ バッチファイルを用意する まずはバッチファイルを用意しましょう( ˇωˇ)☝ 適当なディレクトリにファイルを保存します。 Windows用 Windows用がこちらです。 export_diff_zip.bat if "%2" EQU "" ( set PARAM1=HEAD set PARAM2=%1 ) else ( set PARAM1=%1 set PARAM2=%2 ) setlocal enabledelayedexpan
GitHubコミットメッセージの英語の書き方の文例が検索できるサービス作った - 城陽人の本棚
経緯 個人的にgit commit -m " うっ、英語でなんて書けばよいんだろう。。。。ってなることが多くて、GitHubの公式の検索ってソースコードは検索できても、コミットメッセージをリポジトリ横断的に検索したいなんてことはできないんですよねぇ。まぁネイティブな人にはそんなこと思いもしないのかも知んないですが。調べてみたらGitHub APIでコミットメッセージ取れるようなので、現場のリアルな生の文例を集めて検索できるようにすればよくね？ということで勉強がてら作ってみたので、需要あるか分からないけど同じこと思ってた人のために晒す。 作ったもの http://commit-m.minamijoyo.com/ 使い方 テキストボックスにキーワード「fix bug」などを入力してSearchボタン押すと検索結果が表示される。以上。 機能の補足説明 キーワードはスペース区切りでAND検索になる
ローカル環境の設定ファイルをgitの対象から外す - Qiita
で設定を変更しました。 また、 http://qiita.com/maximum80/items/729af0392a84a3196088 で書かれているように、composerのアップデートを行いました。 その後にリモートの最新状態をpullしようとすると、 Cannot pull with rebase: You have unstaged changes. Please commit or stash them. とgitに怒られてしまいます。 でも、ローカルでの開発用に設定しているファイルなので、この子達はコミットしたくありません。 そんな時の対処法です。 1. git rm --cached ファイル名 まず、 $ git status Changes not staged for commit: (use "git add <file>..." to update what w
第34回 バージョン管理 ─プロジェクト管理ファイルについて［中編］ | gihyo.jp
はじめに 今回と次回の2回にかけて、イマイチよくわかってないAndroid Studioのプロジェクト管理ファイルについて解説します。途中で飽きちゃう人のために、最低限共有する必要のある（バージョン管理する必要のある）管理ファイルを紹介します。 ここでの対象は.ideaディレクトリだけなので、説明のしやすさも兼ねて <PROJECT_HOME>/.idea/.gitignoreを作成し「.ideaディレクトリに対するホワイトリスト」を提示していきます。 図1 新しく<PROJECT_HOME>/.idea/.gitignoreを作成する リスト1 最低限必要な<PROJECT_HOME>/.idea/.gitignoreの例 *.xml !/gradle.xml リスト2 最低限必要な<PROJECT_HOME>/.idea/.gitignoreの例.gitignoreの内容 /.grad
gitでnumstatを利用して総追加行数、総削除行数を取得するワンライナー - @nnm_tech
上期も終わり開発中のgitリポジトリの情報を採取して遊んでいました。Qiitaでコミット数や総追加行数、総削除行数を取得するワンライナーについての投稿があり活用させて頂いています。ありがたい...! リンク先のワンライナーでコミット数は正確に計れるのですが、総追加行数と総削除行数がなにかおかしい。なぜか総追加行数が非常に多く計算されていました。 というわけで原因を調べてみました。 原因1. 1ファイルのみの変更の時にgrepがスルーされる 1ファイルのみの変更の場合、以下のような出力になります。 $ git log --shortstat --oneline --no-merges f86f749 Insert open graph meta tag contents when adding a link item refs #29 1 file changed, 67 insertion
Xcode, Android Studio の .gitignore - Qiita
Xcode *.xcodeproj/* !*.xcodeproj/project.pbxproj !*.xcworkspace/contents.xcworkspacedata .DS_Store Android Studio *.apk *.ap_ *.dex *.class bin/ gen/ local.properties .classpath .project proguard/ *.iml *.ipr *.iws .idea/workspace.xml .idea/tasks.xml .idea/libraries/ .gradle app/build/ .DS_Store Register as a new user and use Qiita more conveniently You get articles that match your needsYou can ef
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
Gitでブランチを統合する方法 — 裏紙
#!/bin/sh rm -fr .git *.txt .gitignore git init echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit" echo b>b.txt && git add b.txt && git commit -m "master 1" git branch other echo c>c.txt && git add c.txt && git commit -m "master 2" echo d>d.txt && git add d.txt && git commit -m "master 3" git checkout other echo e>e.txt && git add e.txt && git commit -m "other 1" echo
Gitの勉強のため参考にさせてもらったサイトやスライドの紹介｜ cocoblo [ココブロ]
Gitを触り始めて間もないのですが参考書もためになりますがネットにもたくさんの情報が掲載されています。 まずはGitとはどういうものかを紹介しているサイトから具体的な流れなどを紹介しているサイトをご紹介します。 ニッチなことなどは自分も勉強不足なところもあるので初心者の方にも馴染めるようなサイトを紹介したいと思います。 ひと通りの流れを勉強するのに最適 サルでもわかるGit入門 まずはここは読んでいて損はないところかと思います。ボリュームもあるので一気読みはおすすめしませんが入門編から読んでみると理解しやすいかと思います。イラストも可愛く読みやすい作りです。 GitHubに関する記事 他にも様々なブログでGitHubに関して書かれていたりしていますのでググったりしてみてはいかがでしょうか？ Windowsにgitをインストールしてgithubにpushするまで Git/GitHub初心者の
![Gitの勉強のため参考にさせてもらったサイトやスライドの紹介｜ cocoblo [ココブロ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e18ea86625a114e8bf7b36e5bec2ee7b6f8e853a/height=288;version=1;width=512/http%3A%2F%2Fwww.cocoblo.jp%2Fblog%2Fwp-content%2Fuploads%2F2015%2F01%2Foctocat.jpg)
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド - akiyoko blog
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います（9つでも多いよ！というツッコミは受け付けません！）。 【コマンド その１】 git clone 【コマンド その２】 git log 【コマンド その３】 g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://unicus.jp/skmk/archives/474
リモートリポジトリを他のものに移行する方法 - Qiita
コンセプトから理解するGitコマンド
