gitでstashが面倒なあなたにautostashgitでrebaseしまくるzaruです、こんにちは。rebaseする時、編集途中のファイルがあるとstashしてくれと怒られますよね。本当に面倒くさいのですが、これを一発でstashしなくて済む方法を紹介します。
え？まだgit checkoutしてるの？
公式ドキュメントには以下のように書かれています。 THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 和訳：このコマンドは実験的です。動作が変更される可能性があります。 この記事の内容と違う場合があるので、ご注意ください。 この記事は2024年2月28日時点の情報です。 え？まだgit checkoutしてるの？ git checkoutといえば、ブランチを切り替えたり、git addしたファイルを元に戻したりするコマンドですが、それはもう古いです。 実は2019年8月リリースのgit 2.23からgit switchとgit restoreが追加されました。 知らなかった人も多いのではないでしょうか？(恥ずかしながら私は知らなかった...) 「先輩、checkoutってなんすか？」と後輩に聞かれる前に、この記事を読んでgit sw
Gitを置き換えるバージョン管理システム「Jujutsu」 | ソフトアンテナ
今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
SQLite vs. その他のデータベースエンジン： 比較検討 - SQLite が Git を使用しない理由
1. IntroductionSQLite は Git バージョン管理システムを使用しません。 SQLite は代わりに Fossil を使用します。これは、 SQLite をサポートするために特別に設計および作成されたバージョン管理システムです。 なぜ SQLite が他の製品のように Git バージョン管理システムを使用しないのか疑問に思う人がよくいます。この記事ではその質問に答えようとします。また、 section 3 では、この記事は Git ユーザーに SQLite ソース コードに簡単にアクセスする方法に関するヒントを提供します。 この記事は Fossil と Git の比較ではありません。2 つのシステムの比較については、 https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki を参照してください。他のサード
令和のGitクライアントはForkで決まり！全力でお勧めしてみた | 技術は熱いうちに打て！
概要 どうも、@daiki1003です！みなさん、Gitクライアントって何を使っていますか？ 多分、ほとんどの人がSourceTreeを使っていると思います。 もしかしたらGitKrakenを使ってるかもしれません。 今回の記事では、Forkについて紹介したいと思います！ 僕自身、2,3年くらいSourceTreeを使っていましたが 今ではそんな時間を取り戻したいと思うくらいにはForkを数年愛用しております。 基本的に、SourceTreeに出来てForkに出来ないことはないと思います👍 Forkの魅力とは？・UI ・処理速度 ・機能の豊富さ それぞれ解説していきましょう。 優れたUI Forkサイトより引用 まず、そもそものUIが美しいです。 全然論理的ではないですが、長時間仕事を共にするGitクライアントですので 使っていてテンションが上がるかどうか(下がらないこと)はかなり重要な
Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
初学者の私がGitを理解するために、この順番で読めばよかったと思った記事の順番 - Qiita
エンジニア未経験のわたしがGitを学ぶ上で、この流れで記事を読むべきだったと思ったことを記載する。 完全に初学者意見のため、疑いながら読んでください。 私は下記の流れで学習することによって、理解をしやすいように感じた。 ① Gitで何をしているかのイメージを掴む（コマンドなし） ② Gitのイメージを、コマンドで実現している記事をみる ③ 実際にGitのコマンドを打ちながら、出力と、頭の中のイメージのすり合わせ Gitで何をしているかのイメージを掴む（コマンドなし） こちらの記事は、Gitのイメージをコマンドなしで、わかりやすく図で示してくださっています。 記事にも記載されていますが、 ・重要なのは 「何」から「何」へ・「どんな作業」を行う のかを追う ・操作前と操作後でどんなことが起こっているのかをイメージする 上記の内容が、すごく同意で、重要だと感じている。いきなりコマンドを打ちながら
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
Gitの内部構造をよく理解して、うまく使おう【基本の仕組みを解説】
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
GASに入門して, Claspを使ったGit管理+Gitlab-CIを使ったCI / CDまでやった記録 - Qiita
GASに入門して, Claspを使ったGit管理+Gitlab-CIを使ったCI / CDまでやった記録JavaScriptGitGoogleAppsScriptGAS GASに入門して, Claspを使ったGit管理+Gitlab-CIを使ったCDまでやってみた 今冬、初めて雪が窓の外をちらついた日のことだ。 GASを使ってスプレッドシートを更新する業務の自動化を推進している同僚が、保守性・メンテナンス性が悪くて困っているという話をしていた。 「バージョン管理をしたらいいよ」というアドバイスが方々から飛んだ。私もそのアドバイスをしたうちの一人だった。そのとき、私はGASを触ったことが一度もなかった。 それから30分後、私はなぜかGASを触ることになっていた。何の偶然か、私はこのタイミングで突然ドライブの特定のディレクトリに存在する全てのスプレッドシートからあるカラムを取得する必要性に迫ら
パッケージマネージャ「Homebrew 4.0」正式リリース、より高速に。Git cloneからJSONによるパッケージ管理へ切り替え
パッケージマネージャ「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」に脆弱性、アップデートを - GitHubやGitLabも対応（1ページ目 / 全2ページ）：Security NEXT
ソフトウェアの分散型バージョン管理システム「Git」に複数の脆弱性が明らかとなり、アップデートがリリースされた。脆弱性を報告したGitLabは、重要度を「クリティカル（Critical）」と評価している。 「CVE-2023-23946」は、パストラバーサルの脆弱性。GitLabの関係者より報告が寄せられた。「git apply」において細工した命令により作業ツリー外のパスを上書きすることが可能になる。CVE番号を採番したGitHubでは、共通脆弱性評価システム「CVSSv3.1」のベーススコアを「6.2」とし、重要度を「高（High）」とレーティングしている。 さらに細工したリポジトリにより、非ローカルのトランスポートを利用している場合も、ローカルクローンの最適化を行わせることが可能となる「CVE-2023-22490」が判明した。CVSS基本値は「5.5」、重要度は「中（Moderat
【Git】SourceTreeで個人的なファイル/フォルダをバージョン管理から外す（ローカル版.gitignore） - Qiita
ローカルで自分だけの.gitignoreをつくる ※この方法で作成した.gitignoreはSourceTree上のすべてのプロジェクトに適用されるので要注意です。 1.まずローカル専用の.gitignore(gitignore_global)を生成する。 （今回はGit Bashで生成しました） User@***** MINGW64 ~ $ pwd /c/Users/User User@***** MINGW64 ~ $ touch .gitignore_global 2.生成されたことを確認した後、SourceTreeを開き上部メニューの[ツール]->[オプション]を開く。 3.グローバル無視リストに先ほどの.gitignore_globalのアドレスを入力 4.ファイル編集を開き、無視したいファイルを記述する。 これで完了です。 念のため、SourceTree上で変更から対象のファイ
[git]git submodule addでエラー「A git directory for ‘[指定モジュール]‘ is found locally with remote(s):」 | Coffee Breakにプログラミング備忘録
[git]git submodule addでエラー「A git directory for ‘[指定モジュール]‘ is found locally with remote(s):」 はじめに [git submodule add]コマンドを実行したときにエラー「A git directory for ‘[指定モジュール]‘ is found locally with remote(s):」が出たので解決案をメモします。 エラー発生から解決まで こちら環境ではvolleyというandroidの通信ライブラリを導入時にエラーがでました。 フローとしては、最初の一回目のsubmodule化ではエラーにはなりません。一度入れたsubmoduleを削除するときに、[rm -rf]で単に削除し、再度[git submodule add]を行おうとするとエラーになります。 [git submodul
既存のGoogle Apps Scriptプロジェクトのコードを Git で管理！ - ROBOT PAYMENT TECH-BLOG
最初に 前提 clasp の導入 google へのログイン 既存のプロジェクトのローカルにクローン 試しに Push してみる gitリポジトリの初期化 既存のファイルをすべてコミット その他 最初に Google Apps Scriptヘビーユーザーの皆様こんにちは！ サブスクペイのシステム基盤を担当しております youponpon です。 突然ですが、Google Apps Scirpt プロジェクトのコードが大きくなってきて Git などのコード管理を導入したくなったことはありませんか？ 今回は google/clasp を利用して既存の Google Apps Script プロジェクトのコードを Git 管理する方法を説明します。 前提 事前に以下の導入をお願いします。 Node.js の導入 https://nodejs.org/ja/download/ Git の導入 ht
Gitのコミットグラフをキレイに分かりやすく見るツールは、VSCodeが最高だ！ | DevelopersIO
今のプロジェクトでは、いわゆるGitHubフローでGit運用しています。 masterブランチから作業ブランチを作って作業する 作業ブランチからmasterブランチへのマージは、プルリクエストを使う 隔週リリースを行っており、その際はリリースしたいコミットにタグ付けをしています。 通常であればmasterが対象ですが、たまに「この機能は次のリリースにしよう」などの理由でmaster以外のコミットにタグをつけます。 リリースはmasterブランチにタグをつけて行う 都合悪いときは任意のコミットにタグをつける このとき、リリース対象のコミットを調べるためにコミットログ（グラフ）を確認しますが、とても見やすいGUIツールがあったのでご紹介します。 今まで シンプルなコミットログなら、gitk -allコマンドで見ることが多いです。 しかしながら、そこそこ複雑なコミットログの場合、gitk --a
本の原稿のバージョン管理を始めて20年たちました - golden-luckyの日記
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
GitHub Actions 逆引きリファレンス
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
既に git 管理しているファイルをあえて無視したい - Qiita
