GitLabの「1年放置された無料アカウントのプロジェクトを削除する計画」がすっぱ抜かれて炎上し即中止へ
2022年8月4日に、「GitリポジトリホスティングサービスのGitLabが、無料メンバーシップのユーザーが所有する1年間アクティブでないプロジェクトを自動的に削除することを計画している」と報じられ、インターネット上で反対する声が相次ぎました。これを受けて、GitLabは翌5日に長期的にアクティブではないプロジェクトを保存する方針を発表しました。 GitLab plans to delete dormant projects from free accounts • The Register https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/ GitLab U-turns on deleting dormant projects after backlash • The Register https://
Git を永続データ構造として見る - koyumeishiのブログ
競技プログラミングは役に立つ、 というかアルゴリズムとデータ構造は身の回りで役に立ってるよ案件なんですが、 バージョン管理システム Git のコア部分の仕組みは永続データ構造です。 ブラックボックスとして使うより簡単な仕組みを知ってる方が 親しみやすいと思うので雑に解説します。 "git データ構造" とかでググると同様の話結構出てくる N 番煎じです (というか公式ドキュメントに書いてあるまんまのことを競プロer的に見るとこうなっているよという話。 Git の使い方を解説する記事ではありませんし、まして GitHub は何の関係ありません)。 ソースコードや公式ドキュメントを読み込んだわけじゃないのでテキトーなことが書かれているかもしれません。 公式ドキュメントを読んでください。 ざっくり "commit" は登録したファイルを含むディレクトリツリーのスナップショットを保存している "c
僕が考える最強のコミットメッセージの書き方 - Qiita
この記事は DeNA 21 新卒 Advent Calendar 2020 の16日目の記事です。 はじめに Gitを使っていく上でコミットメッセージは必須なものです。 そのメッセージ、fix とか適当になっていませんか？ コミットメッセージがおざなりなままだと、どんな変更をしたのかが掴みにくく、レビュー時や後で見たときにコードを追うのが難しくなります。 逆に、コミットメッセージをこだわるだけでより良い開発環境、開発者体験を実現できます。今回は僕が良いと考えている書き方をまとめてみようと思います。 この記事のターゲット Gitを使ったことがある方 チームで決められたコミットルールを理解、改善したい方 よりよい開発者体験を実現したい方 ※諸注意 まず、コミットメッセージの書き方に正解はありません。タイトルにもあるとおり、あくまで「僕が良いと考えている」書き方なので、一意見として参考にしていた
お前らのコミットは汚い - Qiita
お前らのXXXXは<ネガティブな形容詞>シリーズ で失礼します。 日頃gitをお使いの皆様におかれましては、キレイなコミットを心がけていらっしゃいますでしょうか。 私も心がけてはいますが、なかなか難しいものがあります。 参考までにこちら、最近業務で書いたプルリクエストのコミットログです。 控えめに言って汚いと思われたかと思います。 ではキレイなコミットの例を。 プルリクエストというのは、やはり先達の方に見ていただいてご指摘いただこうというものですから、 当然コミットハッシュもゾロ目等でキレイにするというのがマナーです。 では今回はこのキレイなコミットをどうやって作るのか、という話を書きます (ショート)コミットハッシュ コミットハッシュとは、gitのコミットごとに生成される、40桁の[0-9a-f]からなる文字列です。 お手元のリポジトリ上で git log --format=%H を叩く
【Git】削除したブランチは復活できる！Git初心者から中級者になりたい方へ | ジーニアスブログ – WEB制作会社ジーニアスウェブのお役立ちブログ
2018.11.07 Wed 【Git】削除したブランチは復活できる！Git初心者から中級者になりたい方へ BY.yamada #Webプログラミング やってしまった…。そういう経験、皆さんにもありますよね。 つい最近私にもとても困ったことがありました。実装中のブランチを誤って削除してしまい、実装内容がパーになってしまったのです。もう頭が真っ白になりますよね。 でも大丈夫です。消してしまったブランチは変更履歴から抽出して復活させることが可能なのです。 当記事の対象者としましては以下のとおりです。 なくなった過去(削除してしまったブランチ)を取り戻したい方へ ある程度のGitコマンドを理解できている方へ Git初心者から中級者になりたい方へ どうぞ最後までよろしくお願いいたします。 ブランチの削除する方法 要らなくなったブランチを削除したいとします。その際は以下のコマンドでブランチの削除を行
git stash popでコンクリフトした時の解決方法 - chulip.org
入門Git 作者:濱野 純(Junio C Hamano)秀和システムAmazongit stashは作業中の内容を一旦退避することができるため大変便利で結構使ってますが remoteや他branchからrebase等で変更を適応する時にstashしてから適応。 変更箇所がかぶったりするとgit stash popした時にCONFLICTが発生します。 その時の解決方法のメモ。 1. 手動マージ Gitは自動的に解決できない衝突が発生するとファイルに衝突箇所をマーキングしてくれます ++<<<<<<< Updated upstream // 現在のコミット ++======= // コンクリフトした内容 ++>>>>>>> Stashed changes手動で採用したい記述を残してgit addしてCONFLICTを解決します。 これが一般的でいつもこの作業をしていました。 2. git
Git で コミットを無かったことにする方法 （git revert の使い方） - akiyoko blog
Git でコミット（とかマージ）を無かったことにする方法といえば、「git revert」なのですが、使い方にちょっとひとクセ（？）あったのでメモっておきます。 「git revert」は正確には、commit を無かったことにするのではなく、対象の commit の変更を相殺するような差分commitを自動で生成するというものです。 コミットを文字通り無かったことにする（コミットログから特定のコミットだけ抜き出す＝履歴が残らないようにする）には、「git reset --hard」「git rebase」「git cherry-pick」「git push -f」などを駆使すればできるのですが、いくつかコミットやマージが重ねられた後にそれをするのは、あまり現実的とは言えませんよね。 そこで、「git revert」の登場です。 実践 例えば、以下のような commit があったとします。
コミットメッセージの書き方 - MAYAH
ここ5年ほど pre commit review があるような環境(主に chromium とか)で働いてきたので、コミットメッセージの書き方を自分なりにまとめておきます。 コミットメッセージで伝えたいことはパッチのコンテキストである コミットメッセージはコードレビュー依頼であるという態度で記述します(受け売り)。そのため、コードレビュー者がパッチのコンテキストを理解できるように記述するべきです。なにをやっているのか分からないパッチを渡されるより、これはこういう理由でこういう変更をやっているパッチだということを伝えてからパッチを見たほうが、パッチの理解も速いでしょう。レビュー者にパッチのコンテキストを理解してもらえれば、コードレビュー速度が上がったり、コードのミスが見つけてもらいやすくなるという利点があります。 コミットメッセージの基本的なフォーマット コミットメッセージには一般的に使われ
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
[Git] .gitignoreの仕様詳解 - Qiita
対応バージョン この記事の内容は、少なくともGitのバージョン2.19.1までは対応している。 もし最新のGitで新しい動きがあれば随時更新する。 基本 .gitignoreを使うと無視する（Gitのトラッキングの対象外とする）ファイル or ディレクトリを指定できる。 .gitignoreは複数のディレクトリに置くことができる。 深い階層の.gitignoreに書かれた指定の方が優先順位が高い。（後に解釈される） .gitignore内の記述は上の行から順に以下のように解釈される。 /を含まない行（fileなど） .gitignore以下の全サブディレクトリ下にあるこの名前のファイル or ディレクトリを無視する 末尾以外にのみ/を含む行（/file, /path/to/file, path/to/fileなど） .gitignoreが置いてあるディレクトリをカレントディレクトリとする相
![[Git] .gitignoreの仕様詳解 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2a04ab07b13d19d2c325ad2107adf968e241eda0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMTA2NzYwJTJGcHJvZmlsZS1pbWFnZXMlMkYxNDczNzEwMDM1P2l4bGliPXJiLTQuMC4wJmFyPTElM0ExJmZpdD1jcm9wJm1hc2s9ZWxsaXBzZSZmbT1wbmczMiZzPTI3NjczNjgwMTYxNjQ0M2FjMTg0NmQyYTMwY2Q0ZGM5%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Da20672cbe4ba9aa0bb37457861a3f85f%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCR2l0JTVEJTIwLmdpdGlnbm9yZSVFMyU4MSVBRSVFNCVCQiU5NSVFNiVBNyU5OCVFOCVBOSVCMyVFOCVBNyVBMyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPTkyYmE1YmEwOWQ2N2RkZjE5ZDY3ZmFhNzViOWE4NjU5%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBhbnFvb3FpZSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWRhNGM0OWVkMWE1MzMzMWU2YTYwYjMyZmQ3N2E1NjZh%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Dd0ab91f14b79c60c2ded46a11f180c3c)
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【git】マージしたけどやっぱりやめたい時のやり方4種類 - Qiita
Git で変更を patch ファイルにする / patch コマンドで適用する - Qiita
https://www.crz33.com/software/gitlab/gitlab_merge_request
忘れやすい人のための git diff チートシート - Qiita
fetch と pullの違い - Qiita
かず(独学エンジニア/SAGOJO COO)さんのツイート: "エンジニアなら1日1回ぐらい悩む事だと思うんですが、 クラスや変数名迷った時に候補打ち込むとその名前がgithub上のプロジェクトでどれぐらい使われてるかを表示するCLIがクソ便利 特に実務経験ない人、最初毎回これ使ってプログラム内で使われがちな表現になれるとよいかと https://t.co/xlgYHQimHj… https://t.co/I3kqWwqGYl"
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25
Force a "git stash pop" (Example)