[git]ローカルブランチがどのリモートブランチを追跡してるのか確認する方法 - dackdive's blog
githubのリモートブランチと対応するローカルブランチってどれだっけ？ という時に確認する方法。 ここに書いてあります。 git - Find out which remote branch a local branch is tracking - Stack Overflow git branch -vv とすると * master 93e4e9f [origin/master] READMEを修正 のように[]内に追跡中のブランチが表示されます。 たいていはリモートブランチ名とローカルブランチ名を揃えているので 問題はないのですが、 リモートとローカルでブランチ名を変えている場合、 または作業ツリーに複数ブランチある時に 「そもそも追跡ブランチってどれだっけ...？」 という事を確認するのに便利です。 （ちなみに） ローカルブランチが特定のリモートブランチを追跡するように設定するには
![[git]ローカルブランチがどのリモートブランチを追跡してるのか確認する方法 - dackdive's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a6e12004609f875c02ac97ee65343400775aada/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712615374%2F12921228815714339984%2F1645799953)
Gitで数個前のcommitを遡って分割する - 納豆には卵を入れる派です。
数個前のcommitを遡って、それを分解して2つのcommitに分けたいとか、たまにある。 例えば、git logで上から遡って5つ目のcommitを2つに分けたい場合 $ git rebase -i HEAD~5git-rebase -i で5個目のcommitをeditに変える pick xxxxxx Add JS files pick xxxxxx Move Vendors CSS files pick xxxxxx Add jquery.powertip pick xxxxxx Add font edit xxxxxx Design for tasks#index ← 分割したいcommitの 'pick' を 'edit'に変えるで、git-rebase -i した状態で、HEADの位置をさらに一つ手前のcommitに移動する $ git reset HEAD~すると、分割したい
First commit が git rebase -i できない問題 → git rebase -i --root でできる - 納豆には卵を入れる派です。
git init してから一番最初のcommit内容を、2番目のcommitと一緒にまとめたい、と後で思った。 よーし、git rebase -i HEAD~~からのfixupで… $ git rebase -i HEAD~~ fatal: Needed a single revision invalid upstream head~~えっ・・・(ΦωΦ) 一番最初のcommitはgit rebase -i HEADほにゃららでは遡れないのか・・・一番最初のcommitはgit rebase -i できないのか・・・？— TAE ✅ (@ken_c_lo) April 21, 2013 @ken_c_lo それ方法あったら知りたいですねー。調べた限りでは無さそうなのもあって、自分でリポジトリ作る時はgit flow initを使って最初に空のInitial commitを作るようにしてます
.gitattributesで改行コードの扱いを制御する - Qiita
Gitで管理するファイルの改行コードの扱いは、どうしたらよいのでしょうか。どうルール化するのがよいのでしょうか。 なぜルールが必要か そもそもなぜルールが必要なのでしょうか。以下の例で考えます。 AさんはLinuxマシンでコーディングしており、LFで改行されたソースコードのファイルXをGitにコミットしました。 一方、BさんはWindowsマシンでコーディングしています。今、Aさんが書いたコードを編集したいとします。GitからファイルXをチェックアウトして編集するわけですが、このとき、Bさんが使っているエディタはファイルXの改行コードをCRLFに変換してしまいました。Bさんはそれに気づかずコードを編集し、保存し、コミットしました。 BさんはファイルXの中の数行だけを編集したつもりなのに、改行コードが変わったために、全行に差分が生じてしまいました。これではコードレビューもしにくいし、後日、g
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
gitで1つのコミットを複数のコミットに分割する | Webシステム開発／教育ソリューションのタイムインターメディア
gitでは様々な方法でコミットログを書き換えることができます。 その一例として1つのコミットを複数のコミットに分割する方法を紹介します。 問題 先日紹介したgitで複数のコミットを1つにまとめる例ですが、そこでは以下のコミットログを: $ git log -n 4 --oneline --reverse 0000001 Add a neat feature X into the library 0000002 Update to use X 0000003 Fix a typo in X 0000004 Fix a bug in X $ git rebase -i HEAD~4 [detached HEAD b000001] Add a neat feature X into the library 8 files changed, 94 insertions(+), 9 deletion
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
Gitのpost-receive Hookでブランチ名などを受け取ったりする | おそらくはそれさえも平凡な日々
いろいろ調べてまとめようとしたら、以下によくまとまっていた。 http://stackoverflow.com/questions/7351551/writing-a-git-post-receive-hook-to-deal-with-a-specific-branch/13057643#13057643 標準入力にoldrev, newref, refnameが空白区切りで入ってくるのでそれを読み出す。push --allなどで複数のブランチが一度にpushされた場合には複数行の入力が入ってくる。 なので、masterブランチがpushされ、前回からarticleディレクトリが更新されていた場合に作業をさせたい場合は以下のようにすれば良さそうであった。 #!/bin/bash # 標準入力を一行づつ読み出す while read oldrev newrev refname; do br
NDP Software :: Git Cheatsheet
stash workspace index local repository upstream repository status Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the workspace and the index file, and paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace
履歴を残したまま複数のgitリポジトリを統合する - Qiita
半年ほど前のことでうろ覚えなのですが、pixivで複数のリポジトリを統合したときの方法を紹介します。 AAAAAリポジトリとBBBBBリポジトリを統合し、ZZZZZという大きなリポジトリを作成します。もちろんコミットログを統合前まで遡れるようにするのが絶対条件です。 最終形↓ ZZZZZ .git AAAAA BBBBB filter-branch まず、新しくgit clone AAAAAしてきます。（なぜなら、このディレクトリはこの後使い捨てられるので、pushされてないbranchとがあると困るからです） 次にcd AAAAAして、次のコマンドを実行します。 git filter-branch --index-filter \ 'git ls-files -s | sed "s@\t\"*@&AAAAA/@" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new
Git submodule の基礎 - Qiita
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました😩💦 さて、今月正式リリースしました(！) Doc...
Gitのデータモデル
近藤です。こんにちは。Gitは様々な利用の仕方ができますが、その基盤となるモデルは8個だけの簡単なモデルです。これらのモデルを理解していない状態でGitを利用すると、あたかもリポジトリが壊れたように見えてしまいます。Gitは難しいと言われますが、そういう感想を持つ人はGitのモデルを理解していない事が多いようです。 今回はGitを構成する中心モデルと、基本的なコマンドを実行した時のオブジェクト関係を解説します。 基本概念 Gitの基本概念は大きく2つにわかれます。 GitObject Reference GitObjectはGitで管理するオブジェクトです。CommitなどがGitObjectです。Gitリポジトリである.gitを開くとobjects配下にあるファイルがGitObjectです。GitObjectはそのコンテンツをハッシュ化した文字列を元に、先頭2文字で配置フォルダ、残りの文
jgit で s3 にプライベートリポジトリ(IAM編) - nazokingのブログ
この投稿は Git Advent Calendar 2014の 10日目の記事です。 昨日は kyanro@github さんの githubとgoogleを利用して世界征服の意図を調べる でした。 明日は @a-suenami さんです。社内に git サーバがあったりしてデプロイするときに git pull できずに rsync を使っていたりする全国の皆様こんにちは。rsyncだとデプロイ先で緊急修正したときや試行錯誤したあとにgitリポジトリに書き戻すのが大変だったりしませんか？ EC2 でリポジトリサーバたてられればいいけど EC2 のインスタンスはそれだけに使うにはちょっと高い。せめて s3 にリポジトリがおけたら…… できます。 git ではなく jgit です。git を java で実装した jgit というプロジェクトがあります*1。 その中に jgit.sh という
依存リポジトリ管理でのsubmodule/subtree/subrepoの使い分け - Qiita
依存ライブラリを利用する場合RubyGemsやらCocoaPodsといったツールで万事解決するケースがほとんどだと思いますが、たまーにGitに上がっているライブラリを直接自分のリポジトリに追加しないといけない場合もあったりします。 こういった時に使うGitのサブコマンドそれぞれの特徴と使いどころをまとめてみました。 submodule 一番スタンダードな外部リポジトリ追加方法です。たぶん大抵の依存管理ではこれを使えば十分でしょう。git-submoduleを利用すると、外部リポジトリのコード自体は自プロジェクトの管理下に取り込まれず、リポジトリの特定コミットへの参照情報のみが登録されます。外部リポジトリのcommit hashへのポインタが追加されるようなイメージです。 $ git submodule add git@github.com:Alamofire/Alamofire.git $
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
削除したbranchを復活させる - Qiita
横着で神経質な私とあなたに贈るgit add -p - Qiita
What does the term "porcelain" mean in Git?
http://penguin.works/git-push%E3%81%97%E3%81%9F%E3%81%A8%E3%81%8D%E3%81%AB%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%AF%8E%E3%81%AB%E8%87%AA%E5%8B%95%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%97%E3%81%9F%E3%81%84/
Gitでやらかした時に使える19個の奥義 - Qiita
