GitのRebaseによるBranchの運用 | DevelopersIO
渡辺です。 東京では雪が降って騒ぎになっていますが、札幌では雨が降って騒ぎなっています。 これっていわゆる「北から目線」ですが、目線の違いってのは結構大切なことです。 はじめにお断りしておきますが、今回紹介する手法はひとつの運用方法です。 自分はこんなやり方が好きだ／嫌いだといったことを言われても、「そうっすかｗ」としか言えません。 特にGitを使うと様々なやり方があるでしょう。 それらを否定するつもりも、今回紹介する方法が完璧な方法だとも考えていません。 あくまでGit（バージョン管理）運用手法のひとつとしてご紹介いたします。 マサカリを投げるのは歓迎しますが、好みの押しつけはご遠慮ください（笑） メインBranchへのMerge 安全なMergeを行う開発フローでも解説しましたが、Gitでは各開発者がそれぞれ作成したBranchに変更をCommitし、最後にメインBranchへMerg
git rebaseを使うときのルール | Yakst
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
