Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t
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 - 馬
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
git config --add receive.denyCurrentBranch ignoreをやるとどう危険なのか。一言で言うと「ある人が行った実装を、別の人が無意識に削除してコミットする」という事態を引き起こす。これが危険じゃなくて何なんだ。 まずローカルで実験用のリポジトリを作ってみよう。fという名前のリポジトリを作って、READMEをおく。今は中身は空っぽだ。 $ git init f Initialized empty Git repository in /Users/nishio/tmp//f/.git/ $ cd f f$ touch README f$ git add README f$ git commit -m "initial" [master (root-commit) ce6d7d5] initial 0 files changed, 0 insertions
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある 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 push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
Git is a distributed version control system invented by Linus Torvalds that stores data in a file system made up of snapshots of a project over time. It allows developers to work collaboratively by tracking changes to files and coordinating code changes between team members or branches of development. Git uses a client-server model with local repositories that can be pushed to and pulled from remo
2011/07/06追記 今はsubmoduleでなく、vundleを使ってます。 vundleでvimのプラグインを管理 - うんたらかんたら日記 git submodule 参考 git 1.6.0.2 submoduleを使おう！その1：add, status - satoko's blog - s21g git 1.6.0.2 submoduleを使おう！その2 - satoko's blog - s21g こんな感じで使うと。 $ git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec $ git submodule status -fd553b85af3da59a35cf8366319fb244fc4172b5 sub/rspec $ git submodule update --
2011-08-13追記 最近のvim pluginの管理にはvundleがおすすめ。 http://vim-users.jp/2011/04/hack215/ .vimrcなどのdotfiles自体の管理には以下の方法が有用だと思います。 この記事でできるようになること - Windows, Linux環境間, または家, 会社間などでvim設定の共有が可能になります。 - 転職や,新しいPCを買ったときなどのvim環境設定があっという間に終わります。 (vim installは含まなければ5分程度?) この記事の主題は - pathogen.vim - githubとgit(git submodule) です。 - pathogen.vimの機能によって、.vim以下を綺麗にする - githubとgit submoduleを使って置いておくことで.vim以下をweb上で管理する の二
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
vim使いながら、!gitコマンドたたくのやだなと思ったので gitプラグインを探してら、すごくいいのに出会いました。 motemen's git-vim at master - GitHub #README.rdoc == Commands [:GitAdd ] git-add or current file if not specified. [:GitCommit ] git-commit. [:GitStatus] Show git-status of current file or repository. [:GitLog] Show git-log of current file or repository. [:GitCheckout ] git-checkout. Completes git commits. [:GitDiff ] git-diff. Completes
ども。自分のサイトを復旧させるのが面倒なため会社のブログに本のレビューまで乗せようという魂胆の村瀬です。 週末に「入門GIT」を読んだのですがこの本は git ユーザーはもちろんのことその他すべての開発者が必読の本だなぁと感じたので紹介しておきます。 この本です。 この本は現在の git の開発者でありメンテナーである濱野氏によって書かれた git の入門本です。 ただの入門本にあらず しかし入門本だから最初はよくあるようなチュートリアルのような記事からはじまるのだろうと思っていると最初から面食らいます。 最初に書かれているのは git がどのようにデータを記録し、どのように履歴をたどれるようになっているかというまさに git 自体の基本が書かれているのです。 僕個人は二年近く git を使用してきているため自分の知識の確認のような感じで読み進められましたが、初めての方はすこしむずかしいか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
