Fork is getting better and better day after day and we are happy to share our results with you.
![Fork - a fast and friendly git client for Mac and Windows](https://cdn-ak-scissors.b.st-hatena.com/image/square/11d564643fbccbb9fbacfa0256206d011663a9a7/height=288;version=1;width=512/https%3A%2F%2Ffork.dev%2Fimages%2Ftwitter4.jpg)
Fork is getting better and better day after day and we are happy to share our results with you.
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
2016年1月に Git 2.7 がリリースされました。 色々なコマンドが増えたりしていますが、なかでも .gitignore に関する仕様追加が興味深かったのでまとめます。 .gitignore とは Git で管理したくないファイルを設定するためのファイルです。 たとえば .gitignore ファイルにこのように書いて置いておくと、 *.json /sample-folder 拡張子が .json のファイルと、 /sample-folder というフォルダ配下は Git で管理されなくなります(変更などがあっても無視される)。簡単ですね。 .gitignore の設定を、打ち消したい場合 ! 記法で、設定の打ち消しが可能です。 たとえばこう書くと、 *.json !required.json 拡張子が .json のファイルは無視されるのですが、 ! をつけた required.j
git の記事などを見ていると、よく rev-parse というコマンドが出てきます。 rev-parse単体でググっても使い道がよくわからないので、メモ変わりにrev-parseでできることをここに書いてみます。 【参考】 git-rev-parse(1) Manual Page https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 使用可能なリファレンス(ref)を渡すとハッシュを返す ハッシュ $ git rev-parse 1838ad4786...02cc4e713a >> 02cc4e713a10dc68bcba40919f0f23eb62b45ec4 >> 1838ad478661d8cdb544c9adf921d08a97f7cc91 >> ^02cc4e713a10dc68bcba40919
Github(Enterprise)を利用してチーム開発を行っており、開発メンバー全員の環境でpre-commitにてESLintを自動実行したくなった。 けど、.git/hooksにpre-commitを作成してもGithub上で管理できない。。 以下、workaroundをメモとして残す。 目的 チーム開発において、commit直前にESLintを自動実行したい。 方針 チームメンバー全員の.git/hooks配下にpre-commitを配置するシェルスクリプトを用意する。 前提 ディレクトリ構成は以下の通りとする。 ├ bin ├ node_modules └ .git/hooks 手順 package.jsonにESLintを追加する ESLintが無いと何も始まらないね。
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
Gitをhomebrewで2.3.6にアップデートしたら、行内の文字単位のdiffが完璧に出るようになってた。 以前は一応見れたけど3割ぐらい文字化けしてた → 文字単位でgit diff 1行が長い文章を書いている時は、変更された文字単位で背景色がつくとどこが変わったかわかりやすい 設定 diff-highlightにパスを通す % brew install git % ln -s /usr/local/Cellar/git/2.3.6/share/git-core/contrib/diff-highlight/diff-highlight /usr/local/bin/diff-highlight ~/.gitconfig でpagerを設定 [color] ui = auto [pager] log = diff-highlight | less show = diff-highli
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
以前、Gitの使い方、よく使うGitコマンド という記事を書きましたが、git rebase -i の項目に書き足したいことが増えてきたので別エントリに切り出し、内容を見直しました。 git rebase -i を使うと、最新のコミットから指定したコミットまでの歴史を対話式に改変することができます。具体的には以下のことができます。 コミットメッセージを変更するコミット内容を修正するコミットを分割するコミットをまとめるコミットを削除する 私個人の利用シーンとしては、開発ブランチを master にマージする前(プルリクを送る前)にコミットの整理に使うことが多いです。一発できれいなコミット履歴を作るのは難しいので、散らかったコミットを後から整理するのによく使います。Git って便利だなあと思う瞬間です。 目次 rebase -i の使い方 reword コミットメッセージを変更する edit
皆さんはプロジェクトのリソースとしてエクセルの xlsx ファイルを使う事があると思います。 何てったって事務職の人ですら楽々使えるスーパー優れた UI なので、 web の管理画面とかを作り込むよりもエクセルでシート作ってもらってしまった方が早いケースも多いんです。現実の世界では。 で、普通の人は TSV にするだの CSV にしてもらうだのすると思うんですが、一方的にデータ貰うだけなら良いんだけど、相手とやり取りする時にはどうしても xlsx ファイル経由とかにしないと相手がこまる!やっぱりエンジニアのエは優しさのエだから相手に優しくしないとだめです。 で、 xslx ファイルでエンジニア以外の人とデータやり取りするとやっぱり、バージョン管理したくなるのが人情です。 でも xslx ファイルはバイナリファイルなので git diff とかが残念です。。。 って事で作っちゃいました。 h
Our intention was simple — enable people to openly collaborate on projects that could turn into startups. Groups would be open, dynamic, and grow with the popularity of a project. We needed a place to store our code. The fork and pull model did not meet our needs so integrating with GitHub was not an option. Our proposed access model required branch level permissions. A makeshift Gitolite solution
If you have Photoshop psd files lying around your git repository, you probably already know there's no easy way to track any changes to them — you have to launch Photoshop and manually inspect them, and if you're not a designer or don't have Photoshop installed on your device, you're fresh out of luck. psdiff is a small tool that you install as a git hook — then, any time anyone makes a change to
Vim (ビムとも言う) の話です。 さて複数人で Git を使いながら開発していると、ファイルの conflict って頻繁に起きるので、もう皆さん conflict とは仲良しこよしのことと存じます。 大体のひとは、conflict してしまったファイルをエディタで開いて修正すると思うんですが、*1 いちいちターミナルで git statusとか実行して、その結果を見ながら「どのファイルが conflict しているか」を確認して、 エディタで該当するファイルを開いて *2 修正するのってちょっと面倒臭い感じがしますよね。 やはり開発するひとも人間ですから、 「どうせだったら、エディタが conflict しているファイルをピックアップしてきてくれれば良いのに……」 「そうすれば、いちいち git のコマンドをタイプする必要がなくなって、エディタから直接ファイルを開けるのに……」 とい
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
HubFlowとは HubFlow: GitFlow For GitHub HubFlowはGitHubリポジトリでGitFlowを便利に使うためのGitコマンド拡張です. gitflowをforkして開発されています.datasift/gitflow · GitHub 今の時点では,大幅に便利になるというものではない感じです. git hfのようにサブコマンドhfを用いたコマンド体系なので,gitflowと併用できます. さらに,gitflowを利用している既存のリポジトリに対してもgit hf initで上書きすれば使えます. 使い方 なんか新しい図が出てますが,流れはGitFlowとほとんど変わりません. リモートブランチとfork元のブランチに対する操作が用意されていないGitFlowに対して,HubFlowでは用意されているという点が異なります. 便利になったところ git hf
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く