git rebase -i を tig を使ってグラフィカルに行う - Qiita
bind main R !git rebase -i %(commit) bind diff R !git rebase -i %(commit) Rはキーバインドです。自分の好きなキーを設定できます。 追記と注意：2017/09/30 ka_さんのコメントにもありますが、 R 設定をすると tig の"Reload and refresh view" という機能が rebsae 機能に上書きされます。tig の設定が初めての方は B の方がいいかもしれません。ただし、F5 でも更新できるのと、自分が慣れてしまっているのもあって、この記事は R のままにしています tig で選択した箇所で R を押すと git rebase -i が起動します。 tig 上で選択したコミットから git rebase -i してみる feat: 修正というコミットを商品データの取得というコミットに fix
lazygit - ターミナル用のGit UI
Gitはターミナルで使っている人が多いかと思いますが、細かい操作になるとつい忘れがちです。不要なファイルが混ざったのに気付かずに思わずコミットしてしまったり、コミット後のキャンセルなどいちいちネットで調べたりしているのではないでしょうか。 そこで使ってみたいのがlazygitです。ターミナル上のGitクライアントです。 lazygitの使い方 Gitリポジトリで実行するとlazygitが立ち上がります。 コミットメッセージの入力もできます。 コミットロゴを追いかけたり、ファイルを対象外にしたりするのも簡単です。 lazygitがGitのすべての機能を使えるとは思いませんが、普段の運用時に使っているくらいの入力であれば問題なくこなせるでしょう。GUIの重たいソフトウェアは使いたくないが、Gitを見やすく管理したいと言った場合に便利そうです。 lazygitはGo製のオープンソース・ソフトウェ
変化を楽しむ：あなたのshell環境は？：zshのPROMPTを2行にしてみた
こんにちはCTOの馬場です。 ハートビーツの企業理念のひとつに「変化を楽しむ」があります。 その流れもあり、個人的に意識的に変化を起こすようにしています。 例えば慣れたOS、エディタ、shellなどのツールを敢えて変えたりして、意識的にコンフォートゾーンから出るようにしています。 今月は個人PCのshellのPROMPTを2行にしてみたので紹介します。 今までずーーーーーっとPROMPTは1行で短いものだったので、正直なところ最初は抵抗と違和感がありました。 こういうの。 でもやってみて、、、、結論から言うとオススメ。 今はこんな感じです。 メリット gitの状態や長いパスを表示しても、入力行の左側が長くならなくてスッキリ 入力行の右側に何も出ないのでコピペでGitLabやSlackに情報共有するのが楽(以前は入力行の右側にgitの情報を表示していた) 手元環境とリモート環境の違いがよりわ
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
Gitで日本語長文のdiffをとる方法
課題 日本語の長文をgitで管理していると、ほんのちょっとの変更でも、diffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にgit diff 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック クリミナル」リポジトリの途中経過
git rebase で squash する - Change the World!
このブログをご覧のみなさん、こんにちは。 Pull Request を送った後の指摘に対応していたところ「 squash してコミットを 1 個にまとめて」と言われたので、手順を調べたのでメモとして残しておきます。 squash には 2 種類ある squash はすべてのコミットを 1 つにまとめるもので以下の 2 種類があります。 git merge --squash [branch or commit] git rebase -i [commit] git merge –squash [branch or commit] 前者は git merge コマンドで実行している通り、[branch or commit] で指定した内容を 1 つにまとめて merge します。今回 Pull Request を送った自分に対して「 squash して」と言っているので、これとは別になります。
Gitのブランチ名を返すエイリアスを設定したら地味に捗った - Qiita
すると、brname で今のリポジトリのブランチ名を標準出力で返すようになりました。 コマンドと組み合わせる 追記 こちらのaliasを使った例ですが、aliasを使わなくてもできる方法をコメントにて指摘頂いており、 Gitのブランチ名を返すエイリアスを設定しなくても地味に捗った にまとめましたので、こちらも併せてご参考下さい。 git push ブランチをローカルで作ってリモートに初めてpushする時に使えます。 毎回ブランチ名をコピペしてpushしていた作業がコピペ不要になります。 追記：コメントにて push -u については git push -u origin HEADがこれと同じ意味になるとの指摘をいただきました。確かにこちらだとaliasも不要ですね…！ git pull 自分の今いるブランチのみpullすると、余計なものをpullせずにすむのでブランチ名で指定したい時に使え
Gitでpushする前にテストが通る事を確認する - Tech Blog
ようやく暖かくなってきて春が近づいてきた感がありますが花粉症が辛い時期のiOSチームのかっくん(@fromkk)です。 そういえば先日のtry! SwiftはTimersのiOSチーム全員で参加してきました。 面白いトークばかりでしたが頑張って英語で聞こうとしたばかりにあまり理解が十分に出来なかった箇所もあるので動画が公開されたら振り返りたいなと思っています^^; 昨晩サーバーチームの人達と話をしていて、稀に Syntax error が発生したコミットをプッシュしてしまい開発サーバーでエラーが出てしまう事があるという話を聞きました。 iOSでもビルドエラーだったりPushした後にCIでテストが通らなくてSlackでテストが失敗した旨を通知されると悲しくなりますよね。。 リモートリポジトリにPushする前にエラーチェック出来ないかなと思って少しトライしてみました！ Git hookを利用
Remove Xcode default header comment
Xcode file template Every new source file created from Xcode template has top comment similar to this: // // <file name> // <Name of project> // // Created by <My name> on <Date>. // Copyright <Year and company>. All rights reserved. // It has little useful information, and often incorrect. As file name, project and company changes how can we keep in sync file comments? In Agile environment when w
Visual Studio Code の git 連携機能と git コマンドについて (2018/05/23) - Qiita
Git - Book 2nd Edition (2014) 日本語訳の Chapter 2. Git の基本 Chapter 3. Git ブランチ機能 Chapter 7. Git のさまざまなツール に出てくるコマンドに VS Code のコマンドをあてる感じで書き直してみる Visual Studio Code の git 連携機能と git コマンドについて (2018/05/23) Git の情報源 Git クライアントとしての Visual Studio Code git コマンドと vscode の git 関連操作 git 連携機能の設定項目 出力パネル Git の基本 Git リポジトリの取得 既存のディレクトリでのリポジトリの初期化 既存のリポジトリのクローン 変更内容のリポジトリへの記録 ファイルの状態の確認 新しいファイルの追跡と変更したファイルのステージング 状態
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
