git でファイルを無視するには、通常は .gitignore や .git/info/exclude を使います。 しかし、既に git 管理下にあるファイルは、これらの設定があっても無視されません。 以下の方法を使えば、git 管理下にあるファイルをあえて無視することが可能です。 方法 次の2つの方法があります。どちらを使っても、ファイルの変更を無視できます。 方法(1) assume-unchanged
あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト(造語) 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン( master ブランチ)に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙
morimorihogeです。残暑やばい。 ※元々は2014年に書いた記事ですが、2020年になっていろいろと事情も変わっているので2020年revise版として更新しました。 弊社ではバージョン管理システムにGitを使っています。 数ヶ月以上一緒にやっているある程度ツーカーなメンバーだけのプロジェクトなら問題無いのですが、案件によっては協力会社の方が一時的にJOINしたり、新規参入メンバーの参加などで、これまでGitを使ったことがない、または本格的なチーム開発でGitを使ったことがない人が参加することもあります。 ※2020年現在では流石に全くGitを使ったことのない開発者というのはほぼ見なくなりましたが、チーム開発できちんと運用に乗せて使ったことがない、という所は今でもそこそこあるようです。 Gitは自由度の高いシステムですが、その分概念を覚えることが必要なため、導入の敷居が高い方だと
なぜかgit GUIクライアントのSourceTreeやコンソールからgitを使用するgitBashがやたら遅くなる。 gitBashのコンソールが起動するのも遅いし、起動したあともただEnterキー押しただけなのに シェルに戻ってくるまで時間がかかる。 SourceTreeもステージングやコミット、差分の検出がとても実用に耐えないほどクソ遅い。 どうしたもんかと検索しても合致する現象が出てこない。 英語ならどうかなと[gitBash Windows10 very slow]で検索してみたら 同じ現象のがあった 「Disabling AMD Radeon graphics driver in the Windows device manager」 AMD Radeon graphics driverを無効にすればいいらしい。 こんなんで治るんかいなと思ったがとりあえずやってみる。 デバイス
Gitとは、バージョン管理を行うツールの1つだ。バージョン管理は数多く存在するが、ここではGitを紹介する。 Gitインストール方法 Gitはバージョン管理システムのひとつであり分散型と呼ばれている。そのGitのインストール方法を表示される画面の順に従って説明を行う。 ダウンロード 「git for windows」の公式サイト(URL: https://git-for-windows.github.io/)よりインストーラーのダウンロードを行う。 ダウンロードは「Download」ボタンを押すことによって始まる。 ダウンロードが終わると、ダウンロード・フォルダーに最新バージョンのインストーラー(OSに応じてGit-2.13.2-64-bit.exeまたはGit-2.13.2-32-bit.exe)が格納される。この記事を書いている時点では、最新バージョンが2.13.2である。 ダウンロー
著者:江添亮 ブログ: http://cpplover.blogspot.jp/ メール: boostcpp@gmail.com Twitter: https://twitter.com/EzoeRyou GitHub: https://github.com/EzoeRyou アマゾンの江添のほしい物リストを著者に送るとブログ記事のネタになる 筆者にブログのネタになる品物を直接送りたい場合、住所をメールで質問してください。 gitの10周年を記念したLinus Torvalsへのインタビューの翻訳 10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。 なぜGitを作ったのか? トーバルズ:俺はソース
SourceTreeの「端末」を開き、下記コマンドを実行するとgit履歴から編集ファイル一覧が取得できます。 よかったらご活用ください。 (ちなみに頭の$は「コマンドですよ」という印なので、$まで入れないようにご注意ください) ※SHAとは:sourcetree上に「コミット」という欄で表記される履歴IDのこと。本当は長いが省略版も併記してある。どちらでも可 ## コミット間のファイル一覧を取得 $ git diff --stat --name-only [fromコミットのSHA] [toコミットのSHA] ## ファイルに出力(適宜出力先のパスは変えてください) $ git diff --stat --name-only [fromコミットのSHA] [toコミットのSHA] > /Users/aaaaa/Desktop/[出力ファイル名].txt 例 コミット① SHA:11111
Gitで自宅サーバに置いていたレポジトリをWindows PCへCloneしようとしていた時の事 事象 以下のようなエラーが発生した fatal: early EOF fatal: The remote end hung up unexpectedly fatal: index-pack failed 原因 調べていくと原因はレポジトリがでかすぎることっぽい。 解決策は大体以下3つなのかなと思った。 1.gitのhttp通信制限を増やす 2.サーバー側でgc&repackする 3.そもそも一度にcloneする量を減らす 事象の原因によって1~3のどれで直るかは違う模様。 筆者は1を試したがダメで、3を試してうまくいった。 各解決策がどういった詳細な原因と結びついているのか、については調べていない。 1は1つのファイルに対する制限で、3は全体の容量を減らしてるから違うとかそんな感じなのかなと
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
gitのこのエントリがちょっと盛り上がってた。 gitの良さがいまだに分からない 本文もブコメも読んだのだけど、ほとんどの人が「使いこなせてない」ということを問題視しているように見える。 gitのエントリはいつもそれなりに話題になり、それぞれ面白かったりタメになったりするのだが、いつも何らかの既視感を感じていた。ずーっと考えてみたら、それはかつての TeX にあったことによく似てる。 「往時のTeX」も「今のgit」も、 割と誰もが使うことになる てゆーか使ってないと恥ずかしかったりする 結果は素敵だけど学習コストは低くない という点でよく似てる。だからこそ「ノウハウ」の記事がいっぱい上がり、それらについてあれこれ言われ、また「哲学」みたいな「作法」みたいなものも議論になる。 近頃はTeXを使うことが減ったのではあるけど、昔はTeXはよく使っていた。TeXと言っても生TeXではなくて、La
はじめに † gitでコミットログを修正したいです。 Redmineとかで、refs #10とかcloses #10とかつけるとコミットログにチケットを関連付けられますが、これがよく書き忘れるんですね…。 直前のコミットログを修正する方法あるみたいです。 直前のコミットログ以外も修正する方法はないのかな…。 (Subversionだとhookスクリプトで許可できますよね。分散型だとやっぱり無理?) ↑ 直前のコミットログを修正する方法 † 直前のコミットログの修正は"git commit --amend" でよいみたいです。 例えば、 $ git commit -m "fixed xxx bug" : # コミット完了! # あ!しまった!"refs #(チケット番号)"つけるの忘れてた! # (私が使うプロジェクト管理ツールRedmineではrefs #13 のようにすると # コミット
入れたくないとは思っていても、止むに止まれぬ事情で Word, Excel, PowerPoint などのファイルを git レポジトリの中で管理することはありませんか?この記事では、Mac で Office ファイルの diff を取る方法を紹介します。Linux でも多分動くはず。 textconv 普通、バイナリファイルを git diff しても、変更内容がわかりません。ところが、git には textconv という、バイナリファイル(別にバイナリじゃなくてもいいんですが)をコマンドに渡した結果を diff に使う機能があります。ドキュメントには、JPEG の Exif 情報の diff を取る例等が載っています。 Office ファイルからのテキスト抽出 では、Office ファイルからテキストを抽出するにはどうすればいいでしょう?Windows の msysgit には as
$ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*
※この記事は元々「Gitのこれやめて!リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで!!」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
間違えてmasterやdevelopにpushしてしまうあなたは今すぐこれを.git/hooks/pre-commitにコピペしなさいGit #!/bin/bash current_branch=$(git rev-parse --abbrev-ref HEAD) warn_branch() { echo "You can't commit on '$current_branch'!" } case $current_branch in master) warn_branch; exit 1 ;; # Of cource you can add any other important branches as you need. develop) warn_branch; exit 1 ;; # Of cource you can add any other important branch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く