Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Gitは最初1244行しかなかった
概要 Junio C Hamanoさんに興味を持って調べていると、Linusさんが書いたGitの初版は1244行ということが分かりました。Gitの初版について、軽く行数の確認とビルドチャレンジをして、あまり調べずに動かしながら機能を推測してみました。 はじめに Highlights from Git 2.39 の冒頭で登場するcommit数が一番多い方「Junio C Hamano」さんを知らなかったので調べてみました。 gihyoのインタビュー記事が面白かったです。Junio C HamanoさんはGitのメンテナで、LinusさんからGitのメンテナを引き継いだすごい方だということを知りました。 このgihyoのインタビュー記事の中で「MLで流れてきたGitのコード行数は1244行だった」というところが気になりました。調べてみると、2020年にTwitterでRui Ueyamaさんへ
コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
OpenJDKのソースコード、GitHubへの移行を完了
OpenJDKプロジェクトは、ソースコードのリポジトリをGitHubへ移行する作業が完了したことを発表しました。 jdk/jdk repository transition to Git, GitHub, and Skara is done https://t.co/uLKvfY8i5l — OpenJDK (@OpenJDK) September 7, 2020 これまでOpenJDKのソースコードは分散ソースコード管理ツールのMercurialを用いて、OpenJDKのWebサイト上（https://hg.openjdk.java.net/）で管理されていました。 2019年7月に提起された「JEP 357: Migrate from Mercurial to Git」で、コミュニティのソースコードリポジトリに関してMercurialからGitへの移行が提案され、同年11月の「JEP
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
Macでgitのcredential.helper=osxkeychainにアアアアアッてなって削除した話 - ロップップ
きっかけ メインとサブ二つGithubのアカウントを持ってて、 あるリポジトリでサブのアカウントでpushしようとしてもうまくいかない（Permission denied hogehoge to main-account になる。） 確認 originはhttpsで設定してある。 git config --local user.name等の設定はしてあり、 git logで見てみてもコミットログはきちんとサブアカウントのほうで行っている。 わからん……と git config --list でみてみると credential.helper=osxkeychainという記述がある。 いつ設定したかもう忘れているけどいつの間にか……これだ…… removeできない git config --global credential.helper git config --global --unset
マンガでわかるGit 10話「masterブランチを守れ！〜危険な強制プッシュ〜」 | リクナビNEXTジャーナル
masterブランチを守れ！ 〜危険な強制プッシュ〜 そ、それはだな……ごにょごにょ わかばちゃん、私がリモートリポジトリのmasterブランチをプロテクトしておいたわ。これで、たとえ強制プッシュしてしまってもエラーで失敗するだけよ。 思う存分Gitしてね。 あ、ありがとうございます。 エルマスさんって、なんていうか、強いですよね……。 特定のブランチをプロテクト（保護）しよう リモートリポジトリ上にある特定ブランチへの強制プッシュを、未然に無効化しておきましょう！ GitHub編 1.GitHubを開いて、Settings → Branches → Choose a branch の順にクリックします。 2.Protected branches 欄の、 Choose a branch をクリックし、保護したいブランチの名前を入力します。 3.Protect this branch のチェ
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
余計な差分“No newline at end of file”を何とかしたい - Qiita
とあるファイルをVimで修正して保存したら、元のファイルに改行コード(\n)がなくて Git等で余計な差分が出て困る場合の対処方法 事前にファイル末尾に\nがないやつを探し出して、一括修正する。 例えばカレント配下の*.jspなら find . -type f -name '*.jsp' -exec sh -c "tail -1 {} | xxd -p | tail -1 | grep -q -v 0a$" ';' -exec sh -c "echo >> {}" ';' やっていること find -execで見つかったファイルに対して処理。ここではsh -cでダブルクォート内部をシェル実行。’;’は-execの終端子。 tail -1で最終行のみ出力 xxd -pで素のhex dump grep -q -v 0a$でサイレントモードで末尾に0a(=\n)が無い物を探す。 見つかった末尾改
GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenJDK が Github へ移行