サクッとレビューができる 小さなPull Requestを作るには - LIVESENSE ENGINEER BLOG
大きなPull Requestのレビューがつらい 修正ファイル数が多いこと自体が問題なのではない 1つの内容に集中する 小さなPull Requestの作り方 リファクタリングの修正は気になっても別で出す Web API 1つに着目して実装を切り分ける 小さなPull Requestで作ったときのリリースの仕方 featureブランチを作って、そこから更にブランチを作っていく フィーチャートグルを使う 小さいPull Requestで小さくフィードバックをもらおう 大きなPull Requestのレビューがつらい 転職ドラフトでWebアプリケーションエンジニアをしている @iwtn です。 この記事ではチーム開発では当たり前になったレビューにおいて、修正されたファイルがたくさんあるとつらいよね、というお話と、その解決策を提示してみたいと思います。 昨今のWebアプリケーションなどのチーム開
図解！ Gitのブランチ・ツリーをちゃんと読む - Qiita
はじめに この記事は、ちょっとだけGitは使ったことがあるけれども、SourcetreeやGitHubやBacklogなどで出てくるGitのツリー（樹形図）の読み方がよく分からないという人に向けた記事です。なんとな～くで読んでしまっていて、実はよく分かっていないという人も、意外といるのではないでしょうか。 もしあなたが、まだGitを触ったことがなかったり、「変更のステージング」「ブランチにチェックアウトする」と言ってなんの事か分からなかったりしたら、先にこの記事 君には1時間でGitについて知ってもらう(with VSCode) を読んでくることをオススメします。（宣伝） 対象読者の想定レベル Gitを触ったことがあり、コミットをしたことがあるが、本格的なチームでのGitを使った開発は未経験 mainブランチ（masterブランチ）というものがあるらしいということは知っている Source
.gitignoreでフォルダの構造のみを保持したい場合のより良い書き方 - Qiita
例えばWebサイトのバックエンドでアップロードされたファイルを/storage/フォルダ内に入れているとする。その場合、Gitではアップロードされた/storage/内の各ファイルは無視したいが、/storage/フォルダ自体は残しておきたいということがよくある。しかしGitで管理できるのはファイルだけなので、ファイルが一つも入っていないフォルダをGitで表現することはできない。そのために.gitkeepというダミーの空ファイルを作成してGitで管理することでフォルダを保持するということが頻繁に行われている。 ここではそのような場面でこれまでよく解説されている.gitignoreの書き方とは異なる、より柔軟で単純な書き方を発見したので解説する。 結論 保持したいフォルダ構造を作成。ここでは/storage/フォルダ以下のフォルダ構造をgitで保持したいとする。 各末端のフォルダに空のファイ
Oh Shit, Git!?!
Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って？ git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ！ # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index
Gitのコミットメッセージをうまく作成する7つのルール | NHN Cloud Meetup
この記事は、Chris BeamsのHow to Write a Git Commit Messageブログの内容を簡単にまとめた資料で、翻訳・編集して、役に立つ内容を追加したものです。 Gitのコミットメッセージをうまく作成すべき理由 なぜコミットメッセージをうまく書く必要があるのか？理由は色々ありますが、うまく書かれたコミットメッセージが有益であるという事実は、多くのプログラマが同意することでしょう。そのうち代表的な3つの例を挙げてみます。 コミットログの読みやすさ より良いコラボレーションとレビュープロセス コード保守の容易さ 「良いコミットメッセージについて考えることは素晴らしいアイデアだと思う。しかし、良いメッセージの正解があるかは分からない。個人によって良いコミットメッセージと捉える基準が異なるためだ。多くの人々が共感できる良いコミットメッセージをうまく作るためのルールはないだ
あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の
GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
Token authentication requirements for Git operations
SecurityToken authentication requirements for Git operationsIn July 2020, we announced our intent to require the use of token-based authentication (for example, a personal access, OAuth, or GitHub App installation token) for all authenticated Git operations.… In July 2020, we announced our intent to require the use of token-based authentication (for example, a personal access, OAuth, or GitHub App
GitLabもデフォルトのブランチ名を「master」から「main」に変更へ、5月から
GitLabは、5月22日にリリースするGitLab 14.0以降、新規に作成されるリポジトリのデフォルトブランチ名を「master」から「main」に変更することを明らかにしました。 You spoke and we listened. We're joining the Git community and updating "master" to "main".https://t.co/V8UdjxQUBT — GitLab (@gitlab) March 10, 2021 具体的には、4月22日リリース予定のGitLab 13.11でフィーチャーフラグによってデフォルトブランチ名を「main」に変更可能にします。この時点ではまだデフォルトブランチ名は「master」のまま、フラグを切り替えたときのみデフォルトブランチ名が「main」となります。 そして5月22日にリリース予定のGit
git init をすると大量の hint が出て うわ ってなった話
概要 最近 git init をするとオレンジの文字で大量に hint が表示されるようになった。 なんとなく嫌な気持ちになったので対処法を記載します。 環境 Mac Catalina git version 2.31.0 こんな具合に % git init hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.
Gitをまったく使ったことがなくても大丈夫、基本操作と用語を解説『動かして学ぶ！Git入門』
プログラムの変更履歴などバージョン管理を行えるサービスのGit。今やエンジニアには不可欠となったGitの使い方を解説した『動かして学ぶ！Git入門』（翔泳社）が発売中です。本書はGitを使ったことがない、これから試してみようと考えている方向けの入門書。今回は本書から「Chapter1 Gitの基本」を紹介します。 本記事は『動かして学ぶ！Git入門』の「Chapter1 Gitの基本」を抜粋したものです。掲載にあたって一部を編集しています。 バージョン管理システムとは ソフトウェアを開発していると、プログラムにバグを入れてしまって以前のファイルの状態に戻したくなったり、そうでなくても以前のファイル内容を見たくなったりすることがあります。そんなときに便利なのがバージョン管理システムです。 バージョン管理システムとは、ファイルの履歴を管理するシステムです。プログラマは、ファイルのこの状態をとっ
Git
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git リモートブランチをチェックアウトする - Qiita
作業用ブランチで作業していたつもりがmasterブランチで作業してしまった時の対処法 - Qiita
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】