gitで開発を行っていると、不要なブランチが溜まってきて削除したくなることがあります。 以下のコマンドでgitのブランチを削除できますが、一回のコマンドで一つのブランチしか削除できません。
新しくサーバーに開発環境構築して使い始める時、「git log」「git show」 「git diff」などを使うと、多くの場合、日本語が文字化けしてうまく表示できません。 具体的には、以下の２点がよく問題になります。 今回対応する問題： Gitの日本語文字化けのよくある症状 まずは、（１）の症状です。 説明の簡単のため、「さくらレンタルサーバーを借りたデフォルト状態」を例にとって進めていきます。他のサーバーでも似たような状況ではないでしょうか？（推測） 少なくともさくらレンタルでは、初期状態がどんなかというと、git diffとかやると、下の画像のように「ESC」とかたくさん出力されてしまいます。 感じ悪いですよね。。git log やgit show でも、同じような文字化けが見られるはずです。 スクショ上で、「ESC」で表示されているものは、「文字化け」というよりは、エスケープコー
はじめに PHPのComposerでGit上のライブラリを使いたい時のメモです。 下記を見ればわかる https://getcomposer.org/doc/05-repositories.md#vcs のですが、Composer初心者には当たり前のお約束もわからなかったので残しておきます。 今回やりたかったこと 「とあるPHPのComposerライブラリ」をForkして今後ややカスタマイズしつつ使いたい なので、Github上でForkしてそれをcomposer経由で取ってきたい どうしたか こう書けばOKだった { "repositories": [ { "type": "vcs", "url": "https://github.com/yumemi/oauth2-server-php" } ], "require": { "bshaffer/oauth2-server-php": "
git logに`--`セパレータを利用すれば可能です。 あー、もう削除しちゃっているけどログを確認したいな、という時にぜひ。 $ git log -- <path>ドキュメントには以下のように記載されていました。 git-log(1) [--] <path>… Show only commits that are enough to explain how the files that match the specified paths came to be. See History Simplification below for details and other simplification modes. Paths may need to be prefixed with ‘`-- '’ to separate them from options or the revision
20億行のコードを保存し、毎日4万5000回のコミットを発行しているGoogleが、単一のリポジトリで全社のソースコードを管理している理由 Googleは検索サービスやGoogle Apps、Google Cloud Platformなど巨大なサービスを多数運営しています。その同社は、20億行にもおよぶソースコードの管理をサービスやプロジェクトごとに分けず、すべて単一のリポジトリで管理しているそうです。 先週9月14日にサンノゼで開催されたイベント「＠Scale」で、Googleによるセッション「The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repsitory」（単一コードベースへの取り組み：なぜGoogleは単一リポジトリに数十億行ものコー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はGit Advent Calendar 2015の16日目の記事です。 はじめに この記事を読むと、GitHub と Git を人に紹介する時や、GitHub 導入後に注意すること、GitHub 普及の際のメンタルついて知識が得られます。 ある程度、Git, GitHub の知識があり、これから現場に GitHub を普及させたい方に有用な記事かもしれません。技術的な Tips は少なめです。 目次 どうも、GitHub おじさん、または 一度死んだおじさん こと沖縄の金城です。GitHubについてと人に説明する機会や導入する
プログラマーだけがやっている効率的な仕事のやり方 Only Programmers knows the way to optimize working 2015.08.26 Updated by Ryo Shimizu on August 26, 2015, 17:10 pm JST 先日上梓した拙書「最速の仕事術はプログラマーが知っている」がありがたいことに大変評判なようで、発売4日後に増刷が決まるなど売れ行きが好調のようです。 もともとこんな刺激的なタイトルの本を書いていいのか、という悩みもあったのですが、編集の方の強い熱意と最初のミーティングの段階で完璧に近いところまで揃えられた目次と企画書を見て、「これは時間を割いてでも書いてみたい」と思い、引き受けることにしました。 実際に世に出ても、「やっぱりこれは書きすぎなんじゃないか」「刺激が強すぎるんじゃないか」と危惧していたのですが、A
「Git 2.3.0」では、新たにサーバ上のレポジトリへ、直接変更をプッシュできるようになった。サーバ上における現行ブランチへの変更が、自動的に適用され、簡単にデプロイできるようになる。 ただし、この機能では変更履歴が保存される「.git」ディレクトリが作成されるとともに、変更の適用中は、ユーザーに対して変更前と変更後の混在するデータが提供される可能性があるため、利用にあたっては注意が必要となる。 さらに、リモートレポジトリをクローンする際に、すべてのデータをクローンせず、変更が行われたデータのみクローンすることを可能にしている。また、git pushコマンドのデフォルトの挙動を変更し、上流のブランチが指定されていない場合は、プッシュを行わないようにした。 シェル変数では、オプションを指定してSSH接続できるようにするGIT_SSH_COMMANDや、cronのジョブなどでGitを使用する
こんにちは。 久々の更新です。 最近Schemaというフレームワークを作っており、 PHPでの開発について色々と新たな知識を得る機会がたくさんあります。 そこでまずは開発環境の構築編として、最低限のお作法を担保する Gitのhook を作成してみました。 目的 – 5箇条 それくらいきちんとやれよ という話に尽きるのですが、 自動で確認してくれるに越したことはありません。 プログラマは得てして機械的な確認が苦手な生き物です。楽することに全力であるべきです。 （マジレスをすると、人的要素を排除することで、うっかりや人為的なミスが無くなるので、より確実にコードの品質を担保できます。 ただし、このチェックが通れば完璧というわけではないので、加えて動作確認やコードレビュー等の人的チェックも必要かと思います）。 と能書きはこのくらいにしておいて、具体的にやりたいことは以下の通りです。 PHPの構文チ
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
#Gitチートシート ##用語 ###リポジトリ バージョン管理システムにおいて，プログラムやファイルを蓄積しておく場所． Gitではローカルリポジトリとリモートリポジトリの二種類のリポジトリを扱える． ###ローカルリポジトリ 現在作業中のリポジトリ．主に自分のPCや開発サーバーなどで作業する場合はローカルリポジトリとなる． また，リモートリポジトリからリポジトリをクローンして，自分のPC上やサーバー上に環境を構築することもできる． ###リモートリポジトリ 外部にあるリポジトリ．リモートリポジトリはローカルリポジトリを通じて作業を行う． 複数人での作業やインターネットに公開する場合に利用できる． ###ワーキングツリー ユーザーが編集したり新しいファイルを作成したりする場所． ###インデックス ワーキングツリーでの編集後，リポジトリへのコミットの前に次のコミットの対象となる状態を保持
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
昨日は git fetch --prune がでてこなくて、同僚(的な人) に教わりました。帰宅後「Git によるバージョン管理」を読んでいたところ、git fetch と git pull と git remote update の違いについての端的な説明がありました。 git fetch リモートブランチから情報を取得するだけで、チェックアウトしているブランチにマージしないコマンド ワーキングツリー、インデックスには影響を与えない ローカルブランチに反映せずにリモートリポジトリにあるブランチの内容を git log で確認したり、git diff で差分を確認したりできる 取り込まれたリモートブランチの HEAD は FETCH_HEAD に格納される git pull リモートブランチから情報を取得して、チェックアウトしているブランチにマージするコマンド git remote upd
おお、これは企業で使えそうですよ！ 企業によっては外部にソースコードを預けられないため、自社でGitサーバを構えているところも多いでしょう。しかしそうなると管理画面が欲しくなります。GitHubの管理画面は優秀で、ああいったWebブラウザ上でリポジトリの情報を見たいと思うはずです。 そこで使ってみて欲しいのがGitonomyです。デザインの格好いい、Gitリポジトリマネージャです。 Gitonomyの使い方 GitonomyはPHP + Symfonyの組み合わせで作られていて、Webブラウザ上でGitリポジトリの操作が一通りできるようになっています。ユーザはプロジェクト単位にグループに入り、そこで権限管理される仕組みです。 ソーシャル機能はありませんが、企業ユースであれば十分ではないでしょうか。社内でGitサーバを立てている場合はぜひ導入を検討してみてください。 GitonomyはPHP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
