コミットはスナップショットであり差分ではない
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
masterブランチでちょっとした変更をしたいんだけど、devブランチで作業しているから切り替えるのはめんどくさい。 そんな時はgit worktreeを使ってみてください。複数のブランチを切り替えずに操作できます。 ※git worktreeを使うにはGit 2.7.0以降が必要です。それ以前のバージョンだとgit worktree listがありません。 ブランチの追加 操作したいブランチはこんな風に持ってくることができます。 すると、作業ディレクトリ以下に指定したブランチの中身がリンクされます。 たとえば、git worktree add ./worktree-dev devとコマンドを打つと、./worktree-devディレクトリが作成され、その下にdevブランチの内容ができるわけです。 git worktreeは今いるブランチに影響を与えません。 つまり、作業中であっても操作し
Gitの脆弱性によってリポジトリをクローンすると「うんこもりもり」と表示される - BppLOG
8/11にGitの脆弱性 ( CVE-2017-1000117 )が出ていました。 CVE-2017-1000117 - Red Hat Customer Portal これは、gitクライアント上での任意のshellコマンド実行の可能性があります。 重要度 - Important Gitでの"ssh"URLハンドリングにshellコマンドインジェクションの欠陥が見つかりました。これを利用して、悪意のあるレポジトリや悪意のあるコミットを行われたをレポジトリに対して"clone"アクションをGitクライアントで実行した際に、Gitクライアントを実行したユーザの権限でshellコマンドを実行される可能性が有ります。 Gitの脆弱性 ( CVE-2017-1000117 ) — | サイオスOSS | サイオステクノロジー 実際にどんなことが起きるか 百聞は一見にしかず。 このリポジトリを cl
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
先日開催されたAWS Summit Tokyo 2017、わたしもいくつかセッションを聴講してきたのですが、「DevSecOps on AWS - Policy in Code」というセッション1にてgit-secretsというツールが紹介されていました。 awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories これ以外にも、いくつかのセッションで言及されていたと思います。 git-secretsのことは以前から聞いてはいたのですが、自分自身があまりコードを書く環境にいなかったので、良くないとは思いつつも今まであまり気にしていませんでした。 ただ、AWSアクセスキーの漏洩が原因と思われる話を聞く機会はなかなか減りませんし、考えてみれば自分でも、AWSクレデ
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
これまで知らなかったGit機能を調べたまとめ - Qiita
変更のdiffを見ながらコミットメッセージを書く 教えてもらってから活用してる。見ながら書いたほうが具体的に書けるような気がする。 $ git commit -v 変更のdiffを見ながらコミットメッセージを編集できます # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch commit-v # You are currently bisecting, started from branch 'test-git-bisect'. # # Changes to be committed: #>modified: fruits.txt # # -------
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
gitで管理しないファイルを無視させる .gitignore - misc - @OMAKASE
.gitignore とは名前からも分かるように git で無視するファイルを指定するファイルです。 .gitignore は通常トップディレクトリに置きますが git ではディレクトリのみを管理しないためルートディレクトリ下のサブディレクトリなどにも置く事が可能です。 .gitignoreで指定できる書式 ハッシュ記号で始まる行はコメントとして扱われる 空行は無視される ! マークで始まる行は残りのパターンを否定します スラッシュ/で終わる場合はディレクトリのみを表す スラッシュ/で始まる場合はルートディレクトリからを表す どこにもスラッシュ/が無い場合はシェルのglobパターンとしてファイル名のベース部分にマッチするか検査される 複数マッチするパターンがある場合は最後にマッチするものが優先される 設定できる.gitignoreパターン色々 *~ ファイル名の最後に ~ がある全てのファ
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
404
File Not Found アクセスしようとしたページは 見つかりませんでした。 以下のような原因が考えられます。 記事が削除された URLが間違っている
GitBucketのユーザインターフェースの変更について - たけぞう瀕死ブログ
2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。 それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。 1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。 2点目については（ユーザインターフェースに関する権利については諸説あるようですが）、GitBucketが「GitHubク
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
Gitはじめの一歩
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください！（時々アプデしてます）↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-bu
Git 2.7 の優れた新機能 | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git 2.6 からわずか 2 カ月後、膨大な機能と修正、そして性能の向上を果たした Git 2.7 がリリースされました。ここでは Bitbucket チームが興味を持った新しい機能を紹介します。 git worktree の完成 Git 2.5 で導入された素晴らしい git worktree コマンドを使うと、複数のリポジトリブランチからのチェックアウトやブランチ上での作業を、異なるディレクトリで同時に行うことができます。たとえば、簡単な修正をする必要があるけどワーキングコピーを汚したくない場合、次のように新しいブランチを新しいディレクトリにチェックアウトすることができます。 Git 2.7 には、リポジトリのワークツリー (および関連するブランチ) を表示する git worktree list サブコマンドが追加されています。 ワークツリーをサポートする git bisect コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git worktreeを使ってみる - Qiita
SIOS Tech. Lab - エンジニアのためになる技術トピックス
GitHub - awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories
git configをプロジェクトによって使い分ける - Qiita
こわくない Git
