Git security vulnerabilities announced | The GitHub Blog
Open SourceSecurityGit security vulnerabilities announcedGit users are encouraged to upgrade to the latest version, especially if they use `git archive`, work in untrusted repositories, or use Git GUI on Windows. Today, the Git project released new versions to address a pair of security vulnerabilities, CVE-2022-41903, and CVE-2022-23521, that affect versions 2.39 and older. Git for Windows was al
Git で会社のリポジトリとかは自動で別のメアドを使うようにする - 宇宙行きたい
仕事でGit使うときとか普段とは違う会社のメアドでコミットとかしたいんだけど、cloneするたびに git config user.email とかするのメンドイよね〜 というかもうだいぶ有名な設定だと思うんだけどたまに知らない人いるので書いておくと includeif 使うと特定のディレクトリ以下のときに読み込む設定を変更できるので便利です。 で、ここまでは普通にGitのマニュアルにも書いてあるんだけど ghq と組み合わせると最高便利になるのでそのへんの設定を書いておきます。 といっても普通に設定するだけだけど .gitconfig には下記のように書いておいて [ghq] root = ~/src [includeIf "gitdir:~/src/github.com/launchableinc/"] path = ~/.config/git/launchable.inc ~/.co
全リポジトリのコミット前にSecretlintを実行してGitGuardianのお仕事を減らす
# 前置き AWSのSecretをpushしてアメリカから電話が掛かってきてからというもの、GitGuardianからメールが来る度に嫌な汗を掻いている私です。 そんな生活から抜け出すため、 Credentials(秘匿情報)を含んだファイルがないかチェックしてくれるSecretlint と、Gitの特定のコマンドにフックして処理を挟めるGit Hooks を使って、全てのリポジトリでのコミット時にSecretlintを走らせる環境を作っていきます。 なお、私はWindowsユーザーなのでシェルはPowershellで進めていきますが、Unix系のエイリアスを色々追加しているので無意識に使っていたらよしなに脳内変換をお願いします。 Secretlint (opens new window) Git Hooks (opens new window) # 私の環境 git version 2.
Patterns for Managing Source Code Branches
Modern source-control systems provide powerful tools that make it easy to create branches in source code. But eventually these branches have to be merged back together, and many teams spend an inordinate amount of time coping with their tangled thicket of branches. There are several patterns that can allow teams to use branching effectively, concentrating around integrating the work of multiple de
Git clone vulnerability announced
Open SourceSecurityGit clone vulnerability announcedToday, the Git project released new versions to address CVE-2021-21300: a security vulnerability in the delayed checkout mechanism used by Git LFS during git clone operations affecting versions 2.15 and… Today, the Git project released new versions to address CVE-2021-21300: a security vulnerability in the delayed checkout mechanism used by Git L
個人開発者のためのコマンドラインGit使いこなし術
英語で先に書いてから翻訳しています どうも個人アプリ作家のTAKUYAと申します。 Gitはコードベースや変更履歴の管理に必要不可欠なツールです。たとえ個人でアプリを開発していたとしても。 僕はデスクトップとモバイルの両方で動作する、InkdropというMarkdownのノートアプリを独りで開発しています。 当アプリはデスクトップ版はElectron、モバイル版はReact Nativeで作られています。 僕は開発作業は基本的にtmuxとvimでターミナル上で行っています。vimによるJavaScriptコーディングのためのセットアップについては前回シェアしたとおりです。 本稿では、僕のGitのワークフローについてご紹介したいと思います。 内容はすでにGitの基本をご存知の方向けとなります。 Gitの操作も基本的にはターミナル上で行っています。 色んなGUIベースのGitクライアントアプリ
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
gitのdiff-highlightを使い始めた - りんごとバナナとエンジニア
git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま
My favourite Git commit
I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit. This commit is from my time at the Government Digital Service, working on GOV.UK. It’s from a developer by the name of Dan Carley, and it has the rather unassuming name of “Convert template
git-secretsの設定を手元の全Repositoryに反映する。｜teitei.tk｜note
各種秘密鍵をcommitしてしまう場合に警告を出すようにしてくれるツールです。 自分も利用していますが、設定を手元のすべてのrepositoryや、新しく作るRepositoryにも反映したかったので、その手順を書きます。 Installbrew経由でinstallが出来る。 $ brew install git-secrets全repositoryへのルールの追加$ git secrets --add 'your rule' で追加をすることが出来る。 更に--global optionをつけることで、repositoryの垣根を超えてglobalに反映される。 # for AWS $ git secrets --register-aws --global # for GCP @see https://cloudplatform-jp.googleblog.com/2017/08/hel
本の虫: GCCのgit移行が難航中
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
gitのdiffを見やすくする「diff-so-fancy」がとても便利 - BppLOG
git の diff コマンドは差分を色分けしてくれていますが、変更された行単位でしかわかりません。 行の中でどの部分が変更されたのか確認したい・・・ そんなかゆい所に手がとどくようなツールが「diff-so-fancy」です。 左：導入前 右：導入後 変更された部分がハイライトされて可視化されるようになりました。 また、ファイル毎の見出しも表示されるので、視認性も良くなっています。 セットアップも簡単です。 npm install -g diff-so-fancy git diff --color | diff-so-fancyまたlessのTipsとして、以下の設定を行うことでファイル間の移動が簡単になります。 nキーで次のファイル、pキーで前のファイルへと移動できるようになります。 git config --global pager.diff "diff-so-fancy | les
社内リポジトリのサブディレクトリをgo getするにはrepo名に.gitをつける - Qiita
のようなremote import pathによりgo getすることができます。 しかし、この一般的なimport pathでは、go getしたいパッケージがサブディレクトリにあるとき、既定ドメイン(github.comなど)以外、つまり社内リポジトリなどでは、以下のようなエラーが発生します。 たとえば、<domain>/foo/barレポジトリのsub-dirディレクトリをgo getしたい場合、こうなります。 go get <domain>/foo/bar/sub-dir package <domain>/foo/bar/sub-dir: unrecognized import path "<domain>/foo/bar/sub-dir" これは、go getコマンドがimport pathからリポジトリとパスを判別できず、リソースに到達できないことによるものです。 （ここで諦め
gitとsubversionのコマンド対応表 – cyclogy
備忘録がわりにいつも忘れてしまうgit(git-svn)とsubversionのコマンドの対応表をまとめました。 コマンド対比表 subversion git git-svn 更新 svn update git pull git svn rebase コミット svn commit git add → git commit git commit -a (gitコミット後) git svn dcommit git push <url> 追加 svn add <file> git add 削除 svn rm <file> git rm <file> 移動 svn mv <file> git mv <file> 変更取り消し svn revert <file> git checkout <file> ログ svn log git log 差分 svn diff git diff スイッチ svn
100MB超のファイルをコミットしてしまい githubに pushを拒否された時 - ブログ - ワルブリックス株式会社
うっかりgithubに受け付けてもらえないような大きなファイルをリポジトリに追加してしまった時の対策。普通に削除しても消えません。 まっとうなソースコードのリポジトリならそんなことは普通ないはずですが、うっかり100MBを超える大きさのファイルをリポジトリに追加してコミットまでしてしまったとします。 $ git add でかいファイル.tar.gz $ git commit -m 'でっかいファイル追加したった' $ git push remote: error: File でかいファイル.tar.gz is 123.00 MB; this exceeds GitHub's file size limit of 100 MB githubへ pushしようとした時、ファイルが大きすぎるということで拒否られます。あなたは嫌な予感がしつつも、問題のファイルを普通に git rmで削除して再度
GitリポジトリとDockerイメージレジストリを統合した「GitLab 8.8」リリース。開発や継続的統合のワークフローがシンプルに
GitリポジトリとDockerイメージレジストリを統合した「GitLab 8.8」リリース。開発や継続的統合のワークフローがシンプルに GitLabは、Gitリポジトリを中心とした開発ツール「GitLab 8.8」をリリースしました。 GitLabはGitリポジトリ機能の機能に加え、Wikiやイシュートラッキング、コードレビュー、アクティビティフィード、そしてテストやビルド、デプロイなどの自動化を行うGitLab CI機能などが統合された開発ツールです。 GitLab 8.8ではパイプライン機能が強化。パイプラインの状態を画面で参照できるようになりました。 もう1つの大きな機能強化が、Dockerイメージレジストリ機能の統合です。 GitLab 8.8には最初からDockerイメージのレジストリ機能が組み込まれており、インストールするとすぐに使える状態になっています。GitLab CIによ
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
Git 2.x シリーズの 6 つの素晴らしいフィーチャー | Atlassian Japan 公式ブログ | アトラシアン株式会社
私が Git リリース ノートをレビューしてからしばらく経ちましたが 、だからといって私が最新のノートを熱心に読んでおらず、毎日の作業に新たな優れモノを取り入れていなかった訳ではありません。自分の誕生日 (拍手！) と、先日の Bitbucket Server のリリースを祝うため、本日は私が Git 2.x シリーズ (2.6 まで) で気に入っているフィーチャーを全てご紹介します。どれか役に立つようなことがあれば、是非ご一報ください。 リベース前に変更内容をスタッシュ Git 2.6 では、rebase コマンドが皆さんから良い意味での注目を浴びました。以下にご紹介するのは、より興味深い新しいフラグの1つです : git rebase --autostash これからは、rebase 操作の開始時に未コミットの変更内容を一時的にスタッシュするか、操作を失敗させるかを指定できます。この行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SIOS Tech. Lab - エンジニアのためになる技術トピックス
[Cryptography] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers