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

「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう?って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
MIXI(旧社名ミクシィ)は5月8日、同社の新入社員向け技術研修で使用した資料を無償公開した。分散型バージョン管理システム「Git」とテスト・設計研修の資料をスライド共有サービス「Speaker Deck」で公開中。動画も後ほど公開するという。 Gitの研修資料は約470ページあり、Gitを使ったチーム開発の進め方やGitの内部構造などを記載している。テスト・設計研修の資料は約40ページ構成で、テスト技法やコードレビューのコツなどを紹介。いずれの資料も同社の社員が作成した。 同社は2021年から新入社員向け研修の資料を一般公開しており、22年はUnityでのゲーム開発やAI、セキュリティ研修など全12種類の資料を自社ブログに掲載していた。同社の公式Twitter(@mixi_engineers)は「今後も随時資料や動画を公開していく」としている。 関連記事 ミクシィ、技術カンファレンスを初
GitHub Copilotがローカルでも動けば楽しいので、Gigazineでtabbyというのが紹介されてたので試したけど動きませんでした・・・ というか、最近はGigazineの後追い追試みたいになりがち・・・ ローカルPCでセルフホストできてGithub Copilotのように使えるコーディング補助AI「tabby」、Dockerイメージありなので早速使ってみたレビュー - GIGAZINE 毎回ちゃんと自分の環境にインストールして動かしてるのすごいなーと思います。 tabbyのリポジトリはこちら。ここにDockerのコマンドがあるので、パスを適当に修正すればOKです。 https://github.com/TabbyML/tabby Gigazineでは触れられてないけどイメージが32GBくらいあるので注意。 起動したけど、ぜんぜん補完してくれない。 SwaggerからAPIを叩い
[速報]「GitHub Copilot X」発表、GPT-4ベースで大幅強化。AIにバグの調査依頼と修正案を指示、ドキュメントを学習し回答も GitHubは、GTP-4をベースに「GitHub Copilot」の機能を大幅に強化した「GitHub Copilot X」を発表しました。 GitHub Copilot is already helping developers code faster in their IDEs. But what’s next? Our answer is GitHub Copilot X. It’s our vision for the future of AI-powered software development. Check it out https://t.co/3Xrn7dAPgi — GitHub (@github) March 22, 202
こちらはエンジニアなりたての私が学んだ、Gitの基礎知識になります。 トピックは職場の先輩に大事な部分を抽出いただいてまとめました。 私と同様、初学者さんたちのお力になれれば嬉しいです ローカルリポジトリについて Gitのローカルリポジトリには3段階がある 1. ワークツリー 自分の作業場所。ここでファイルの作成や編集を行う。 ワークツリーで編集後、addしていない状態でgit statusを行うと以下のように言われる。 Changes not staged for commit→ステージに上がっていない変更があるよ use "git add ..." to update what will be committed→addするにはgit add <file>してね use "git restore ..." to discard changes in working directory→
AWS App Runner開発者ガイドのチュートリアルをやってみました。 GithubのソースコードリポジトリかECRコンテナイメージから選択できるようですので、Githubのソースコードで試しました。 App Runner開発者ガイドのrequirements.txtとserver.pyのみ作成しました。 yamamanx/apprunnersample App Runnerサービスの作成 マネジメントコンソールで[App Ruunerサービスの作成]ボタンを押下しました。 ソースコードリポジトリを選択して、Githubアカウントを新規追加しました。 Githubログイン画面が別ウインドウで開いて、AWS Connector for Githubからの接続を許可しました。 apprunnersampleを選択して、デプロイトリガーは自動で設定しました。 構築コマンドと開始コマンドを指定
パッケージマネージャ「Homebrew 4.0」正式リリース、より高速に。Git cloneからJSONによるパッケージ管理へ切り替え MacやLinuxに対応するパッケージマネージャ「Homebrew」の最新版となる「Homebrew 4.0」正式版がリリースされました。 下記は開発者であるMike McQuaid氏のツイートです。バージョン3.6以来最大の変更が行われ、Tapと呼ばれるサードパーティアプリをインストールするためのスクリプト管理がJSONベースになり、大幅に高速化されたと紹介しています。 Today I'm proud to announce the release of Homebrew 4.0.0. The most significant change since 3.6.0 enables significantly faster Homebrew-maintai
gitで最低限のデプロイ環境を作る際のメモ。 いろいろなCIツールを使うまでもない、小規模なコンパイルいらずのWebアプリのデプロイ環境を作る。 CIツールを使う場合でも基礎となる知識なので整理しておく。 やりたいこと ローカルで開発。 リモートにpush pushを拾って、公開ディレクトリにpull イメージ 図で書くとこんな感じ。 今回は、独自のリモートリポジトリを使うが、ここがGitHubとかでもいい。 前提条件 ローカル、リモートにgitがインストールされていること(Mac想定) リモート(サーバ)にはsshで透過ログインできること 手順 まずは、push,pullの流れを手動でやってみる。 リモートリポジトリの用意(リモート) とりあえず、外からは非公開かつ、チームがアクセスできるディレクトリを用意し、リモートリポジトリにする。
バックエンドエンジニアのKazです。 昨今では、エンジニアにとってほぼ必須ツールとなった、ソースコードのバージョン管理ツール「Git」。今回はGitについて、ちょっと上級ですが、使いこなせばとても便利なコマンドを集めてみました。 なお、記事中のコマンドはすべて最新版のGitを想定しています。一部古いバージョンでは動作しないものも含まれていますので、バージョンの差異で非対応の場合はご容赦ください。 用例 任意指定オプションについて コマンド例の角カッコ ([])で囲まれたオプションは任意指定となります。 git log [-p] ↑この角カッコ内は任意指定 プレースホルダについて コマンド例の山カッコ(<>)で囲まれた値はプレースホルダとなります。下記に沿って適宜置き換えてください。 <branch>: ブランチ名 <path>: ファイルのパス <pattern>: 検索したい文字列やパタ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました(ヒャッハー)。 README: ”GIT - 馬
githubが公式にgitコマンドのチートシートというのを出していたので、それを日本語に翻訳しました。 gitとはオープンソースの分散バージョン管理システムで、ラップトップやデスクトップ上での活動を促進します。 このチートシートは簡単なGitのコマンドラインを参照できるようになっています。 GITをインストールする GitHubは、最も一般的なリポジトリアクション用のグラフィカルユーザーインターフェイスを含むデスクトップクライアントと、高度なシナリオ用のGitコマンドラインエディションが用意されています。 GitHub for Windows Mac用GitHub Linux用GitディストリビューションPOSIXシステムは公式のGit SCM webサイトで利用可能です Git for All Platforms http://git-scm.com gitの初期設定 ローカルリポジトリ
元々IDEとか開発ツールは専門分野(?)なので、この手のものは以前からいろいろ試しているのですが、個人の感想をまとめておきたいと思います。IDEやエディタに統合されていて利用シーンが限定されるものや、GitHub for Windowsなどのように機能に制限の多いものは省いています。 SourceTree 信頼と実績のAtlassian製 無料で使用可能(要ユーザ登録) 日本語対応しており、書籍などの情報もある リポジトリごとにウィンドウが開く(Windows版はタブで開くのに…) 対話型リベースが可能 動作がかなり重い、特にブランチが増えると実用に耐えないレベルで重くなる ただし突然死などはしない Tower2 有料(買い切り$79) 履歴一覧でブランチの関連を把握するのが難しい気がする 1ウィンドウで複数リポジトリを切り替えて使用 動作はかなり軽い 時々突然死することがある ブランチを
こんにちは、今年は2017年ですね。tanakaです。 このたび、2009年からコミット履歴のあるプロジェクトのSVNリポジトリをようやくGitに移行しました。 その手順やハマリどころについてまとめておきたいと思います。 移行前と移行後の制作フローとか このSVNリポジトリは、開発用ブランチ trunk とリリース用ブランチ branches/RB の2本が常設してあり、 trunk でリリース可能になったコミットだけをCherry pick で branches/RB にマージする運用をしており、 マージしないコミットが増えると衝突が発生したり、時間経過で差が増えていき辛い感じになってました。 そこでGit(GitLab)に移行することにしました。 移行にあたり、ブランチ戦略としてGitHub Flow を導入しました。 master への直接のプッシュは禁止し、すべてマージリクエストで
先日開催された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クレデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く