別リポジトリのコミットをパッチとして当てる (git format-patch & git am)
A fashion developer. Interested in life engineering. やりたいこと稼働中の現行リポジトリと、リニューアル中のリポジトリが並行稼動しているシーンを想定している。 ビジネスロジックはそのまま引き継ぎ、フレームワークをすげ替えたい。 リニューアル作業は全く別の新しいリポジトリで実施していたが、現行リポジトリの改修も背後で続いていた。 共通であるビジネスロジックの同期をとるために、お互いのリポジトリの変更分をパッチ化し、一連のコミット群を取り込みたい。 実現方法以下のやり方は コミット日時が維持される。 つまり、コミットは通常通り並ぶが日時が時系列で並ばない。 （Git的にはコミットが過去から未来へキレイに並ばなくてもよい模様） パッチを作成する取り込みたい内容がコミットされているリポジトリのブランチで以下を実行。abcd123は開始コミットのS
YoctoでLinuxカーネル触るときのTips - Qiita
ことあるごとに「Yoctoで取ってきたコードで開発しちゃダメ」とはいわれるものの、ビルド環境がある以上はソースを触りたいのが人情。 というわけでYoctoでLinuxカーネル触るときのTipsを記載してみる 以下ターゲットがi.MX6の環境について記載されているので、それ以外のターゲットでは適宜読み替えること。 最重要事項: gitリポジトリは作り直される 基本的にdo_unpackタスクが走ると、gitリポジトリごと一から作り直される。 そのためコード修正してgit commitして一安心、と思っていると泣きを見ることになる。 do_unpackはdo_cleansstateしたりレシピファイルを修正したりすると簡単に走ってしまうため要注意。 カーネルソースはどこにあるか 以下で確認可能
GitHubで他人のプルリクエストに対しコンフリクト解消や追加の修正を行いつつマージするもう1つの方法
GitHub 単純なコマンドラインでmergeする方法が使えない時 本の虫: GitHubで他人のプルリクエストに対しコンフリクト解消や追加の修正を行いつつマージする方法を読んで, そう言えば私もバイトで最初にチーム(私と社長で2人)で作業を行うときに戸惑ったなあと思い出しました. なので, 今のバイト先の社長から教えてもらった, もう1つの方法を紹介します. 江添さんの述べた方法は, シンプルでわかりやすいですが, 我々のチームでは使えません. 何故ならば, 我々のリポジトリにはTravis CIによる自動テストが導入されているからです. そして, コードレビューで承認を貰い, 自動テストが成功していない限り, 原則masterにはそのpull requestをmergeしてはいけないというルールがあります. なので, 社長が作ったpull requestが気に入らなくて私が修正をしたい
Meld
Meld Visual diff and merge tool Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems. Meld helps you review code changes and understand patches. It might even help you to figure out what's going on in that merge you keep avoiding. File comparison
Success is a Journey, not a Destination: 初心者向けガイド: Linux カーネルのハック
( The newbie's guide to hacking the Linux kernelがとても素晴らしい記事だったので翻訳しました。 ) ( 2010-09-28 LinuxCon Japan にて、口頭ですが、Greg K-H から翻訳・公開の許可をもらいました。Thanks! ) カーネルをハックするのに、コンピュータサイエンスの博士号や下積み期間は必要ないよ。もちろんそういうことは役には立つ。でもLinux開発の重要な点は、誰にでもオープンだってことだ。とにかく取り組むことが必要。あなたは毎日何らかの形でLinuxカーネルを使ってるでしょ? どんな小さいことでもいいから、カーネル開発を少しでも手伝えば、それを誇りに思えるはずだ。 多くの貢献をしていて (そして Linux Format の読者でもある) Greg Kroah-Hartman に聞いてみた。初心者が Linu
プログラマが知るべき 97 のこと - Backnumbers: Steps to Phantasien
「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...) 一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい. パッチのなやみ 私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
