Sorry. This site has been closed. Please use the Search for commit messages on GitHub instead. The original source code is available at minamijoyo/commit-m.
よそからcloneしてきたリポジトリでは、remotes/origin/xxxという名前でoriginのブランチが参照される。 だが、他の人がhogeブランチを削除してoriginにpushしても、既にそのブランチが手元にある人のローカルリポジトリからは普通にpullしても消えてくれない。 そういった既にリモートで削除されているブランチを消したい場合は、以下のどちらかの操作を実行すればちゃんと消えてくれる。 git fetchもしくはgit pullにpruneオプションをつける --pruneオプションをつけると、fetchやpullする際に自動的にリモートで削除されているリモートブランチを削除してくれる。
シンプルに、リモートの本家リポジトリを fetch し手元にマージするという方法。 fork したリポジトリに移動して以下を行う 本家を upstream という名前でリモートとして追加する git remote add upstream git://github.com/FOO/BAR.git git remote -v show 本家の変更を fetch git fetch upstream 本家の変更を merge git merge upstream/master 手順としてはシンプルで理解しやすい。 fork したリポジトリの master は常に本家に追従するようにしておいて、pull request を送る際には必ずトピックブランチを切ってから送るように運用すればよさそうだ。 参考 GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する - Qiita
こんにちは。monipla facebookを担当している佐藤(ま)です。 アライドでは「大佐」と呼ばれております。 最近Gitの操作にも慣れてきましたが、SourceTreeは未だ手放せません。 さて今回は、関連性はありませんが「HEAD^ HEAD~」と「ダブルドット/トリプルドット」について書いていきたいと思います。個人的に最初少しとっつきにくかったので。 HEAD^とHEAD~ まず、HEADとは「今いるブランチの最新コミット」のことですね。 つまり「git show HEAD」とすれば最新のコミット情報が見れることになります。 なのでHEADを起点にすればわざわざハッシュを指定しなくてもコミットログを見ることができます。
2019/12/11 分かりやすいサイトへのリンクを追加しました hub コマンドの hub fork について追加しました 2013/04/11 興味深い手法があれば随時追加していきます ネットを検索すると、色々な手法が出てきますが、自分としては「WEB+DB PRESS plus 開発ツール徹底攻略」p.71 に載っていた以下の手法がシンプルで良く理解できました。 本家リモート upstream を追加する方法 本家リポジトリの例として、実際にGitHubに存在する練習用リポジトリ git@github.com:DQNEO/Renshu.git を使います あなた (youraccount) が既にForkしているRenshuリポジトリをcloneします。 $ git clone git@github.com:youraccount/Renshu.git Cloning into 'R
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
git blame 使い方 ファイルの各行がどのコミットのものか調べる file.txt に対して git blame file.txt とすると、 各行毎にコミットのハッシュ値、著者、時間が表示される。 git blame の出力を変更する -f コミットのファイル名を表示する -s 著者とタイムスタンプを表示しない -l ハッシュ値を短縮しないで表示する 行番号で指定した範囲の各行がどのコミットのものか調べる 「-L」オプションで範囲を指定できる。 行番号で指定するには数字を二つコンマで区切って指定する。 また、「+」と「-」を使ってオフセットを指定できる。 git blame -L 5 file.txt git blame -L ,5 file.txt git blame -L 5,10 file.txt git blame -L 5,+3 file.txt git blame -L
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 例えば新機能Xを実装する場合、 X用のトピックブランチを作成し、実装を進めて、完成したら統合ブランチへマージする というのが普通です。 具体的にコマンド例を挙げると以下のようなものになります: $ git checkout -b topic-x master Switched to a new branch 'topic-x' $ $EDITOR $ git add foo.x bar.x baz.x $ git commit -m 'Implement X' [topic-x 0000001] Implement X 3 files changed, 8 insertions(+), 5 deletions(-) $ $EDITOR $ git add qux.x $ git commit -m 'Fix
git branch 使い方 新しいブランチを作成する ブランチ new-branch を新しく作るには git branch new-branch とする。すでに new-branch というブランチが存在しているときはエラーになる。 ブランチやコミットから新しいブランチを作成する あるコミットを指示する some-commit や他のブランチ other-branch から ブランチ new-branch を作成するには git branch new-branch some-commit git branch new-branch other-commit とする。たとえば、最新のコミットを除いて新しいブランチを作る (2つ前のコミットからブランチを作る)には git branch new-branch HEAD^ とする。 ローカルのブランチの一覧を見る git branch とする
まずは、リモートにどんなブランチがあるかを確かめる。-aオプションでリモートブランチも一覧できる。 > git branch -a * master remotes/origin/master remotes/origin/other_branch チェックアウトしたいブランチが表示されていない時は、git fetchとかすると情報をリポジトリから取得できる。 > git fetch 次に、ローカルブランチ名を指定して、リモートブランチをチェックアウトする > git checkout -b other_branch origin/other_branch 最初の引数がローカルブランチ名 -bオプションを指定しておくと、自動的にそのブランチに切り替わる。 -bオプションを指定しないと、以下を再度する必要がある。 git checkout -b other_branch
Posted on Wed May 21 22:41:31 +0900 2008 by nabeken 別のブランチで作業をしていて、また、ブランチを作って作業をしようと思い # git checkout -b moge // これは別のブランチからさらにブランチを作る操作で、やりたかったのは以下の操作 # git checkout -b moge master // master からもう1つブランチを作りたかった 前者でブランチを作ったことに気がつかず、masterにマージしてしまった。まだ公開予定ではない記事がマージされてしまった。さて、どうしよう。 gitk コマンドで戻すべきHEADを捜しだす。その commit-ish を master にすればよい。ただし、masterでなかったことにしたい期間のコミットを含むブランチがまだ残っていることを確認すること。さもなければ、コミット
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
git log で変更者、変更日時等の変更履歴が表示されますが、変更されたファイル名を表示するには --stat, --numstat, --name-status, --name-only などで知ることができます。 % git log --stat commit 801fe8c4bd09f91bb2172640c4857acc52f89135 Author: Yuumi Yoshida <yy@ey-office.com> Date: Sun Aug 3 12:15:30 2008 +0900 バグ対応 upload.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) commit 609aa81ec0a489cdac4cb2398918758f609a47e4 Author: Yuumi Yoshida <yy@ey-
git clean 使い方 git clean で削除されるファイルを確認する 「-n」オプションをつけると、実際にはファイルを削除せず、 どのファイルが削除の対象となるか表示される。 git clean -n 追跡されていないファイルをワークツリーから削除する リポジトリに管理されていないファイルは git clean で まとめて削除することができる。 git clean -n で削除対象のファイルを確認して git clean -f で実際に削除する。 「-f」オプションは git の設定で clean.requireForce が false (デフォルト値)になっていても ワークツリーのファイルを削除する。 git clean の対象を制限する git clean にファイルパスを与えると 削除の対象を制限することができる。 たとえば、削除するファイルをディレクトリ dir 以下
2013-02-25 Gitのconflictを解決する方法 Git 複数人で開発をしているとよくこんなことが起こります。最新のmasterからブランチを切って作業開始 ↓ シコシコ作業 ↓ よーしできた!commitしてpush、pull requestだー! ↓ Bitbucket:「conflictが発生しています」 ↓ なぬぬ…これは、自分がbranchを切った後に他の開発者がリモートのmasterにマージしたために、自分のローカルのmasterがリモートのmasterより遅れていることに起因して発生します。 こんなときは以下のように対応します。 まず、localのmasterにブランチを移動してmasterを最新の状態にします。 $ git checkout master $ git pull 作業中のブランチに移動し、リベースします。 $ git check
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く