他人のコミットをgit merge --squashするべきでないのではという話 - Qiita
最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまったことが一部界隈で話題になっていました。この件にはマージを行った人に悪意はなかったようなのですが、gitの理解不足により生じてしまった案件だとすると悲しい話なので一応メモ 何が起きたか コミッターが複数の内容が含まれたPRを送った 管理者はその中の一部の内容だけをマージするために、管理者はgit merge --squashを実施し、コミットを改変した上でmergeを実施した ←これが問題 コードの内容はコミッターのものなのに、Authorだけ管理者にすげ変わってしまいコミッターのモチベを損ねた そもそもsquashするとどうなるの ここに分かりやすくまとまっています。 アジャイルSEを目指すブログ 図で分かるgit-mergeの--f
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ：git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ
最強のGitフロントエンドはForkかもしれない - たけぞう瀕死ブログ
昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版（動作にはMacOS X 10.11以降が必要）のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー（見た目的にはSourceTreeに近い） コミット時点のファイルツリーを確認できる 動作は軽快（ただし安定度についてはまだ不明） ターミナルから起動する
Compromise On Checkout - Vulnerabilities in SCM Tools · The Recurity Lablog
The Recurity Lablog Posts computer security, research, reverse engineering and high level considerations First Round: Git LFS In mid May 2017, I was about to go on my two month parental leave, when I stumbled across a nifty vulnerability in Git LFS, which is developed by the fine people at GitHub. The actual vulnerability was shockingly simple: Git LFS can be configured (partially) by a .lfsconfig
Gitのステージング領域の正体を探る | メルカリエンジニアリング
ソフトウェアエンジニアの @DQNEO です。こんにちは。 Gitの内部構造を深掘りするシリーズ３回目です。 前回までのお話はこちら Gitのつくりかた – Mercari Engineering Blog Gitのコミットハッシュ値は何を元にどうやって生成されているのか – Mercari Engineering Blog 今日はみんなだいすき「ステージング領域」の中身について解説してみます。 ステージング領域とは何か？ 簡単に説明すると「次にコミットしたときにコンテンツとして登録されるもの」リストです。(別名「インデックス」ともいいます。) このリストは、 git addやgit rmしたときに書き換わります。 (古くはcacheと呼ばれていました。内部実装やgit diff --cachedに今もその名残があります。) git addのマニュアルに説明があります。 Git – git
一気に書いた新規ファイルを一部git addしたい時にはgit add -Nが便利 - Takuji->find;
新機能作ったりする時、コード書くのに集中しすぎるとコミットする前にめっちゃ色々混ざったファイルができてしまったりして、最悪な感じになることが多い。 自分は割と細かい単位でコミットするようにしている(あとで戻せるように)ので、こうなってしまった時今まではチマチマと手動で消してaddして、commitして、undoしてみたいなことをやっていたが、ミスったりすると数時間分の作業が消える。 そういう時にはgit add -N (file path) すると、ファイルの存在だけindexに乗せることができるので、あとはgit add -pでパッチモードにしてがんばる。 そもそもちゃんと細かくコミットしろよって話でもある。
Git 2.11 has been released
CompanyGit 2.11 has been releasedThe open source Git project has just released Git 2.11.0, with features and bugfixes from over 70 contributors. Here's our look at some of the most interesting new features: Abbreviated… The open source Git project has just released Git 2.11.0, with features and bugfixes from over 70 contributors. Here’s our look at some of the most interesting new features: Abbrev
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におけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
Gitの最初のコミットは空コミットにしよう
# リポジトリ作成 git init # 最初のコミット git commit --allow-empty -m "first commit" 解説 Gitの最初のコミットを修正したいとなると以下のようなことをする必要がある git commit --amend で最初のコミットを修正する(コメントで教えてもらいました!) この方法なら楽にできますね git rebase -i --rootでrebaseする git update-ref -dで参照を更新する 参照 First commit が git rebase -i できない問題 → git rebase -i --root でできる 初回のコミットを取り消したいときにはgit update-refを使う 上記のよう面倒くさいので first commit は空コミットにしておくと良い。 こうすることで2回目以降が本質的に意味のある
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
過去に戻れ！reflogを使いこなしてこそGit中級者である。 - カイワレの大冒険 Third
Gitの一番好きなコマンドといっても過言ではない reflog 。 すごく便利なので、使いましょうと言う話です。 簡単にいえば、 reflog で過去を探索し、 reset で好きなタイミングに戻ることができるというテクニックです。 開発していると、ここまでいじっちゃったけど、ここまで戻したいとかそういう欲が出てきます。 そういうときに是非使って欲しいコマンドです。 では説明していきます。 まず説明用に、いくつかファイルを作り、コミットなり色々しときます。 $ cd ~/work/ $ mkdir git $ cd git/ $ git init Initialized empty Git repository in /Users/masudak/work/git/.git/ # 適当にファイルを作る $ touch sample.txt $ git status On branch ma
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
気付いたら.gitignoreはgiboで自動生成する時代になっていた - Qiita
$ gibo --version gibo 1.0.4 by Simon Whitaker <sw@netcetera.org> https://github.com/simonwhitaker/gibo $ gibo java ### https://raw.github.com/github/gitignore/8c9b77cb5c85f6464c0bb31abdf4cfcfdf6833bb/java.gitignore *.class # Mobile Tools for Java (J2ME) .mtj.tmp/ # Package Files # *.jar *.war *.ear # virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml hs_err_pid*
地震や火事など緊急時に使うgit-fireのススメ - Qiita
$ git-fire "やばい" Switched to a new branch 'fire-master-[メールアドレス]-1444060029' [fire-master-[メールアドレス]-1444060029 bc88227] @a 1 file changed, 13 insertions(+) create mode 100644 index.html Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 384 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gith
続・Git中級者に送る便利なコマンド群 - カイワレの大冒険 Second
前回の記事「Git中級者に送る便利なコマンド群」でははてブ経由で多くのコメントを頂きました。今回の記事では、頂いたコメントのうち、いくつか取り上げて、可能な限り補足をしたいと思います。 git push origin master -f 前回の記事で最も多くご指摘頂いたのがmasterに対するforce pushに関してでした。結論から言うと、これはやっちゃいけませんね。 forceが必要になるときでパッと思いつくのはgit commit –amend後であったり、git rebase後なのですが、これらは過去の歴史を書き換えているので、共同レポジトリとかでやってしまうと、他の人がpushできなくなってしまうのですね。 AさんのローカルレポジトリAと、BさんのローカルレポジトリBをもとに再現させてみましょう。ディレクトリAもディレクトリBもともに、リモートからcloneしてきたものです。
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - git-chglog/git-chglog: CHANGELOG generator implemented in Go (Golang).
git resetを使って、単一のファイルをmasterに戻す - カイワレの大冒険 Third
