GitExplorer: Find the right git commands you need without digging through the web
私の独断と偏見によるGit for Windowsのインストール手順です。 最終更新 2022/06/07 Downloadをクリックし、インストーラーのダウンロードを開始します。 ファイルをダブルクリックしてインストーラーを起動します。 ライセンスを確認して、Nextをクリック。 Only show new optionのチェックは、アップグレード時に新規に設定する項目のみを表示させるためのオプションです。 インストール先ディレクトリを確認されるので、Gitをクライアントとしてのみ使う場合にはできるだけこのままで進めます。ただ、オープンソースのTracのようなITS/BTSと組み合わせる場合や、SSHを使ってサーバー公開をする場合などは、C:\Gitのように短めで、間にスペースが入らないディレクトリに設定してインストールをします。 VSのGit拡張や、その他Git関連ツールと組み合わせる
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
追記(2.x): Git for Windows は2015年8月にリリースされた 2.5.0 以降日本語まわりの問題もいくつか改善されているので追記しました。 2.x 系では開発ベースも変わり、もはや msysgit ではなくなったので、本稿のタイトルも変更させていただきます。 "Git for Windows"(いわゆる Git Bash)は Windows 上で git 利用を可能とする bash シェル環境だ。 Gitが使えるだけでなく、オールインワンで基本的なコマンドを備え、 ssh, perl, curl などのツールも入っていて、cygwin なんかに比べお手軽かつお得な環境だ。 筆者の周りでは "Git Bash" で通用している。 かつては日本語を扱うのが面倒であったが、1.8.3 から Bash 上で日本語入力できるようになるなど、最近の状況はだいぶよくなっている。 $
gitで日本語ファイルが文字化けする こんばんは。小室です。gitを使っていて日本語のファイル名を入れるとファイル名の表示が崩壊するという経験をしました。 割と今までは放置していたのですが、きちんと日本語ファイル名を表示するコマンドを教えてもらったため、備忘録として記録しておきます。 若干人を小馬鹿にしたようなファイル名のファイルを配置したディレクトリをサンプルとして用意しました。 $ ls -la total 8 drwxr-xr-x 4 komurohiraku staff 136 Mar 25 19:09 . drwxr-xr-x 22 komurohiraku staff 748 Mar 25 19:08 .. drwxr-xr-x 10 komurohiraku staff 340 Mar 25 19:08 .git -rw-r--r-- 1 komurohiraku staff
SourceTreeは、MacOSX用のgitフロントエンド。 例に漏れずUTF8-MAC問題を抱えている。他OSで作成されたリポジトリに日本語ファイル名や、その他マルチバイト文字、アクセント記号付きアルファベット等を含むファイル名が含まれている場合、正しく扱うことができない。 それは、バックエンドのgitが古いバージョンだから。 この記事では設定方法を紹介する。 ステップ1 Gitをインストールする まず、以下の記事の手順を参考にgit 1.7.12以降のgitをインストールする。 git 1.7.12でUTF8-MAC問題が解決 ステップ2 SourceTreeが新しいGitを使うよう設定する 次に、SourceTreeの環境設定で、Gitタブの、「システムのGitを使用する」ボタンを押す。 SourceTree設定画面 ファイル選択ダイアログが開くので、先ほどインストールしたgitの
gitの唯一の弱点は日本語ファイル名に弱いことだ。 つい最近WindowsではUTF-8ファイル名に対応したが、MacではUTF8-MAC(UTF-8-MAC)問題という持病を抱えていた。 このため、WindowsやLinuxで濁点、半濁点とかの入った日本語ファイル名のファイルを含むリポジトリを作成し、Mac上にcloneすると、次の画像のようにこれらのファイルをリポジトリ内のファイルとして見なしてくれないと言う問題があった。 日本語ファイル名が使えなかった旧バージョンのgit 簡単に説明すると、ファイル名の見た目はLinux等と一緒だが、文字コード的に濁点の扱いが微妙に違うためである。ある意味、文字化けの類の問題である。この説明はかなり端折っていて不正確なので、技術的な詳細はこちらを参照して欲しい。 これまで、解決するにはnfsをマウントする方法や、パッチはあったが、本家では取り込まれて
(★2014年09月時点の情報です。最新の Git では解決しているかもしれない。) Mac の Git で日本語ファイル名を扱うときは core.precomposeunicode = true にしておく。 clone, checkout したら日本語ファイル名のファイルが新規ファイルになってるとか git status で確認したらファイル名が \xxx になってるとか そんな症状に出くわしたら。 普段仕事だと Windows だし、自分で日本語ファイル名とか作らないし、普段おっかけてるリポジトリにもそんなの無かったので、未設定なのに気付いてなかったわ。Visual Basic なレガシーなプロジェクトを Mac で読もうとして気付いた。 既に clone 済みのローカルのリポジトリでは $ git config --local core.precomposeunicode true
次回以降の流れは?(2016/04/11 0時 追記) マンガでわかるGitの構成は、ざっくり下記の構成を考えています。 最初の一歩: Gitとはなんぞや? 第一フェーズ: 1人で使ってみる 第二フェーズ: 複数人で使ってみる 第三フェーズ: 実務上でのハウツー(応用) これは、まだ私が頭の中で考えているだけの仮段階のものですので、細部はみなさんからのコメント・需要を拝見しながら変更していくと思われます。 ちなみに、はてブコメントで要望の多かった「SVNとGitの違い」 → こちらのマンガ化はやってみたいですね。 #マンガでわかるGit 全体の構成(仮)考えるの楽しい♫ Gitってそもそも何?メリットは? ↓ 一人でGit😃 ↓ 複数人でGit😃😃 の流れで考えています。 はじめてコミット、チェックアウトしたときの感動といったら! pic.twitter.com/uyCl1zAxAF
クロスプラットフォームのGUI Gitクライアント「GitKraken」が公開されています。現在パブリックベータテスト中で、公式サイトよりMac / Windows / Linuxに対応した実行ファイルを無料でダウンロードして使用することができます。 最近流行のElectronを使用して作成されたソフトウェアのようで、libgit2やNodeGitといったオープンソースライブラリも組み込まれています。 Electron風の美しいGUI ▼メイン画面は以下の通り。 コミット履歴やブランチの分岐が美しく表示されているのが印象的です。コミットやブランチの作成/マージ、pull/pushといったGitの操作をGUIを使って行う事ができます。 ▲設定画面を使って「git config」の設定や、sshの鍵の管理、GitHubやBitBucketといったサービスの認証情報の管理、Git Flowの設定
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください!(時々アプデしてます)↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-buRead less
このサイトのテーマはgithubで管理しています。 ただgithub上でソースを管理し ローカルで修正 → githubにpush → Webサーバーでpull としても便利なのですが、githubにはwebhookという機能があり、githubのレポジトリに変化があった時に任意のURLを叩いてもらうことができます。 この機能を使うことでレポジトリにpushした時に自動的にサーバーを更新することができます。 Webサーバーの設定 まず、Webサーバーにgithubから叩いてもらうプログラムを置きます。 今回はこのサーバーにはWordpressのためのPHPが入っているので、PHPで以下のように書きました。 hook.php <?php $LOG_FILE = dirname(__FILE__).'/hook.log'; $SECRET_KEY = '** secret **'; if (
原文は 2015 年 4 月 17 日に掲載されました。 ※ この記事は「チュートリアル」からの転載です。 今年 4 月は、Git サーバーの誕生記念でした。Git は、Linus Torvalds が開発した バージョン管理システムです。Git は、世界中のまさに国境を越えた何百万というユーザーに使われています。 GitHub のような Git を使ったコード ホスティング サービスを提供している会社がいくつもあります。あるレポートによれば、GitHub は世界最大のコード ホスティング サービスだそうです。GitHub は 21.8Mバイト のリポジトリを管理し、ユーザーは 9,200,000 人います。大会社も GitHub に移行しつつあります。検索大手の Google でさえも、Google Code を止めて GitHub に移行しています。
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
※この記事は元々「Gitのこれやめて!リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで!!」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く