git configをプロジェクトによって使い分ける - QiitaGit v2.13.0（2017/05/10リリース）でgit configにConditional includes（条件付きインクルード）という機能が実装され、特定のリポジトリに対して一括でgit configを適用できるようになりました。 会社用と個人用でプロファイルを使い分けたり、たまに使う設定をまとめて適用する場合などに役立ちそうです。 設定方法 includeIfセクションを使います。git configコマンドか、~/.gitconfigを直接編集して追記します。
git gone: stale なローカルブランチのクリーンアップ · eed3si9n
2018-09-15 / git GitHub の pull request を中心に作業していると、やたらといらないブランチがローカルに溜まってくる。本稿では、このいらないローカルブランチを掃除する方法をみてみる。 基本的に 2つの戦略があると思う: “master” ブランチを選んで、そこにマージ済みのものを削除する GitHub 上で既にブランチは削除されている前提で、リモートの “origin” にはもう無いローカルのブランチを削除する Erik Aybar さんの Git Tip: Deleting Old Local Branches というブログ記事は第2の方法をとっている。 This just helped clean up 150+ old local branches for me this morning, so I thought I should share! #
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
Exploding Git Repositories – Kate Murphy
Exploding Git Repositories If you are an adventurous sort (and can handle a potential reboot) I invite you to clone this tiny repo: Were you able to clone it? Unless you have quite a lot of memory (both RAM and storage) git was killed, ran out of memory, or you had to reboot. Why is this? It is a perfectly formed repo made of only 12 objects. How does a tiny repo cause git to run out of memory? Th
Setting your commit email address in Git - User Documentation
About commit email addresses GitHub uses your commit email address to associate commits with your account on GitHub.com. You can choose the email address that will be associated with the commits you push from the command line as well as web-based Git operations you make. For web-based Git operations, you can set your commit email address on GitHub.com. For commits you push from the command line, y
Merge, update, and pull Git branches without using checkouts
The Short Answer As long as you're doing a fast-forward merge, then you can simply use git fetch <remote> <sourceBranch>:<destinationBranch> Examples: # Merge local branch foo into local branch master, # without having to checkout master first. # Here `.` means to use the local repository as the "remote": git fetch . foo:master # Merge remote branch origin/foo into local branch foo, # without havi
gitでローカルブランチにmasterなんて（普通は）要りません - Qiita
理由 GitHubやGitLabなどのおかげで、リモートで直接masterにマージできるようになった。 どうしても、という時以外ローカルのmasterブランチで作業する必要はないはずです。 間違えてmasterを壊してしまうリスクが更に減る ローカルのmasterブランチをメンテするコストが減る 地味なメリットに聞こえるかもしれませんが個人的にはありがたいので最後のものを詳しく説明します。 Gitの仕様上、ローカルのmasterブランチはリモートのmasterブランチを更新しても自動的には更新されません。 現状、git checkout masterしてからgit pullしないと更新できないはずです（他にも方法はありそうな気がしますが割愛します）。 この方法、一瞬でもmasterにチェックアウトしなければならないため、チェックアウトする前のブランチとローカルのmasterの差が大きい場合
Git pullを使うべきでない３つの理由 · DQNEO日記
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
git archive で指定ファイルを除外する
git archive コマンドを使えばリポジトリをアーカイブできるみたいです。 けれど .gitignore とかはアーカイブにはいらないのでどーにかできないかな、と思っていると tar とかでフィルタする 方法があるらしい。 けれど Mountain Lion にデフォルトで入っている tar には --delete オプションが無い様子。 で、もう少し調べると .gitattributes なるものがある様子。 これを書いているとファイルに対していろいろと設定できるらしく、 export-ignore と書いているとarchiveに含まれなくなるみたい。 .gitignore 除外のための .gitattributes の例はこんな感じ .gitattributes を書いて実際にアーカイブを試してみるけれど $ git archive HEAD -o archive.tgz だと
git show-branch の見方 - 言語ゲーム
git が使いにくいのはコマンド設計の悪さの他、レポジトリの状態と自分の位置を確認するのが難しいからだと思います。例えば Subversion ならある瞬間のファイルはパス名とリビジョン番号で一意に定まるので、時間的、空間的位置を把握するのは簡単です。しかし git ではそこにブランチが加り、ファイルは SHA1 という恐ろしい記法で管理されます。そこで色々試してみて git show-branch を活用するするとだいぶ理解しやすくなる事が分かりました。 本来の git show-branch の役割は、複数のブランチやタグが分岐してから現在までの記録を表示する事です。例えばたまたま手元で仕事中のブランチ bui-test と master、そして タグ idst-r612-merged を比較するとこんな風になります。ブランチ名を指定しないとローカルのブランチを全部指定したのと同じにな
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
GitHubコミットメッセージの英語の書き方の文例が検索できるサービス作った - 城陽人の本棚
経緯 個人的にgit commit -m " うっ、英語でなんて書けばよいんだろう。。。。ってなることが多くて、GitHubの公式の検索ってソースコードは検索できても、コミットメッセージをリポジトリ横断的に検索したいなんてことはできないんですよねぇ。まぁネイティブな人にはそんなこと思いもしないのかも知んないですが。調べてみたらGitHub APIでコミットメッセージ取れるようなので、現場のリアルな生の文例を集めて検索できるようにすればよくね？ということで勉強がてら作ってみたので、需要あるか分からないけど同じこと思ってた人のために晒す。 作ったもの http://commit-m.minamijoyo.com/ 使い方 テキストボックスにキーワード「fix bug」などを入力してSearchボタン押すと検索結果が表示される。以上。 機能の補足説明 キーワードはスペース区切りでAND検索になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ericfrederich/sillygit
How to ZFS · GitBook (Legacy)
GitHub - microsoft/Git-Credential-Manager-for-Windows: Secure Git credential storage for Windows with support for Visual Studio Team Services, GitHub, and Bitbucket multi-factor authentication.
What does the filesystem cache do in Windows 7?
Gitでやらかした時に使える19個の奥義 - Qiita
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
「Git for Windows」v2.5.0が公開、プレビューを脱した初めての正式リリース
