セキュリティの脆弱性を再現するために下ネタを出力するリポジトリ(POC)を遊びで作ったら、脆弱性チェックのスタンダードとして国内に普及してしまった話。 Gitなどのバージョン管理システムのアップデートがまだの方はお早めにアップデートを。。
はじめに 全国で5000人くらい*1はいると思われるComputerCraftユーザーの皆様こんにちは。 今日はまず、こちらの動画を紹介します(ニコ動です)。 職業プログラマーならばさほど問題ないのですが、僕を含む趣味プログラマは、日々、独自の作法でCCプログラミングをしています。 しかし、そのコードが他人からみて見やすいのか、変な癖がついていないか、そしてよりよいコードにするために何を心がければ良いか。 一人孤独にCCプログラミングしていると不安になりますよね。 「誰かに見てもらえないかなー。チラッチラッ。でも恥ずかしいしなぁ・・・。悩ましい悩ましい」 そこで、この動画です! なんと、マサカリを投げてくれるCCプログラムのコードレビューをしていただけるとのこと。 すばらしい! この機会を逃す手はありませんよね。 動画でコードレビューの説明を聞き、コードレビューを受けるときの心構えを理解し
コミットログには"Why"を書け? よくコミットログには「何をしたか」ではなく「なぜその変更をするのか理由を書け」と言われます。 これは確かに一理あります。 例えば、コミットログに などと書かれていたとすると、「いやいや、そんなのはgit log -pすればわかるでしょ。何で変更するのかその理由を書いてよ」と言いたくなります。 そこでチームの規約で「コミットログには理由を書くこと」と定めたとします。 まあよくある話ですね。 そうすると、コミットログはこうなるでしょう。 さあこれでよいでしょうか? 「理由」を突き詰めると「生きる理由とは?」になってしまう これは確かに立派な理由かもしれませんが、「ではそれは何のために?」と理由をさらに深堀りする人がいるかもしれません。 「なぜその変更がSEO的に有効なのか?」 「そもそもなぜSEO対策が必要なのか?」 これらの疑問はもっともです。 コミットロ
Too Long; Didn't Read<a href="https://hackernoon.com/tagged/git" target="_blank">Git</a> had a <em>huge</em> year in 2016, with five feature releases<a href="#c8e9">¹</a> (<em>v2.7</em> through <em>v2.11</em>) and sixteen patch releases<a href="#408a">²</a>. 189 authors<a href="#315b">³</a> contributed 3,676 commits<a href="#dbfb">⁴</a> to <code class="markup--code markup--p-code">master</code>, w
A Vim plugin which shows a git diff in the sign column. It shows which lines have been added, modified, or removed. You can also preview, stage, and undo individual hunks; and stage partial hunks. The plugin also provides a hunk text object. The signs are always up to date and the plugin never saves your buffer. The name "gitgutter" comes from the Sublime Text 3 plugin which inspired this in 2013.
vim-gitgutter github.com vim-gitgutterというプラグインを使うと、Gitで管理しているファイル編集時に差分を表現する記号が左端に表示されるようになる。 ~が変更があった行、+が追加行、-が削除された行があることを示す。 インストール NeoBundleの場合は下記行をvimrcに追加。 NeoBundle 'airblade/vim-gitgutter' 使い方 インストールが完了すればデフォルトで有効になっているので設定を特に追加しなくてもよい。有効無効の切り替えは下記コマンドで可能。 :GitGutterToggle また、下記コマンドを実行すると行ハイライトの有効無効が切り替えられる。 :GitGutterLineHighlightsToggle 起動時に行ハイライトを有効にしたい場合は下記行をvimrcに追加。 let g:gitgutter_h
これを実行すると、エディタが立ち上がって、sampleブランチの直近3個のコミットが見れます。 以下この3つのコミットを一つにまとめてみる。
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
Home技術者ブログGit:手元にある古い古い状態のブランチをoriginの最新のもので更新したいけれどいちいちcheckoutしたくない場合にどうすればいいかという話 Git:手元にある古い古い状態のブランチをoriginの最新のもので更新したいけれどいちいちcheckoutしたくない場合にどうすればいいかという話 #git#vcswar 2012年 10月 16日 kana 問題 git checkout another_branch にすら時間がかかる……というのは大規模なプロジェクトだとありがちです。 例えば 自分が長期休暇を取ったら自分の居ない間に盛大なリリースが行われmaster にコミットがとんでもなく積み重なっている という状況を考えてみましょう。 普通なら
間違って.DS_Storeがgitリポジトリに混ざった状態でコミットしてしまったらしく,後になって指摘されて初めて気付くというgit初心者っぽりを遺憾なく発揮してしまった.確かにコミットのコメントが全然違う部分にも適用されてて,変だと思ってはいたのですが.....自分にとっては初めての多人数での共用リポジトリなので,もう少し注意しなければ. 現状確認 $ git log --stat commit ... Author: yag_ays <...> Date: Tue Jan 17 21:30:01 2012 +0900 ... /.DS_Store | Bin 0 -> 6148 bytes /src/.DS_Store | Bin 0 -> 6148 bytes ... (ノ∀`) アチャー.ごめんなさい.... .gitignoreの設定 ということで..gitignoreを設定して
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる? コミットが綺麗になる! 以上です! この一言に尽きる! 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか? 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います! マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
例えばtmpファイルを置くディレクトリだけgit管理下に置きたいなど 空ディレクトリはgit管理したいが、中にあるファイルはgit管理したくないような場合は、 1. 管理したいディレクトリの中に.gitkeepファイルを作成 $ touch /tmp/.gitkeep 2. .gitignoreでtmpフォルダ内の.gitkeep以外を無視させる .gitignoreに下記を記述。 tmp/* !.gitkeep※ !.gitkeep は最後に記述すること これで tmpフォルダ内に置かれたファイルはgit管理下に入りませんが、 .gitkeepが生きているので空フォルダでgit管理下に置くことができます。 入門git 作者: Travis Swicegood,でびあんぐる出版社/メーカー: オーム社発売日: 2009/08/12メディア: 単行本(ソフトカバー)購入: 25人 クリック:
photo by V Threepio .gitignoreファイルについて 代表的なgitの追跡から逃れる方法。 このファイルに記載されているファイルは、gitの管理下に置かれなくなる。 注意点として、既にgitの管理下に置かれているファイルに対しては、.gitignoreファイルに記載しても無力なため、 git rm --cashe <ファイル名>などとして、gitから削除する必要がある。 当然ながら、リポジトリからファイル自体も削除されることに注意。 .gitignoreの作り方 Windowsの場合「.gitignore」というファイル名では作成出来ないので、 「.gitignore.」(どっと ぎっといぐのあー どっと)というファイル名で保存する。 なお、サイトによっては「.ignore」でOKみたいなことも書いてあったりするけど、.gitignoreが正解。 また、.gitig
はじめに git pushを取り消すメモ。 ほとんど手順メモ程度な感じ+他記事で使うスニペット記事。 とはいえ、数あるgit便利コマンドの中で毎回使うものではないけど いざって時に役立つ、もしくは、困るのは取り消し系のコマンドですよね。 補足 他の取り消しもぱっと見たい自分用にまとめたので参考までに。 【git】add、commit、push、merge、pull request、merge pull requestの取り消し アジェンダ git resetでmasterへのgit pushを取り消す git resetでbranchへのgit pushを取り消す git resetでリモートのみgit pushを取り消す git revertでgit pushを取り消す commitの取り消しと操作は似てるのでそちらも参考にしてみてください。 →【git】git commitを取り消す
HEAD の位置を移動する方法 間違えてコミットやマージをしてしまった場合など、以前のコミット状態に戻したい場合もあると思います。 その時には、まずは "git log" を実行して、直前のコミットに割り当てられた ID を確認したら、それを使って次のようにします。 git reset --hard コミットID このようにすることで、ワーキングコピーを含むすべての状態が、指定した ID の状態に戻ります。 "git reset" には "--hard" のほかにもいくつかオプションが用意されているので、それについても簡単に整理してみます。 HEAD Staging Working --soft
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く