GitHub - git-chglog/git-chglog: CHANGELOG generator implemented in Go (Golang).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
thank-you-starsで利用しているnpmパッケージに気軽にスターを送る - teppeis blog
先週、こういうツイートを見て、 OSSを使っているなら、GitHubのリポジトリにそっとスターをつけると開発者のキャリアにわりと直接的に貢献できるのでお薦めです。少額の寄付より効果があるかも— Taro L. Saito (@taroleo) 2017年8月15日 共感したのでサクッと作った。 github.com package.jsonと同じディレクトリで実行するだけで、depsとdevDepsのパッケージのGitHubリポジトリにスターできる。 事前にパーソナルトークンをホームディレクトリに保存しておく必要があるけど、その辺はREADMEを読んでくれ。 依存に入れて使っているということは、それなりに恩恵を受けているということなので、問答無用でスターを送ってしまって良いと思う。 孫依存のパッケージにも送るか迷ったけど、npm的にそこ含めると一気に数が膨れてしまうのでやめた。 これでみん
github で git コミットメッセージで issue 番号を指定 - それマグで！
github のIssueとコミットを関連付ける コミットメッセージで、Issueと関連付けるには git commit -m "あれこれに追加 #1234" このように＃ISSUE番号を書くと関連付けて、Issueに関連付けられる github issue をコミットで閉じる git commit -m "あれこれ fix #1234" このように fix #番号 でIssueに関連付けられ、Issueが閉じられる。 fix だけ？新機能の時はどうするの git commit -m "あれこれ close #1234" このように close #番号 で issue に関連付けられる、Issueが閉じられる 一度に複数のIssueを片付けたら？ git commit -m "あれこれ close #1234 #1235 #1236 " このように、番号を複数書くことが出来る まとめ コミ
配管を通ってGitを理解してみる - Tbpgr Blog
Gitを理解するにはGitの中身の知るのが良い、 と天の声が聞こえてきたので学習がてらまとめることにしました。 この記事は個人メモ的な記事です。 基本的に既出情報なのでタイトルをみてピンと来ているかたは読む必要がありません。 ※この記事を読むタイミングとしてはGitの基本的な操作と概念をある程度理解した あとが良いと思います。曖昧な基準ですが。 Gitの2種類のコマンド 配管（ Plumbing ） コマンド 磁器（ Porcelain ） コマンド Gitの中身 Gitオブジェクト blob オブジェクト tree オブジェクト commit オブジェクト tag オブジェクト 参照 .git配下のファイル、ディレクトリの説明 HEAD ファイル index ファイル objects ディレクトリ refs ディレクトリ 関連資料 Gitの2種類のコマンド Gitの中身はキーバリュー型の
Homebrewでbrew updateしたら/usr/local/Library/ENV/scm/git: No such file or directoryと言われてしまう - Smoky God Express
事象 めっちゃ同じのが出る。 $ brew update /usr/local/Library/brew.sh: line 32: /usr/local/Library/ENV/scm/git: No such file or directory : 対応 brew prune でよい $ brew prune Pruned 0 symbolic links and 6 directories from /usr/local $ brew update : これ同僚に教えてもらったんだけど、brew pruneってなんだろって思って調べたのでメモ $ brew prune --help brew prune [--dry-run]: Remove dead symlinks from the Homebrew prefix. This is generally not needed, bu
Vagrant + VirtualBoxで通信やgitコマンドが遅いのを回避
Vagrant + VirtualBox環境で開発をしていて、やたら遅いなと思った2点を解決した時のメモ。 通信が遅い Vagrant上でdeployをすると、通常30秒で終わる処理が、なぜか5分以上かかっていた。 調べると、CentOSの問題とのこと。 [参考] RHEL6/CentOS6では、single-request-reopen を必須にしたい…[IPv6] ↑ここに書いてある通り、 vagrant:~$ sudo vim /etc/resolv.conf で options single-request-reopen を追記すると、通常の速度を取り戻した。 他で調べた感じだと、Vagrantの設定（Vagrantfile）でも回避可能とのこと。 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| ... config.v
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
git-flow cheatsheet
About git-flowはgitの拡張であり、Vincent Driessenの提唱するブランチモデルを実現するための高度なリポジトリ操作を提供します。 more ★ ★ ★ このチートシートは基本的な使い方とgit-flowの効果を表します。 ★ ★ ★ Basic tips Git flow は素晴らしいコマンドライン補助と出力を提供します。何が起こるか注意深く読み解いてください。 macOS Clientの Sourcetree は素晴らしいGUIとgit-flowサポートを提供します。 - Git-flow はマージすることをベースとして考えるソリューションです。リベースは行いません。 ★ ★ ★ macOS Homebrew $ brew install git-flow-avh Macports $ port install git-flow-avh Linux $ apt
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている！
Visual Studio Code は JavaScript 開発が超絶便利になる可能性を秘めている！ クロスプラットフォームでオープンソースな IDE 環境、Visual Studio Code が公開されたので試してみた。 拡張を入れなくても、デフォルトで JavaScript の「自動 Lint」「Grunt、Gulp 連携」「デバッグ」が動いた。なんだかすごく便利そうな予感。 Windows 環境で起動してみたらこんな画面だった。 なんか黒いが、色は好みにカスタマイズできるし、プリセットからも選べる。 フォルダーを開くことから始まる Visual Studio Code にはプロジェクトの概念はない。 [File] > [Open Folder] からフォルダーを開けばよい。 ためしに、過去に作った Node.js 製の livereloadx のフォルダーを開いてみた。 左側に
.gitignoreの範囲の指定方法 - nametake-blog
過去に書いた記事をそのまま移行します。 前提 $HOMEディレクトリ上でドットファイルをgitを管理している。 .gitignoreはホワイトリスト方式で記述している。 やりたかったこと $HOME └── .vim ├── bundle ├── snippet ├── syntax ├── template └── userautoload 上記の構造になっているvimの設定ファイルのbundleディレクトリ以外をgitの管理下に置きたい。 (bundleディレクトリだけはgitで管理したくない) やったこと ホワイトリスト方式で.gitignoreを設定したが、階層構造をとっている時の設定でつまずいた。 ダメだったパターン 以下のように記述したら$HOME/.vim/以下のディレクトリ内部のファイルが読み込まれなかった。 # all file ignore /* /.* # targe
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
git submodule init / update が出来ない！No submodule mapping found in .gitmodules for path が出るときの対処
git submodule init / update が出来ない！No submodule mapping found in .gitmodules for path が出るときの対処 No submodule mapping found in .gitmodules for path git の submodule は、 プロジェクトの内部に外部のリポジトリを組み込むことが出来る機能です。 submoduleで組み込まれたプロジェクトのソース管理は独立した状態にあり、 git clone した場合には、submoduleの内容は空です。 そのため、 git submodule init git submodule update として、 別途初期化・更新する必要があります。 しかしこの際に No submodule mapping found in .gitmodules for pa
git submoduleについてのメモ 追加/削除/更新等
B! 70 0 0 0 Gitのsubmoduleがいつもイマイチ良くわからなくなるので 自分なりのまとめ。 レポジトリにsubmoduleの追加 submoduleのあるレポジトリをcloneする submoduleの更新 submoduleの削除 ignore = dirty Submoduleのプロトコルの変更 レポジトリにsubmoduleの追加 git submodule addで追加。 $ git submodule add [email protected]:rcmdnk/evernote_mail.git ./submodules/evernote_mail addすると.gitmoduleというファイルがまだ無い場合は作られ、その中に [submodule "submodules/evernote_mail"] path = submodules/evernote_mai
初めてのpull request @ GitHub - rcmdnk's blog
B! 25 0 1 0 GitHubを使い始めてしばらく経ちましたが、始めて初めて 1 Pull Requestをしてみたので やり方をメモしておきます。 Pull Requestを送ったレポジトリ 実際に行った手順 Forkする Forkしたレポジトリをclone 作業用ブランチを作って変更を適用する 変更をcommitしてリモートへpush Pull Requestを送る オリジナルの作者とやり取りしながら変更を取り込んでもらう まとめ Pull Requestを送ったレポジトリ 以前Octopressへ絵文字の導入で紹介した jekyll-emojiと言う プラグインに対して、emojiのイメージを外部における様な設定を可能にする 変更をリクエストしてみました。 実際に行った手順 Forkする まず、GitHubにログインした状態で リクエストを送りたいレポジトリのページに行きます。
Github で Fork してから Pull Request をするまでの流れ | けーこ in サンフランシスコ
いつも忘れてしまうので、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.
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
横着で神経質な私とあなたに贈るgit add -p - Qiita
gitのsubmoduleに変更を加えるとdiffが生じるのを無視する - Qiita
