はらへり日記 - 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 commitをやり直しする＆取り消しする(「get commit --amend」と「git reset」) - hogehoge foobar Blog Style Beta
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す（git commit --amend） 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
ど素人でも、アプリ「Git-it」を通じてGit/GitHubが使えるようになった話 - LOGzeudon
このページは別のブログに移転しました。
Git超入門："git push origin master"の"push"と"origin"と"master"の意味がわからないあなたへ · DQNEO日記
Home Subscribe この２行のコマンドを見て((；ﾟДﾟ))ｶﾞｸﾌﾞﾙした経験はないでしょうか？ 私は恐怖を感じました。 "remote"と"add"と"origin"と"push"と"master"の意味がわからん！！ 人間（というか私は）は、わからないものが３つ以上同時に登場すると、ストレスを感じるものです。 この場合は５つもあるのでものすごいストレスです。 でもご安心を！ これから超わかりやすく解説します！ git remote add origin ... の意味は？ ずばり、 URLに"origin"という短縮名(ニックネーム)を付ける したがって、git remote add unko .... と書いてもかまいません。 慣習上、"origin"という名前が使われることが多いというだけのことです。 そして、ここが重要なのですが 別にニックネームをつけなくてもよい。(
Gitのリモートブランチと追跡ブランチは違うよ - kaeruspoon
いまさら感がひしひしと伝わってくる今日この頃ですが、ようやくまともにGitを触りはじめています。 Gitについては Learn Git Branching という素晴らしいサイトがあって基本的なところはだいたい理解できました。 ところでGitの本を読んでいると大きくわけて三つのブランチが出て来ます。 * ローカルブランチ * 追跡ブランチ * リモートブランチ 最初の頃、追跡ブランチとはローカルブランチが追従しているリモートブランチのことで、つまりはリモートブランチと追跡ブランチは同じものを指していると思っていました。両方ともリモートリポジトリ上にあるものだと勘違いしていて、ここでちょっと混乱していました。 実のところ、追跡ブランチ自体はローカルリポジトリ上にあります。これに気づくといろいろとGitの理解が深まりました。ちゃんとこのことを書いている本ってあまりないですよね。 以下のような状
Gitでブランチをリモートに送る時の注意点
B! 32 0 0 0 まだ余りGitで複雑な事をしてないこともあって曖昧なまま 使ってる点が多くて駄目ですが、 新しく作ったブランチをリモートに送る際に ちょっと勘違いしてた事があったのでその辺のまとめ。 リモートにブランチを送る pullしてみる リモートとの接続を調べる pullにも登録する pushするときに登録する リモートにブランチを送る 新しいブランチを送るには1 $ git push <remote repository> <branch> でリモートレポジトリに遅れてGitHubとかならウェブから見れば新しい ブランチが確認できます。 $ git clone [email protected]:rcmdnk/sentaku.git ... $ git branch -a * master remotes/origin/HEAD -> origin/master remot
gitで差分を抽出してpatchで使えるファイルを生成 | 秋山ブログ
gitで差分を抽出してpatchで使えるファイルを生成したい時、毎回同じ検索ワードで検索して、毎回同じサイトを見ていたので、自分用にメモ。普通のpatchコマンドで取り込めるdiffファイルをgitで作成する – kanonjiの日記という記事が自分にとって一番分かりやすかった。このページを参考に、自分が使う用に書いておく。 $ # ファイルを生成 $ git diff (diffの方法) > (パッチ名.patch) $ # 実行結果を確認 $ patch --dry-run -p1 例 $ git diff develop features/dummy > diff.patch $ patch --dry-run -p1 gitに関する書籍
Mac / Windows / Linuxに対応した無料のGUI Gitクライアント「GitKraken」 | ソフトアンテナ
クロスプラットフォームのGUI Gitクライアント「GitKraken」が公開されています。現在パブリックベータテスト中で、公式サイトよりMac / Windows / Linuxに対応した実行ファイルを無料でダウンロードして使用することができます。 最近流行のElectronを使用して作成されたソフトウェアのようで、libgit2やNodeGitといったオープンソースライブラリも組み込まれています。 Electron風の美しいGUI ▼メイン画面は以下の通り。 コミット履歴やブランチの分岐が美しく表示されているのが印象的です。コミットやブランチの作成/マージ、pull/pushといったGitの操作をGUIを使って行う事ができます。 ▲設定画面を使って「git config」の設定や、sshの鍵の管理、GitHubやBitBucketといったサービスの認証情報の管理、Git Flowの設定
【実践FuelPHP】gitで管理するFuelPHPプロジェクトをつくろう | DevelopersIO
FuelPHPを業務で使う上で、必要となってくるのがgitでの管理。 ウェブアプリといえど、ソース管理をしないと怖い。 ということで、さっくりとgitでFuelPHPのプロジェクトを管理する手法をメモしておきます。 多分、他の人もこんなかんじで管理してるんでしょ？って方法です。 何番煎じ位な感じなので、別にこの方法じゃなくても管理できるはずですが、とりあえず・・・ FuelPHPのファイル群をsubmodulesとして管理する いろいろ考えた挙句、gitでソースコードをそのまま引っ張ってくることが便利というところに行き着きました。 が、メンテナンス性を考えると、そのままファイル郡をsubmodule化するほうが楽かと。 バージョンの問題等でどうしても使わなきゃいけない以外は最新版を使えば問題なさそうですし。 まずは、FuelPHPのgitリポジトリから最新のものを取得します。 git cl
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Git でブランチを整理しつつリポジトリを移行する | risou's Lithograph
使っている管理ツールが変わったりサーバを移行したりする際、Git のリポジトリもあわせて移行する必要が出てくることがある。 最近、移行作業をすることがあったので、そのログを残しておこうと思う。 やりたいこと メインはもちろんリポジトリを移行することだが、それに付随してやりたいことがもう1つあった。ブランチの整理である。 手順 手順のみを簡単に列挙する。 旧リポジトリから git clone する 旧リポジトリ上の全てのブランチを取得する メインストリームにマージされていないブランチの一覧を取得する 残したい(マージされていない)ブランチ以外を削除する origin の接続先を新リポジトリに設定する 残したい全てのブランチを push する 手順の詳細 便宜上、旧リポジトリを [email protected]:user/old_repo.git 、新リポジトリを [email protec
git reset がわからない - Qiita
git reset がわからないので図をかいた 以前のコミットへ戻るとき 現在の HEAD へ戻るとき 現在の HEAD へ戻る という日本語はおかしかった。 reset は HEAD の位置を変更する。 オプションとしてステージ上、ワーキングツリーのファイルを削除したり残したりできる。 HEAD へ reset するということは HEAD の位置がかわらない reset --soft はステージにもワーキングツリーにもなにもしない、のでなにもおこらない reset はステージ上からファイルを降ろすので、add の取り消しになる reset --hard はワーキングツリーへの変更も削除してしまう。コミットしていない作業は消える。 メモ ステージ と index は同じもの unstage はステージから削除されるということ HEAD^ は HEAD の一つ前のコミット ローカルファイルを
Git管理ツール「SourceTree」で差分ファイルを抜き出す方法 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
どうもです、お久しぶりです、はやちです✌(´ʘ‿ʘ｀)✌ ここ最近DMMのブラウザゲーム「刀剣乱舞」にハマってしまいましてひたすら刀狩りをしております( ˇωˇ )＜おじいちゃんこない そんなことはどうでもいいですね。 今回は、Git管理ツール「SourceTree」を使用して昔のファイルと作業したファイルの差分を抜き出す方法をご紹介いたします( ˘ω˘)☝ バッチファイルを用意する まずはバッチファイルを用意しましょう( ˇωˇ)☝ 適当なディレクトリにファイルを保存します。 Windows用 Windows用がこちらです。 export_diff_zip.bat if "%2" EQU "" ( set PARAM1=HEAD set PARAM2=%1 ) else ( set PARAM1=%1 set PARAM2=%2 ) setlocal enabledelayedexpan
Git リポジトリに上がっているファイルを履歴ごと消すには？ - Qiita
仕事で必要になったので、ファイルを履歴ごと消す方法を試してみました。 ファイルを消しても履歴は残っている 例えば、1GB のバイナリファイルを Commit & Push したとします。 そして、それを git rm で削除したとしてもリポジトリの容量は減りません。 なぜか？ git rm は「ファイルが削除されたことにするコマンド」であって、「Git リポジトリ内に保存されている履歴を消すコマンド」ではないからです。 このサイトに書かれていますが、Git は「差分」ではなく「スナップショット」を保存して、「どのスナップショットを参照するのか？」をコミット単位ごとに切り替える仕組みです。 git rm は、この「どのスナップショットを参照するのか？」という情報を削除するコマンドです。 もし、データを丸ごと消したいのであれば、保存されている全ての「スナップショット」を消さなければなりません。
Git中級者に送る便利なコマンド群 - カイワレの大冒険 Second
Gitを使っていて、ちょくちょく便利だなと思うコマンドに出会うので、メモ残しておきます。実際中級者の方には物足りないかもしれませんが、とりあえず。目次は以下。 自分がいじったファイルを一旦退避させたい ツリーが今どういう状態になっているか確認したい 今まで作業をやったことを振り返って、特定の過去に戻りたい リモートブランチをチェックアウトしたい コンフリクトがあったファイル一覧を表示したい 間違ってremote masterブランチにpushしてしまったので、取り消したい マージコミットを消したい 過去のまとまったコミットをまとめたい ここから載せるサンプルは、以下のフローが既に処理された前提で話します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # 適当にファイル作成、push $ touch sample.txt
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dev:core:git [Piwigo Wiki]
こっそり始めるGit／GitHub超入門
Git講座 - [SMART]
vbacでエクセルVBAのソースコードをGitバージョン管理する方法
