特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
git gc の仕組みを原理から理解してサイズを 136MB → 7.2MB(95%減)まで削減した時の勉強メモ
個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-
「Visual Studio Codeの教科書」を読んでVS Codeの設定をゼロから見直してみた - karaage. [からあげ]
追記：VS Codeの入門書をZennでリリースしました ブログで扱ったVS Code関連の記事をまとめて、無料の電子書籍としてZennというプラットフォームでリリースしました。よければ、こちらも参考にしてみてください。 Visual Studio Codeの教科書 Visual Studio Codeの教科書を購入しました。基本的な使い方から拡張機能の作り方まで、広く押さえられていました。 プログラマーのためのVisual Studio Codeの教科書 (Compass Booksシリーズ) 作者:川崎 庸市,平岡 一成,阿佐 志保発売日: 2020/04/30メディア: Kindle版 自分は拡張機能作りには興味なかったのですが、思わず手を伸ばしたくなりますね。拡張機能作りまで興味ある方にとってはかなり良い本ではないかと思います。 本を読むと、色々改めて発見があったのと、拡張機能一回
![「Visual Studio Codeの教科書」を読んでVS Codeの設定をゼロから見直してみた - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b8cf77980ab900ed339768901e94cfe2584441d7/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fkaraage%2F20200707%2F20200707003818.png)
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
GitHubを使うなら最低限知っておきたい、プルリクエストの送り方とレビュー、マージの基本
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回の記事「これでもう怖くない、Git／GitHubにおけるリモートリポジトリの作成、確認、変更、更新時の基本5コマンド」では「リモートリポジトリ」に対する基本操作を解説しました。 連載第10回目の本稿では「プルリクエスト」の基本機能や手順について解説します。 本稿で解説する作業は、前回の記事で作成したリポジトリをベースに進めていきます。リポジトリを作成する作業をまだ行っていない場合は、前回の記事を読みながら準備を進めてみてください。 プルリクエスト
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
君には1時間でGitについて知ってもらう(with VSCode) - Qiita
おことわり この記事はプログラミング＆業務未経験の新入社員に、Gitについて1時間程度で説明した内容をもとに作ったものです。自分がもし誰かにGitについて教えて貰える立場にいたら、最初にこれを教えて貰いたかったという気持ちで作りました。 とりあえず「1人のプロジェクト」で「1時間で」Gitをそこそこ知って使えるようになることを目的としています。実際のチーム開発ができる水準までこの記事だけで達することはできませんが、今後Gitを使う必要がある人にとって学習の足がかりになれば幸いです。 それと、新入社員に教えるという都合上、表現がやや正確でなくざっくりしたところがあるかもしれませんが、質の悪い誤解を招くようなものでなければご容赦下さい。 全体像 まずはGitとは何かをざっくり分かって貰った後で、VSCode上での操作を行って頂きます。 Windowsでの説明を行いますが、Macの方は適宜読み替
[ver 1.2] Git でよく使われるコマンドにイラストによる説明を加えて1枚のチートシートにまとめてみた - Qiita
本題のチートシートはこちら PNG SVG https://d.kuku.lu/6b5cc7b0a9 から DL できます 作った理由 git って他人に概念を説明するのって難しいし、自身も何度も反復させないと定着しなかったなあという感覚を持っていたので作ってみました 所感 こちらの Git チートシートですが、この中に盛り込めなかった内容で 第2段 を作成しようか考え中です 皆さまのオススメの便利コマンドとか、この内容は必須だろ！的なものがあればをご教示いただければ幸いです もし誤りがあれば、作者の心が折れない程度にご指摘いただければ幸いです あとがき ここまで反響を頂けるとは思っておらず、嬉しい限りです・・・本当にありがとうございます・・・！！ また、図は全て自作です。図における言語は英語、説明は日本語、と言う形に統一しました。（吹き出し部分だけ日本語になっていたのでこちらは修正しまし
![[ver 1.2] Git でよく使われるコマンドにイラストによる説明を加えて1枚のチートシートにまとめてみた - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/535e1dafd3e9e039ec14846c02e07dcad8a40851/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCdmVyJTIwMS4yJTVEJTIwR2l0JTIwJUUzJTgxJUE3JUUzJTgyJTg4JUUzJTgxJThGJUU0JUJEJUJGJUUzJTgyJThGJUUzJTgyJThDJUUzJTgyJThCJUUzJTgyJUIzJUUzJTgzJTlFJUUzJTgzJUIzJUUzJTgzJTg5JUUzJTgxJUFCJUUzJTgyJUE0JUUzJTgzJUE5JUUzJTgyJUI5JUUzJTgzJTg4JUUzJTgxJUFCJUUzJTgyJTg4JUUzJTgyJThCJUU4JUFBJUFDJUU2JTk4JThFJUUzJTgyJTkyJUU1JThBJUEwJUUzJTgxJTg4JUUzJTgxJUE2MSVFNiU5RSU5QSVFMyU4MSVBRSVFMyU4MyU4MSVFMyU4MyVCQyVFMyU4MyU4OCVFMyU4MiVCNyVFMyU4MyVCQyVFMyU4MyU4OCVFMyU4MSVBQiVFMyU4MSVCRSVFMyU4MSVBOCVFMyU4MiU4MSVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MSU5RiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YjRlMGFkY2RmZmMzNDQ3YzRlMTgwZjVmZjNiNzhiNmU%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrb3p6eSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZGIzMGI1YjNjY2U0YzM3ZTQ3YzNkY2M3ZDA4ODdlMTU%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd07a8428cf4444e0572dc2ef9a64a8c8)
【GitHub】Pull Requestの手順 - Qiita
Git勉強会（社内勉強会）でできなかった、Pull Requestについての説明です。 Pull Request の手順 単純にソースコードを取得したいならgit clone http://{対象のGitHubリポジトリ}で大丈夫です。もしコードの内容を修正したい場合はリポジトリをForkする必要があります。 対象のGitHubリポジトリをFork ローカルへclone（クローン） ローカルリポジトリで新規ブランチを作成 修正を加える（コミット） 作成したブランチをpush（プッシュ）する Pull RequestをGitHub上で作成 1. 対象のGitHubリポジトリをFork 対象のGitHubリポジトリをブラウザ上でアクセスします。 んで、そこにあるForkってボタンをクリック。 自分のアカウントに対象のリポジトリがForkされます。 Forkって何？ 基本的にはgit clone
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
gitでシンプルなデプロイ環境を作る - Qiita
gitで最低限のデプロイ環境を作る際のメモ。 いろいろなCIツールを使うまでもない、小規模なコンパイルいらずのWebアプリのデプロイ環境を作る。 CIツールを使う場合でも基礎となる知識なので整理しておく。 やりたいこと ローカルで開発。 リモートにpush pushを拾って、公開ディレクトリにpull イメージ 図で書くとこんな感じ。 今回は、独自のリモートリポジトリを使うが、ここがGitHubとかでもいい。 前提条件 ローカル、リモートにgitがインストールされていること（Mac想定） リモート（サーバ）にはsshで透過ログインできること 手順 まずは、push,pullの流れを手動でやってみる。 リモートリポジトリの用意（リモート） とりあえず、外からは非公開かつ、チームがアクセスできるディレクトリを用意し、リモートリポジトリにする。
GitHubとBitbucketへの公開鍵の登録方法+SSHで複数鍵の使い分け - TASK NOTES
GitHubとBitbucketに公開鍵を登録してSSHを使えるようにする方法です。HTTPSのように毎回パスワードを入力する手間もなくなります。 秘密鍵と公開鍵を作成する まずはGitHubとBitbucket用の鍵を作ります。 $ ssh-keygen -f ~/.ssh/id_rsa_github ... $ ssh-keygen -f ~/.ssh/id_rsa_bitbucket ... 作成されました。 $ ls .ssh/ id_rsa_bitbucket id_rsa_bitbucket.pub id_rsa_github id_rsa_github.pub 鍵の作成について詳細は Macで秘密鍵と公開鍵を作成する (ssh-keygenの使い方) - TASK NOTES 参照 SSHの設定をする 複数の鍵を使い分けるために~/.ssh/configを作成します。とりあ
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
Gitの使い方をアニメーション付きで学べるサイト「Learn Git Branching」 | ライフハッカー・ジャパン
「Learn Git Branching」はGitの使い方をアニメーション付きで学べるサイトです。Gitを使い始めて間もない方には重宝するサイトだと思われます。Gitでいまどういったフローになっているかを視覚的に分かりやすく解説してくれます。ブラウザがあればいつでも学習できる点も助かりますね。 以下に使ってみた様子を載せておきます。まずLearn Git Branchingへアクセスしましょう。いくつかの学習項目が用意されていますので気になったものを選んで学習できますよ。 自分でコマンドを打って動作確認できます。間違えても大きな失敗にはなりませんので、安心して気軽に取り組めますね。Gitを学習し始めた方はもちろんのこと、そろそろ復習しておきたいなという方もおすすめできるサイトです。ぜひご活用ください。 Learn Git Branching （カメきち）
いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識
developブランチ 開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹介するfeatureブランチなど、他のブランチで行った作業は、ここにマージされる featureブランチ 主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにfeatureブランチを作成し、作業を行う releaseブランチ リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチを作成し、微調整を行う。releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発のコードを分けることができる masterブランチ リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、releaseブランチはmasterブランチへマージされて、リリースタグが打たれる。開発者は、このブランチへのコミットは行わない hotfix
Git コミットメッセージのプラクティスまとめ - 酒と泪とRubyとRailsと
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました！ 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました！ Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitExplorer
ギットクエスト
あとからまとめて.gitignoreする方法 - Qiita
