意外と知らない？ Gitコマンド 100本ノック - Qiita
概要 みなさん、Git使ってますか？ もしくは、使いこなしていますか？ 独習Gitを読んで、思いの外Gitコマンドが多かったので、 タイトルの通り、Gitコマンドで100本ノックをまとめてみました。 Gitの環境構築が終わっている状態からを想定しています。 git initでローカルにリポジトリを用意してください。 問題に対して、直後に回答を載せる形式にしています。 Git初心者の方も、目を通して知らないオプションをググれば勉強になると思います。 参考文献 独習Git Gitに馴染む 1. メールアドレスをGitのグローバル設定に追加 git config --global user.email "Your E-mail@example.com" 2. user.nameの設定値を表示 git config user.name 3. user.emailの設定値を表示 git config
Gitリポジトリをメンテナンスして軽量化する - Qiita
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
Git で コミットを無かったことにする方法 （git revert の使い方） - akiyoko blog
Git でコミット（とかマージ）を無かったことにする方法といえば、「git revert」なのですが、使い方にちょっとひとクセ（？）あったのでメモっておきます。 「git revert」は正確には、commit を無かったことにするのではなく、対象の commit の変更を相殺するような差分commitを自動で生成するというものです。 コミットを文字通り無かったことにする（コミットログから特定のコミットだけ抜き出す＝履歴が残らないようにする）には、「git reset --hard」「git rebase」「git cherry-pick」「git push -f」などを駆使すればできるのですが、いくつかコミットやマージが重ねられた後にそれをするのは、あまり現実的とは言えませんよね。 そこで、「git revert」の登場です。 実践 例えば、以下のような commit があったとします。
削除したbranchを復活させる - Qiita
c939342 HEAD@{0}: pull: Fast-forward fb488d2 HEAD@{1}: checkout: moving from feature/hogehoge to develop 7f4b273 HEAD@{2}: checkout: moving from feature/hogehoge to feature/fugafuga
ストレスフリーなGitHubのIssue生活 - クックパッド開発者ブログ
こんにちは。サービス開発部の丸山@h13i32maruです。 今日はGitHub/GHE(GitHub Enterprise)で快適なIssue生活をおくるために作ったJasperというツールと、それを実際にどうやって使っているかを紹介させていただきます。 ストレス GitHub/GHEを日々の業務の中心として使っていると、すごくたくさんのIssueやPull Request(以下PR)が流れてきます。 これらのIssueを処理する方法としては主に「メール」と「通知ページ(github.com/notifications)」の2つだと思います。 僕もこれらの方法を使っていたのですが、以下の点ですごく困っていました。 多すぎてメンションされたものやコメントしたものを見逃してしまう あとで見ようと思って、忘れる ブラウザのタブを大量に開いた状態になる 知らないところのIssueで議論が進んでい
GitHubでマージ済のプルリクをrevertした後に引き続きrevertされたブランチで作業を続行したい時 - Qiita
GitHub上でプルリクをマージした後に、まだマージできる状態では無かったと気付きrevertする事ってありませんか？ その後に問題になるのが、revertしたのはいいけど、引き続きそのrevertされたブランチで作業してまたプルリクを発行したい。という状況です。 この時に何も考えずに普通に作業を続行してプルリクを発行した場合、revertされた分の変更が失われてしまいます。 結構でかい事故に繋がる場合があるので、この時の対処方法を書きたいと思います。 前提 以下の操作を行っている。 プルリクを発行 プルリクをマージ マージ済のコミットのrevertプルリクを発行 revertプルリクをマージ ここまでの操作はGitHub上ですんなり行える。 再度revertされたブランチのプルリクを発行してみる 普通の感覚だと、また差分が復活していると思うのでプルリクが発行できそうな気分になると思います
Git Howto: Mirror a GitHub repo without pull refs | Christoph Rüegg
Maintaining .NET open source projects for 15 years and counting. Enjoying functional programming, distributed algorithms and number crunching. Twitter GitHub NuGet Keybase.io LinkedIn Paypal Math.NET Math.NET is an opensource initiative to build and maintain toolkits covering fundamental mathematics, targeting advanced but also every day needs of .Net developers. Contributions FsBlog FsLab Docu Pa
Git のマージについて、自分的まとめ - Make You Feel Better
チーム開発で Git を使ってから半年ちょい位経ちました。 Git 玄人な人たちに囲まれて開発していたおかげで、そこそこ Git 力がついてきました。 そんな中で、ブランチの統合（マージ）についての考え方が大分固まって来たのでまとめます。 まずは結論から。 統合するブランチ → 統合されるブランチ : 統合の為に使うコマンド ローカル(自分用) → ローカル(自分用) : 適当に ローカル(自分用) → ローカル(リモート用) : merge --squash リモート → ローカル(リモート用) : pull --rebase ローカル(リモート用) → ローカル(自分用) : rebase ローカル(リモート用) → ローカル(リモート用) : merge --no-ff ローカル(リモート用)は、リモートドラッキングブランチからチェックアウトしたブランチを指してます。 要は、git
git logのオプションあれこれ - 煙と消えるその前に
普段何気なくgit log叩いてるけど、実はオプションが多くて驚いた。 自分的に使えそうなものをメモしておく。 参考サイト transitive.info - git log 使い方 Git - コミット履歴の閲覧 僕の考えた最強のry 色々調べた結果、自分で使うならこんなところかなーという結論に至った $ git log --graph --name-status --pretty=format:"%C(red)%h %C(green)%an %Creset%s %C(yellow)%d%Creset"そのまま使うには長すぎるのでエイリアスにしておく $ git config --global alias.mylog 'log --graph --name-status --pretty=format:"%C(red)%h %C(green)%an %Creset%s %C(yellow
diff-so-fancy - 差分をより見やすく加工
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました プログラマであればDiffを使うことがしょっちゅうあるはずです。そのため、Diffの使い勝手の良さ/悪さが開発効率に直結しているとも言えます。git diffなど、標準のままに使っていないでしょうか。 git diffは色分けされて見やすくなっていますが、さらに整形して可読性を上げてくれるのがdiff-so-fancyです。 diff-so-fancyの使い方 diff-so-fancyのインストールはnpmで行います。 npm install -g diff-so-fancy 実際に使い方は次のようになります。–colorはデフォルトになっている環境もあるでしょう。 git diff --color | diff-so-fancy 標準のdiff。色分けされているので見づらいわけ
どこでも使える git diff と git apply - Qiita
Git Advent Calendar / Jun. 28日目の記事です。27日目はつるはしで過去を発掘するでした。 Git リポジトリの外で git diff / git apply あまり知られていないことですが、 git diff と git apply は Git リポジトリの外でも使えます。普通の diff ではできない、バイナリファイルを含む2つのディレクトリの差分を取りたいときなどに重宝します。ちょっと試してみましょう。 $ mkdir dir1 dir2 $ echo foo > dir1/text $ echo FOO > dir2/text $ dd if=/dev/random of=dir1/binary bs=128 count=1 $ dd if=/dev/random of=dir2/binary bs=128 count=1
【Git】TIPS: リモートブランチをチェックアウトする方法 | DevelopersIO
はじめに こんばんは！ Github などを使ってチーム開発を行っていると、他のチームメンバーが作ったリモートブランチをチェックアウトしたい時があると思います。 特に、プルリクエストをコードレビューするときとか！ そんな時、僕はいつも $ git fetch $ git checkout -b branch_name origin/branch_name とターミナルに入力していたのですが... 実は！ $ git fetch $ git checkout branch_name だけで大丈夫のようです！ タイプ数が半分くらいになってとっても幸せです！ まとめ リモートブランチをチェックアウトするときは、 $ git fetch && git checkout branch_name を使おう！ ではまた！ 参考 Checkout remote Git branch - Stack Ove
GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
git2.3.0をRPMにてインストール
git2.3.0をRPMにてインストール �z$F�U 0q7F�U rpmbuild用のvagrant環境を用意する。 以下、vagrant環境にて実施。 vagrant: CentOS-6.5-x86_64-v20140110.box rpmbuild環境の構築 # yum groupinstall "Development tools" # yum install rpmdevtools createrepo yum-utils # rpmdev-setuptree # cd ~/rpmbuild/SOURCES/ # wget https://www.kernel.org/pub/software/scm/git/git-2.3.0.tar.gz # tar zxvf git-2.3.0.tar.gz SPEC情報をソースより取得する。 # cd ~/rpmbuild/SPECS/
Git - 認証情報の保存
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Git - タグ
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git logのフォーマットを指定する - Qiita
リモートリポジトリを他のものに移行する方法 - Qiita
gitで空白の違いだけの行を除いてaddする - Qiita
