Gitブランチをきれいにするワンライナー - テクめも
今すぐalias登録すべきワンライナー by ゆめみ① Advent Calendar 2018 10日目の記事です。 開発していると、マージされたfeature/xxxとか不要なブランチが結構でてくるので、一括で削除するコマンドをalias登録しておくと良いです。 git checkout develop && git branch --merged | grep -v '*' | xargs -I{} git branch -d {} && git fetch --prune はじめのdevelopのところはデフォルトブランチです。必要に応じて修正ください。 簡単な解説 developブランチにcheckout $ git checkout develop 現在のブランチを除くマージされたブランチを表示 $ git branch --merged | grep -v '*' 表示された
Git Identity Manager - Gitのアカウント情報を切り替え
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました Gitではユーザ名とメールアドレスなどを設定として保存しておきます。しかし、企業と個人でアカウントを切り替えている人にとっては不便です。間違って会社のアカウントで登録してしまって、慌てて削除したなんて経験がある人がいるかも知れません。 そこで使ってみたいのがGit Identity Managerです。複数のアカウント設定を簡単に切り替えられるソフトウェアです。 Git Identity Managerの使い方 アカウントの追加はaddを使います。名前、メールアドレス、SSHキーのパスはセットです。 git idm add jcool --name "Joe Cool" --email joe@example.com --key ~/.ssh/id_rsa 登録したら、listで登
Gitで日本語長文のdiffをとる方法 - Qiita
（この記事はここからの転載です） 課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク
「tig」をつかってcommitをきれいに分割する - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 2年目のエンジニアになりました、FM_Harmonyです。 Rakus Developers Blogでは4回目の投稿です。 ↓前回の記事はこちら tech-blog.rakus.co.jp さて、弊社ではビアバッシュというイベントを行っています。（ビアバッシュ・・・?という方はコチラ） 今回はその際に私が発表したことについて、補足も踏まえつつまとめたいと思います。 テーマはtigでcommitをきれいに！です。 はじめに tigとは？ 準備 tigのインストール（windowsの場合） tigのインストール（macOSの場合） commitをきれいにする理由 使ってみる 実演の前準備 機能を追加して、まとめてcommitする git rebase -i で、commitの分割を始める tigを使ってcommitを分割する - その1 tigを使ってcommitを分割する - そ
git rebase で squash しつつ edit したりコミットを分割したりする - Qiita
pick d94123a 001 pick d9b3511 002 pick b3f6c3e 003 pick 3a76981 004
gitのブランチをきれいにしたい。 - Qiita
はじめに gitに関するメモの中で触れた、git-flowについてのメモです。 これも眠ってたので記事にしてみることにします。 git-flowの概要 git-flowの概要はこのページに簡単な説明がある。 Git for windowsには初めから付属されているので特になにも考えずともgit flowコマンドが使えるようになっている。 Linuxとかだと別途インストールが必要になるようだ。具体的なインストール方法はこのページを参照。 git-flowでは以下のブランチを使用して開発を進める。 master: 常にデプロイ可能なブランチ。 develop: 開発用ブランチ。開発中の最新の状態が保管されている。 feature: 機能追加などの新規開発用ブランチ。開発する機能ごとに作る。feature/というプレフィックスを付ける。 release: リリース用ブランチ。 hotfix: 緊
[Git] コミットメッセージのフォーマット
プレフィックスを付けるようにしているが、fix:〜とかadd:〜としているものの、なかなか定まらない。（調べてみたが、きれいな書き方が定まらない…） 通常版fix：バグ修正hotfix：クリティカルなバグ修正add：新規（ファイル）機能追加update：機能修正（バグではない）change：仕様変更clean：整理（リファクタリング等）disable：無効化（コメントアウト等）remove：削除（ファイル）upgrade：バージョンアップrevert：変更取り消し絵文字コミットコメントに基づいた関連する絵文字。 fix：バグ修正🐛🪲🩹🔧hotfix：クリティカルなバグ修正🚑🔥🆘add：新規（ファイル）機能追加✨➕🆕📝update：機能修正（バグではない）🛠️✏️⚙️🔄change：仕様変更♻️🔄📈📐clean：整理（リファクタリング等）🧼🧽🧹💅disab
![[Git] コミットメッセージのフォーマット](https://cdn-ak-scissors.b.st-hatena.com/image/square/c079ea7ae5f35a23da962941df111cf7cc67d56e/height=288;version=1;width=512/https%3A%2F%2Fb.0218.jp%2Fimages%2Fogp%2F20170223002406.png%3Fts%3Dda92d8452b83631c89087c21ff6c400917e3d205)
2つのGitリポジトリをマージする - Qiita
今回も 100% 自分のためのメモです。仕事で２つのGitリポジトリをマージして新しいリポジトリを作る必要がありました。コマンドの意味のいくつかを理解していなかったので、調べてメモしておきます。 自分の理解にポイントを置く 普段はこのレベルのは書かなかったですが、結城さんの一連のポストが素晴らしく、見習ってみることにしました。特に「自分の理解にポイントを置く」というのは、私におそらくもっとも足りていないことと思っています。 （自分の勉強法でいいのか） あなたの質問の中で「5分考えて何も思いつかない」というところが気になりました。いつも「5分」でタイムアウトするのはいいことなのかなと思ったからです。また「考えて何も思いつかない」というのは、（続く）https://t.co/0CSFZX0e8g pic.twitter.com/5APJBrbawm — 結城浩 (@hyuki) 2018年2月
Windows で Git - 2017冬 - Qiita
tl;dr 昔は Windows で Git を使うのは辛かったが、現在は悪くない Scoop で簡単に構築できる 操作は CLI, 閲覧は GUI クライアントで使い分けている GUI クライアントは、 VS Code がオススメ 言わずと知れた、バージョン管理システム。 Windows と Git そもそも Git は、 Unix/Linux 文化圏で生まれてきたもので、Windows 対応はされてはいるがイマイチな時期が長く続いた。 イマイチだった点 Git を導入するために、Git 以外の登場人物が多く辛い ( 特に新人 Windowser には msys Git Bash ssh 情報が色々あって辛い 3~4 年前までは、まだ Cygwin 派の記事もあった Windows への導入の記事なのに、何となく Linux の知識ある前提だったり 鍵生成が辛い putty 形式 ? O
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
Gitでコメントを無視して差分を見る - tmtms のメモ
古いRubyのコードのコメントを独自のRDoc形式からYARD形式に変換して、さらにその後にプログラムを変更したんですが、その後に差分を見ると大量のコメントの差分が表示されて、実際のコードの差分が何かわからなくなったりしたので、コメントを無視して差分を取る方法を調べてみました。 普通にgit diffするとこんな感じ: diff --git a/hoge.rb b/hoge.rb index 8fa6659..0561977 100644 --- a/hoge.rb +++ b/hoge.rb @@ -1,8 +1,8 @@ -# == ほげクラス +# ほげクラス class Hoge - # === ほげ - # +str+ 何か + # ほげ + # @param str [String] 何か def hoge(str) - 123 + 456 end end プログラムとしての変
初心者でもほぼ無料でGitの使い方を学べるコンテンツ7選 - paiza times
Photo by othree こんにちは。谷口です。 開発業務未経験からITエンジニアを目指す方にとって、プログラミングだけでなく、習得しておきたいのがGitの使い方です。 Gitは、プログラミングしたコードの変更などをした履歴を管理してくれるシステムです。 開発をしていると、ファイルを編集前の状態に戻したいとか、間違えて編集しちゃったとか、どれが最新かわからないとか、そういうことがたびたび発生します。（プログラミングの勉強しているときに、コードをいじったら動かなくなってしまって「前の状態に戻したい！！」となった経験がある人も多いかと思います） そんなときに、バージョン管理をしておけば、コードの変更履歴を管理したり、過去のバージョンのファイルに戻したり…といったことが簡単にできます。そのため、ほとんどの企業がバージョン管理システムを導入しています。 バージョン管理システムには、大きくわけ
GithubでのWeb上からのマージの仕方3種とその使いどころ - Qiita
GithubでWebのGUIからマージしようとすると「Create a merge commit」、「Rebase and merge」、「Squash and merge」の選択肢があります。この記事では、それぞれのマージの動作の違いと使いどころをまとめました。 GithubのWebからのマージ GithubでPull requestをいただいてマージしようとすると以下の3種類が表示されます。 Create a merge commit Rebase and merge Squash and merge この動作の違いをまとめました。 前提 説明するに当たりマージする前の状態を以下の状態として進めていきます。これはAのリポジトリからBがforkして、2つコミットした後にAにPull requestを出して、取り込まれるのを待っている状態だと思ってください。 また、BがY、Zの変更をしてい
GRV - ターミナル上のGitリポジトリビューワー
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました Gitは普段の運用ではpush/pullの繰り返しですが、時に履歴を確認したいと思うことがあります。そんな時、logコマンドだけではなかなか辛いです。そんな時になってGitリポジトリビューワーが欲しくなりますが、GUIアプリケーションのインストールは面倒です。 そこで使ってみたいのがGRVです。ターミナル上で使えるGitリポジトリビューワーです。 GRVの使い方 立ち上げたところです。3ペイン構成でとても見やすいです。 ちゃんと差分を見ることもできます。 GRVではローカルのブランチはもちろん、リモート側を見ることもできます。ログを見る際の基本的な機能は押さえていますので、GRVだけあれば大抵のニーズには応えられることでしょう。インストールしておくと便利です。 GRVはGo製のオー
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
はじめに 先日参加したRails Developers Meetupの中で、「コミットの粒度がわからない問題」が少し話題になっていました。 「commitの粒度がわからない」すいません、私もです…！よく迷っちゃいます…！！！ #railsdm — まえとー (@maetoo11) July 20, 2017 commitの粒度がわからない問題、ある。（ほんとわからない） #railsdm — おおた (@ota42y) July 20, 2017 普段僕は感覚的に「それっ、ここでコミット！」とコミットしているんですが、具体的にどういうルールでやってるの？と聞かれると、きれいに明文化しづらいものです。 とはいえ、できるだけ明文化できるよう、模範解答を考えてみました。 この記事ではそんな「適切なコミット粒度」について解説します。 動画で明文化・・・！？ すいません、「明文化した模範解答」という
git push -f をやめて --force-with-lease を使おう - Qiita
force push問題 rebaseなどの作業の際、強制PUSHが必要なタイミングが出てくるが --forceではローカルの内容を破壊的にリモートレポジトリを上書きしてしまう。 同じブランチで複数人開発していた場合にタイミングによっては 「◯◯さんのコミットを吹き飛ばしちゃった//」 が発生する可能性が十分ある。 そもそも上記の運用方法に問題がある気はするが、どんな運用をしていたとしても force pushする際は --force-with-leaseオプションを必ずつけるようにしておいて損はないと思う。 TIPS: Github上でブランチを削除できないようにする 消されるとまずいブランチは [Settings] → [Branches]でさまざまなprotectionルールをかけておきましょう！
ステージを理解して git をもっと便利に使う(その2)
前回から引き続き、「ステージを理解して git をもっと便利に使う」というテーマでコマンドを紹介します。 今回は git diff --cached です。 ●git diff --cached 使用例 git diff --cached 前回覚えた git add でstageする/しないを使い分けると、困ったことがひとつ出てきます。 それは git diff が「index」と「ワーキングコピー」の差分だけを表示すること、つまり一旦git addでstageした内容はgit diffで表示されなくなってしまうことです。 前回の復習として、git add直後の「最新のコミット」と「index」、「ワーキングコピー」の関係を思い出してみましょう。 「最新のコミット」≠「index」＝「ワーキングコピー」 git diffは「index」と「ワーキングコピー」の差分だけを表示するので、「最新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
diff, branch、grepなどが改善されたgit 2.19
Git で全ブランチから検索
作業別Gitコマンド集 - Qiita
