三井住友銀行（SMBC）が行内で使っている業務システムのソースコードの一部が流出していたことが2021年1月29日、明らかになった。Twitterなどのソーシャルメディアで、2021年1月28日の夜ごろから流出の可能性が指摘されていた。三井住友銀行が1月29日に事実関係を調査し、行内システムのソースコードの一部と一致したことを確認した。 一部のソースコードが公開されていたのは米ギットハブが運営する「GitHub」。日本在住で三井住友銀行のシステム開発に関係した人物が投稿した可能性が浮上している。三井住友銀行は日経クロステックの取材に対し、「当行が利用しているシステムのソースコードが公開されていたのは事実。顧客情報の流出はなく、セキュリティーに影響を与えるものではないことは確認済み」（広報部）と説明している。 三井住友銀行によれば、公開されていたコードは複数ある事務支援系システムの1つに含ま

プログラマー歴20年の艦これ提督が 作ったプログラムを入れると年収を査定してくれるからと 手持ちのプログラムを全て入れてしまい SMBCとNTTと警察庁、日銀、埼玉県庁で使っているソースコードGithubで世界中に公開してしまう

Gitの仕組みを学び、Rustで実装する内容をまとめました。 Gitの仕組みの部分は無料公開されています。

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機

注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ

イラストの管理 自分はたまにイラストを描いたりするのですが、以前からその管理方法に苦労していました。 苦労していた点は主に次の 2 点です。 バックアップ 制作過程 Gif をつくるのが面倒くさい 強い人は、短時間でもさらっとイラストを描いてしまいますが、自分は時間をものすごく掛けないとまともなものが描けないので、バックアップは結構頻繁に取ります。 手動でバックアップしようとした場合は、ふつうにファイルを複製する感じになると思います。 ただ、普段からコードを書いていて VCS を利用している身だと、どうしても原始時代かと錯覚してしまいます。 さらに、PhotoShop の psd 形式や CLIP STUDIO PAINT の標準である clip 形式はいろんなデータが詰め込んであるので 1 ファイル当たり平気で 50 MB くらい持って行かれます。これも結構厳しいところです。 VCS を

GitHubのイベント「GitHub Universe 2016」がサンフランシスコで開幕。初日の基調講演に登壇した同社CEO兼共同創業者のChris Wanstrath氏は、GitHubの新機能として「Projects」を発表しました。 Chris Wanstrath氏。 Issueを管理する方法は機能これまでも改善を続けてしてきたが、この新機能はおそらく過去最大の新機能だ。 必要十分にしてシンプルなIssueのトラック機能として、「Project」を発表する。 「ボード」と「カード」を備えており、カラムを設定して名前を自由に決め、カードをドラッグ＆ドロップで配置できる。

We've detected unusual activity from your computer network To continue, please click the box below to let us know you're not a robot. Why did this happen? Please make sure your browser supports JavaScript and cookies and that you are not blocking them from loading. For more information you can review our Terms of Service and Cookie Policy. Need Help? For inquiries related to this message please co

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ

前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある 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 する際には

はじめに リポジトリを共有モードにするのを忘れていてトラブったので、解決した際の方法を紹介します。 今回は、 ssh経由でアクセスことが前提です。 http/https を利用する場合は別途手順がありますので、機会があれば後日紹介します。 解決方法 まず、 Git リポジトリをチームで共有する際には、 --shared オプションを付与し、リポジトリを初期化します。次に、チームのメンバーの umask を 002 もしくは 007 に変更します。 手順さえ間違えなければ、リポジトリの共有は簡単です。 --shared を忘れた場合はどうなるのかというと、正しく共有できる状態となっていないため、Permission denied が発生します。 この状態は、次の手順で解消できます。 $ cd /your/git/repository $ git config core.sharedRepos

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Scalaで実装されたオープンソースのGitHubクローン、GitBucket 3.7をリリースしました。 https://github.com/takezoe/gitbucket/releases/tag/3.7 Markdownプロセッサの変更 Markdownプロセッサをこれまで使用していたpegdownから独自実装のmarkedjに変更しました。 markedjはJavaScriptで実装されたmarked.jsをJavaにポーティングしたもので、GitHub Flavored Markdownのより良いサポートを提供します。これによってこれまで問題となっていたGitHubとGitBucketのMarkdown記法の違いはかなり解決されています。 また、markedjはGitBucketで使うためにポーティングされたものではありますが、単なるJavaライブラリなので他のアプリケーシ

こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?