いちばんやさしいGit入門20190425 JJUG ナイトセミナー
Gitの中身
はじめに Gitで管理するプロジェクトには.gitというディレクトリがあり、その中にGitの管理情報が入っている。その中には、全てのコミットや、いろんなバージョンのファイル、ブランチ、タグといった情報が格納されている。Gitを操作するにあたり、この中身がどうなっているかを理解する必要はないし、もし中身を覚えたとしても、操作方法は変わらないまま、内部実装だけ変更になる可能性もある。それでも、Gitの仕組み、特に様々な情報が.gitにどのように格納されているかを知っておくのは二つの理由から有用だと考える。 一つ目の理由は、「物が動く仕組み」を知っておくことが教養だからだ。車を運転するのに、アクセルを踏めば進み、ブレーキを踏めば止まり、ハンドルを回せば曲がることを知っていれば十分だ。しかし、シリンダーにガソリンが噴射され、ピストンで圧縮したところで点火し、爆発する力でピストンが押される、という直
Gitブランチフロー規約 | Future Enterprise Arch Guidelines
本コーディング規約は、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに 本規約はGitブランチ管理の標準的な運用ルールをまとめている。以下の想定で作成されているため留意すること。 GitHub ／ GitLab の利用トランクベース開発（フィーチャーフラグ）を 採用しないライブラリではなく、アプリケーション（CLIツール、Webアプリケーションなどの）開発で利用する免責事項 有志で作成したドキュメントである フューチャーアーキテクトには多くの部署や多様なプロジェクトが存在し、それぞれの状況に合わせて創意工夫された設計ポリシーが存在する。本規約はフ
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
git-sim: Visually simulate Git operations in your own repos
Table of Contents Introduction When --dry-runs aren't enough What is Git-Sim? Git-Sim Goals What Does Git Sim Do? Full list of Git-Sim supported commands Git-Sim features How to Install and Run Git-Sim How Does Git-Sim Work? Contributing to Git-Sim Summary Next Steps Introduction Despite its simple design under the hood, Git is a notoriously confusing tool for new devs to learn to use and understa
VSCode-GitLensはいいぞ、という話 – Wyton
※このエントリはOSS紹介 Advent Calendarの17日目のエントリとなります。 Visual Studio Code使ってますか？ 皆さん、Visual Studio Code（以下VSCode）使ってますか？ VSCodeはMicrosoftが開発しているOSSのエディタです。github上で活発にコミットされているプロダクトであり、その使い勝手は比較的Atomに似ていると言えるかもしれません。 今回は、そんなVSCodeのプラグインとして提供されているGit LensというOSSを紹介したいと思います。 Git Lensって何？ 簡単に表現すると、git blameをVSCodeで超絶便利に使えるようにするプラグイン、という感じでしょうか。いちいちgithubとかbitbucketに見に行くのもだるいですし、かといってgit blameを毎回手打ちするのもだるい、という向き
How much of a git sha is *generally* considered necessary to uniquely identify a change in a given codebase?
If you're going to build, say, a directory structure where a directory is named for a commit in a Git repository, and you want it to be short enough to make your eyes not bleed, but long enough that the chance of it colliding would be negligible, how much of the SHA substring is generally required? Let's say I want to uniquely identify this change: https://github.com/wycats/handlebars.js/commit/e6
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
Git で merge commit を revert したあと、再度 merge したい | risou's Lithograph
Git の merge は、「2つのブランチの共通の親を探し、そこから merge されるブランチのコミットを順に merge するブランチに適用」していくものだ。 では、次のようなときどうするか。 ケース 上の画像において、それぞれのコミットは以下の通りである。 S：分岐元のコミット M, G：マージコミット R：マージコミット（M）の revert コミット A, B, C, D：通常のコミット 上記グラフができるまでの流れは、 マージを行う（Mコミットが作られる） 先のマージはまだ早かったと気づき、 revert する（Rコミットが作られる） しばらく経ち、マージしても良くなったので再度マージを行う（Gコミットが作られる） という感じだ。 さて、このときGコミットには、A、B、C、Dの4つのコミットが適用されていて欲しい。 しかし実際には、CとDの2つだけしか適用されない。 なぜなら
Gitの良さが分からない？ ちょっとそこに座れ | To Be Decided
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
アホみたいにでかいgit repositoryを上手く扱う方法 - Qiita
gitが大きくなると時間かかってしゃーないと思っていたら、ちょうどatlassianのブログにこんな記事があった。 How to handle big repositories with git - Atlassian Blogs 巨大なリポジトリ を Git で上手く扱う方法 直訳ではなく、読んだことを参考に自分用にメモを記す。これは本当にメモ代わりなので原文を参照した方がいいと思う。 gitが重くなる原因は、「長い歴史」と「デカいファイル」の2つがある。その2つの対処法。 長い歴史に対処する shallow cloneを使う gitのhistoryが積み重なると、git cloneに時間がかかる。そのときはshallow cloneを使って、深さを限定してcloneする。 git clone --depth depth remote-url 手元の環境だと23sくらいかかっていたのでも
Fork - a fast and friendly git client for Mac and Windows
Fork is getting better and better day after day and we are happy to share our results with you.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitの仕組みと用語 / GitHub Term
Gitea Official Website
[Git] 一部のファイル、部分的な変更点のみgit stashする - Qiita![[Git] 一部のファイル、部分的な変更点のみgit stashする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/bd8d0ccd0b0528273b1fd830b97c4f4c9759dc16/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%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMzc3MjElMkZwcm9maWxlLWltYWdlcyUyRjE0ODY4NzE1NjY_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9NjdhYTNkNTE3NDg3M2U0MjZiYTZmMTllNTgzNzZiNTg%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253De91fe427ca59b3e21fa47030559dc790%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCR2l0JTVEJTIwJUU0JUI4JTgwJUU5JTgzJUE4JUUzJTgxJUFFJUUzJTgzJTk1JUUzJTgyJUExJUUzJTgyJUE0JUUzJTgzJUFCJUUzJTgwJTgxJUU5JTgzJUE4JUU1JTg4JTg2JUU3JTlBJTg0JUUzJTgxJUFBJUU1JUE0JTg5JUU2JTlCJUI0JUU3JTgyJUI5JUUzJTgxJUFFJUUzJTgxJUJGZ2l0JTIwc3Rhc2glRTMlODElOTklRTMlODIlOEImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtcGFkPTAmcz1mY2JmZTBmMWZjZWU3YmUzMmM4YjA1OWQ3MGI4YzZjYQ%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBrb2FyYS1sb2NhbCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWY4NDI3NDY5YjY4Y2MwOGYzZGY4MGMxZWU0ODljOGVl%26blend-x%3D242%26blend-y%3D454%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26txt64%3DaW4g44Oq44OD44Kv44K944OV44OI5qCq5byP5Lya56S-%26txt-x%3D242%26txt-y%3D539%26txt-width%3D838%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D28%26s%3De3312da4ce7f1cf1d818415748af0631)
GitでMerge CommitをRevertする方法 - Qiita
How to ZFS · GitBook (Legacy)
