「Git for Windows」v2.5.0が公開、プレビューを脱した初めての正式リリース
Gitで管理しているコードをポスター化できるサイト「Commits.io」 | ライフハッカー・ジャパン
フォームローラーでほぐし続けた結果...ようやくわかった効果とメリット3つ #Amazonプライムデー
空のディレクトリをgitで管理するには.gitkeepを使う（.gitignoreは使わない） - YomuKaku Memo
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins （vendor/pluginsは中身が空なので何も出力されません） 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
異なるgitリポジトリ間でもcherry-pickはできる - Qiita
git cherry-pickは異なるリポジトリ間でも使える。 なんとなく似てるコードがいろんなリポジトリにある。。。残念な状況だけど。 そんなとき点在している同じコードに問題が見つかったら一生懸命修正して回ることになるけど、ちょっとでも楽したい。 （修正を導入したいリポジトリ内で） git remote add FIXED_REPO {すでに修正を導入したリポジトリのURL} git fetch FIXED_REPO git cherry-pick {FIXED_REPO上のコミットのSHA1} git push origin master （最初に修正を導入したリポジトリ内で） git remote add TO_FIX_REPO {これから修正を導入したいリポジトリのURL} git fetch TO_FIX_REPO git checkout -b TO_FIX_REPO-mast
巨大なリポジトリ を Git で上手く扱う方法 | Atlassian Japan 公式ブログ | アトラシアン株式会社
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
git リポジトリの最新の履歴だけを取得する shallow clone - Qiita
git でリポジトリを clone した場合、通常は元のリポジトリを丸ごと取得してきます。 しかし、最新版が取得できればそれでよい、過去の履歴情報はいらない、という場合もあるかと思います。そんなとき、次のようにすればリポジトリを丸ごと取得せず、最新版だけ取得できます。 これは、git のマニュアルでは shallow clone と呼ばれています。 オプション depth に渡す値は、取得する履歴の数です。上記では 1 を指定しているので、最新のみを取得します。depth 1 で shallow clone したリポジトリで git log を実行すると、ログが 1 つしかないのが分かります。 利点 変更履歴が多くて通常の clone では時間がかかるような git リポジトリの場合、shallow clone を使うことで通常の clone より速く最新版を取得できます。 とりあえず最近
Gitの便利な-pオプション四兄弟 - エンジニアをリングする
この記事はGit Advent Calendar 2014の6日目の記事です！ （更新がお昼になってしまいました、ごめんなさい＞＜） みなさん！ Gitの-pオプション使ってますか？ 今日は便利な-pオプションを使えるコマンドと、使いどころをご紹介します！ 紹介する内容 git add -p git stash -p git log -p git stash show -p git checkout -p git add -p きっとこれが一番有名ですね！ 追加したい変更を、ファイル単位ではなく差分のブロックごとに追加していくことができます。 Git管理されているindex.htmlに、以下の修正を加えたとしましょう。 ヘッダーのメニューの文字を小文字から大文字に変更 Contactに新しいリンクを追加 このまま両方まとめてコミットしてコミットメッセージに両方の内容を書いておくというのもひ
初心者がプルリクまでに覚えるべきたった 9つの厳選 Gitコマンド - akiyoko blog
この投稿は 「Git Advent Calendar 2014 - Qiita」 の 2日目の記事です。 2年前の 「Git Advent Calendar 2012 - Qiita」 では、「Gitコマンド総選挙」と題して、本当に使える Git コマンドのベストテン発表というネタを書いたのですが、今振り返ってみても、Git コマンドって、よく使うものから普段あまり使わないものまで様々なコマンドが取り揃えられていて至れり尽くせり感がある一方で、Git 初心者が覚えるにはぶっちゃけ 数が多過ぎて辛い ですよね。 そこで今回は、Git 初心者がプルリクできる ようになるまでに覚えるべきコマンドを絞りに絞って、9つだけ紹介したいと思います（9つでも多いよ！というツッコミは受け付けません！）。 【コマンド その１】 git clone 【コマンド その２】 git log 【コマンド その３】 g
How to use git-ftp
最近「寺子屋」と称して個人レッスンというか、数名規模の私塾みたいなことをやっているこもりです。こんにちは。 寺子屋については年が明けてからあらためてお知らせするとして、寺子屋の参加者の皆さんの間などでよく「Gitは使ってるんだけど、アップロード先がFTPしかだめで…。どうにかなりませんかね？」みたいな質問を受けることがあります。もったいないですね。手元は効率化できてるのに、最後の最後がそれじゃ。 アップロード先がFTP（とかSFTP）しか使えない場合は、「dploy.io」とか「Deploy」みたいにGitHubとかBitBucket、自分のリモートのリポジトリからデプロイだけやってくれるサービスを使ったり、むしろその辺も一緒くたになった「Beanstalk」みたいなのを使うと簡単なのですが、いかんせんそれなりにお金はかかります（その辺の話はここに書いてます）。 dploy.io – Co
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
普通のpatchコマンドで取り込めるdiffファイルをgitで作成する - kanonji’s diary
まとめ $ git diff --no-prefix HEAD~ > thisis.patch $ patch --dry-run -p0 < thisis.patch $ patch -p0 < thisis.patch git diffに--no-prefixをつける事で、普通のpatchで当てられるパッチファイルを出力できます。この例ではHEADの1個前*1からHEAD*2までのパッチです。 普通のpatchコマンドのほうの知識があまり無くて-p0がいまいちよく分からないんですが、git diff --no-prefixで作成したパッチファイルを当てるには必要みたいです。--dry-runは、実際には当てないけど当てた場合の結果を出力します。なので、まずは--dry-runで確認して、問題が無ければ実際にパッチを当てます。 エントリー書いた後に教えてもらった補足 patch -p1の
Git Submodules: コアコンセプト、ワークフロー、コツ | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git を使った開発では、サブモジュールを使うことによって、他のプロジェクトを自分のコードベースに取り込めるようになります。それも、他のプロジェクトの履歴を分離しつつ、あなたのプロジェクトの履歴と同期できるようになるのです。これはベンダーライブラリ問題や依存関係問題を解決する便利な方法です。git に関してはいつもそうですが、このアプローチもかなり自己流なのでうまく出来るようになるまで少しばかり研究することをお勧めします。submodules に関する好例や詳しい説明はすでに公開されているので、ここでまた繰り返すのはやめることにします。この記事では submodule という機能を最大限に活用するのに役立つであろういくつかの面白い情報を共有したいと思います。 目次 コアコンセプト 考えられるワークフロー 初めての人向けの役に立つコツ サブモジュールを自分のフォークしたリポジトリで置き換える
git submoduleはコミットへのシンボリックリンクである説 - hell0againのチラ裏
個人的にgitで思った通りの挙動をしないコマンドナンバー2、それがsubmodule。ちなナンバー1はrebase。 submodule自体、使い込むとたいへん便利な機能なのは間違いないものの、誤解をされやすい挙動をするので扱いにくい感じがある。特にチームで使うとなると全員がsubmoduleを理解していないとハマる人が続出しがち。 なので最近はあれはコミットへのシンボリックリンクだ、と説明してごまかしていたりする。 例えばひとつのリポジトリからライブラリ的なものだけを切り出したり、アセット的なものだけを切り出して別途管理したくなることがよくありまして。そういうときにsubmoduleを使って複数のリポジトリに分割すればスッキリするんじゃね、って考えるわけです。 で、いざsubmoduleを使って分割してみたら submodule 配下がなぜか空だったり、なぜか更新されてなかったり、なぜか
エンジニア3人で支える月間10億PV
・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
GitHub実践入門、Pull Requestによる開発の変革。GitHub Kaigi 2014
GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。GitHubを利用した開発は、スタートアップやオンラインサービス系の企業などを中心に広まりつつあり、いままさに数多くのノウハウの交換が求められているツールでもあります。 本記事ではGitHub Kaigiの最初のセッションとなった大塚弘記氏の「GitHub実践入門 ─ Pull Requestによる開発の変革」の内容をダイジェストで紹介します。 GitHub実践入門 ─ Pull Requestによる開発の変革 大塚弘記といいます。会社でもリアルでもほとんど@hirocasterと呼ばれています。 今日はメッセージを3つ持ってきました。まず、GitHubを使っている世界と使っていない世界についての話を少し。次に、GitHubを使っているけれど、十分に使っているかどうか、という話をして、最後に本
いざという時のためのgit reflog - Qiita
Git Advent Calendar / Jun. 29日目の記事です．28日目は@uasiさんの「どこでも使える git diff と git apply」でした． 「間違ってマージしていないブランチを消した」「reset --hard HEAD^*で戻しすぎた」ということがたまにある． しかしgit reflogを使うと(GCされていなければ)過去のあらゆるコミット履歴を見ることができ，git logやgit branchでは辿り着けない時点まで戻すことができる． $ git reset --hard HEAD^^ # HEAD^と指定するつもりが間違えた! $ git reflog f5cb888 HEAD@{0}: head^^: updating HEAD b0b8073 HEAD@{1}: merge @{-1}: Merge made by the 'recursive'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンセプトから理解するGitコマンド
分散型バージョン管理システム「Git」に脆弱性、任意のコマンドが実行される恐れ
ブランチの構成を保ったままrebaseする - Qiita
https://muan.co/2013/07/21/git-weddnig-speech/