Git ファイルの履歴を完全に削除する
Git_ファイルの履歴を完全に削除する.md Git ファイルの履歴を完全に削除する 秘密鍵など誤ってコミットしてしまった場合に履歴を完全に削除する手順 参考:6.4 Git のさまざまなツール - 歴史の書き換え 動作確認用にブランチを作成して試す $ git checkout -b clean-key-file 動作確認用にブランチでgit filter-branchを実行 $ git filter-branch --tree-filter 'rm -f common/key/id_rsa' HEAD Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) Ref 'refs/heads/clean-key-file' was rewritten clean-key-fileブランチでid_rsaが履歴から完全に削除されているこ
GitHub CLI 1.0 is now available
ProductGitHub CLI 1.0 is now availableGitHub CLI brings GitHub to your terminal. It reduces context switching, helps you focus, and enables you to more easily script and create your own workflows. Earlier this year, we… GitHub CLI brings GitHub to your terminal. It reduces context switching, helps you focus, and enables you to more easily script and create your own workflows. Earlier this year, we
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
gitで別のリポジトリにpushする - masartz->log(type=>'hatenablog')
通常git push は git cloneしてきたリモートリポジトリに対して打つ事が多いので、 git push とか git push origin master くらいしか打ったことがありませんでした。 とある対応で、my/hoge.gitのリポジトリで作業したあと、最終的にpublic/moge.gitのリポジトリとして公開したいという 場面があり、git merge あたりを軽く眺めたんですが、結局 init commitなので手動コピー -> git add , commit , push でも いいかというアナログ手抜き対応をしちゃいました。 すかさず突っ込みを貰い、非常にシンプルな正解を教わりました。。 my/hoge.git をcloneしたディレクトリで、↓の1行で一発 git push [リポジトリ名] master （ 前述の例だと git push git@rep
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回記事「たった3つで共存できる、Git／GitHubとSubversion（SVN）の連携、移行に関する基本操作」では、Subversionとの連携や移行について解説しました。 本連載の最終回となる今回のテーマは「Git／GitHubのワークフロー」です。幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。 git-flow 「git-flow」はVincent Driessen氏の「A
リモートのgitブランチをローカルにチェックアウトする - setoya-blog
まずは、リモートにどんなブランチがあるかを確かめる。-aオプションでリモートブランチも一覧できる。 > git branch -a * master remotes/origin/master remotes/origin/other_branch チェックアウトしたいブランチが表示されていない時は、git fetchとかすると情報をリポジトリから取得できる。 > git fetch 次に、ローカルブランチ名を指定して、リモートブランチをチェックアウトする > git checkout -b other_branch origin/other_branch 最初の引数がローカルブランチ名 -bオプションを指定しておくと、自動的にそのブランチに切り替わる。 -bオプションを指定しないと、以下を再度する必要がある。 git checkout -b other_branch
はらへり日記 - Git開発でmasterの内容を開発ブランチに反映させる方法
Git開発を行っていると、こんなことありませんか。 origin/masterブランチからhogeブランチを切る hogeの実装をゴリゴリ行ってる間にorigin/masterブランチがどんどん更新されていく 自分が編集してたファイルがmasterで更新されてた＼(^o^)／ origin/masterを一回merge、コンフリクトを直してPull Requestを送る あるあるですよね。 そしてrebaseを知らない頃の僕は以下の方法で解決していました。 % git checkout master % git pull origin master % git checkout hoge % git merge master (ここでコンフリクトが出て怒られる) (bot modifiedステータスのファイルを修正、コミット) % git push origin hoge ここでやっとPu
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
Git 2.0以降の変更点まとめ
WindowsのGitが長い間1.9.5のまま更新が止まっていたため、WindowsでGitを使用する方向けにGit 2.0以降での変更点についてまとめたいと思います。 以下のAtlassianのBlogも参考にしてください。 とうとう Git 2.0 が現実のものに。便利な機能満載 - Atlassian Japan git pushのデフォルト動作の変更 git push時の動作がmatchingからsimpleに変更となりました。 以下は設定できるモードの説明です。 matching 2.0以前の既定です。この設定では現在いるブランチ以外のブランチもあわせてアップストリームにpushします。アップストリームに同名のブランチがあれば同名のブランチにpushします。また、ローカルにあって、アップストリームに無いブランチがあったら、そのブランチはpushされません。 意図したブランチはpu
Upgrade Git to 2.5.2 in CentOS 6.4 through yum (Example)
I found it is impossible to find lastest Git in yum repo. Fortunately, the Git source base has provided make rule to build RPM package. Note you have to build the rpm from the source code repo. Building rpm from source tarball is not supported. yum install curl-devel expat-devel xmlto asciidoc git clone https://github.com/git/git.git cd git make rpm Find the rpms in ~/rpmbuild/RPMS/x86_64 Install
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
GitLabの運用方法をドーンと公開！！ - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2016の時間です。今回はピクシブ株式会社でエンジニアをしている @catatsuy が担当します。今回は意外と書いてなかったのでGitLabを社内でどう運用しているかの話を書こうと思います。 GitLabとGitHub ピクシブ社内では以下の2つの方法でソースコードを管理しています。 自社でホストしているGitLab GitHub Organization それぞれ以下の特徴があります。 GitLabのメリット 自社でホストしているため、アメリカにサーバーがあるGitHubよりもgit cloneでリポジトリをダウンロードする場合などは速い オープンソースのプロジェクトのため、社内のサーバーにインストールするだけで使える ソースコードを読めば内部でやっていることが分かる ユーザー数やリポジトリ数などで料金がかからないため、気軽に使える G
![GitLabの運用方法をドーンと公開！！ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e3e8f846870fc5033b87b4b346a4f506eb82516/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F11696248318756278971%2F10328749687197154835%2F1481852582)
GitやSvnなどの差分ファイル抽出決定版 - なんたらノート第三期ベータ
せっかくソースコードのバージョン管理をしているのに、納品物が「前回との差分ファイル」だったりすることありますよね。たしかに変更ファイルはこんなコマンドで、こういうふうに出せます。 $ git diff --name-status HEAD~1 M foo/bar.html A foo/baz.html ...が、このとき差分がいろんなディレクトリに分散していると、選んで取り出すのが面倒です。 それで以前こんなこと (Subversionで、あるリビジョン以降の差分をファイルで抽出 - なんたらノート 第二期) をしていたのですが、使っているバージョン管理ツールがひとつに固定できなくなってきたし、そもそも差分の取り方も多様なオプションが欲しかった。というわけで書いたのがこれです。 使い方 $ git diff --name-status HEAD~1 M foo/bar.html A foo
テクニカルライティングの未来を先取り ー Asciidoc フォーマットと GitHub を使って技術書 Pro Git を共同執筆
テクニカルライティングの未来を先取り ー Asciidoc フォーマットと GitHub を使って技術書 Pro Git を共同執筆 Pro Git 第2版の「最高の執筆過程」と「最終的な制作環境」 ちょうど6年ほど前、出版社の Apress から「執筆スケジュールが押している本を手伝って欲しい」と連絡があった。本のタイトルは Pro Git。ほどなくして元々の著者が執筆を断念することになり、僕が一から書きなおして2009年の8月ごろに出版にこぎつけた。最初の3章分くらいは Word で書いていて、書き上げたファイルを編集者に送り、しばらくすると訂正版が送り返されてくる、といった感じだった。 でも、このやりとりを3章分も続けているといよいようんざりしてきたので、「Markdown フォーマットを使わないか」と頼んでみた。執筆と技術的内容の訂正は Markdown で、その後の出版に向けた校
Git - Book
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
git add -p をさらに分割する - 納豆には卵を入れる派です。
$ git add -pという、ひとつのファイルから分割して部分的にcommitできる便利なオプションがあって、最近commitをもうちょっとこまめに分けようと心がけるようになってからたびたび使うのだけど、そうすると欲が出てきて、もう少し細かく分割してくれたらなあと思うことがたまにある。git add -p もうちょっと細かくわけてくれたらいいのにとたまに思う— TAE ✅ (@ken_c_lo) February 16, 2013 @ken_c_lo 確か「git add -p」した後に「y」とか「n」で取り込むところを選ぶ時に「s」をやると、さらに小さい単位に分割してくれた気がします。最近やってないので若干怪しいですが。。— 松本 瞬／Shun Matsumoto (@shu_0115) February 16, 2013 @ken_c_lo だいたいこんな感じだったと思います。→ b
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Flow (Japanese translation)
GitExplorer
Gitの使い方をアニメーション付きで学べるサイト「Learn Git Branching」 | ライフハッカー・ジャパン