gitでaddする前の状態で別ブランチに移動したくなった時に変更内容を避けておく方法。 - Qiita
$ git status On branch hogehoge_20150914 Untracked files: (use "git add <file>..." to include in what will be committed) hoge.php nothing added to commit but untracked files present (use "git add" to track) $ git checkout master error: Your local changes to the following files would be overwritten by checkout: hoge.php Please, commit your changes or stash them before you can switch branches. Abort
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
Git subtree のパワー | Atlassian Japan 公式ブログ | アトラシアン株式会社
Git subtree を使うとリポジトリを他のリポジトリのサブディレクトリとして追加することができます。Git プロジェクトがプロジェクト依存関係を管理する方法はいくつかありますが、これはその一つです。記憶力の良い人は、私が以前に Git submodule の代替の記事でこのコマンドの使用法と利点について書いたことを覚えているでしょう。 Git subtree の基本 それでは git subtree があなたにとって有益かどうかを判断するため、基本を振り返ってみましょう。想像して下さい。あなたは自分の持つリポジトリに外部プロジェクトをいくつか追加したいが、あなたや同僚の日々の利用するものにたくさんのものを追加したくはありません。このような場合に subtree コマンドは役立ちます。 例えば vim 設定を保存しているリポジトリに vim 拡張を追加したい場合はこのようにします: こ
便利な「git-サブコマンド」を作成する - Qiita
#!/bin/bash # Check arguments if [[ -z $1 ]]; then echo "too few argument" 1>&2 exit 1 elif [[ ! $1 =~ ^(((https?|git)://)?github.com/)?[A-Za-z0-9_-]+/[A-Za-z0-9_-]+(\.git)?$ ]]; then echo "$1: invalid github.com URL" 1>&2 exit 1 fi # Format username/reponame uri="$(echo "$1" | perl -pe "s/^((https?|git):\/\/)?(github\.com\/)?//;s/\.git$//")" username="${uri%/*}" reponame="${uri#*/}" # Destination
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
Emacs上で動作するGitクライアント「Magit 2.2」リリース | OSDN Magazine
Emacs上で動作するGitクライアント「Magit」の開発チームは8月15日、最新版「Magit 2.2」をリリースした。多数のコマンドが追加されている。 Magitは、Emacs上でバージョン管理システムGitを操作するためのパッケージ。Gitの主要コマンドをEmacs上から操作できることを目指しており、現時点でもGitユーザーが利用するほとんどのタスクをEmacsから行えるという。 Magit 2.2は7月に公開されたMagit 2.1に続く最新版。6週間に19人から合計321のコミットがあったという。パッケージマネージャELPA（Emacs Lisp Package Archive）で提供される「with-editor」および「magit-popup」パッケージが「async」パッケージに依存するようになり、「async-bytecomp-package-mode」モードを有効にす
git pullを対話的に実行する - Qiita
使い方 どういうことかというと、git pull -iを打てば、shellと対話しながらpullできるというシロモノです。 こんな感じ。 $ git pull -i Please input remote (default: origin) upstream Please input branch (default: master) master # file diff .gitignore | 1 + app/assets/javascripts/hoge.coffee | 7 + app/controllers/hoge_controller.rb | 2 +- 3 files changed, 9 insertions(+), 1 deletions(-) Are you sure you want to run? (y/N) リモートリポジトリとローカルブランチを入力すると試しにd
Git使ってて困ったこんな時 - Qiita
ブランチの派生元間違えた!! 本当はdevelopブランチから切らないといけないのに、masterブランチからfeature/hogeブランチを切ってしまった もう３回くらいコミットしてしまった...(´；ω；｀)ﾌﾞﾜｯ ブランチ作りなおしてcherry-pickするか....... こんなとき!! $ git log --graph --all --decorate --oneline * 08733a5 (HEAD -> feature/test) test 1 * e7872a3 (master) master 2 | * 09140ba (develop) develop 1 |/ * 8c001b5 master 1 $ git rebase --onto develop master feature/test First, rewinding head to replay y
Magitユーザーマニュアル
MagitユーザーマニュアルMagit は、バージョン管理システムGitリポジトリへのインターフェースで、 Emacsへの拡張機能として実装されています。 Magitは、GNU Emacsのバージョン22以降をサポートしています。 それは、他のemacs達も動作するかもしれませんが、Magit開発者は、サポートされていないバージョンで表示されたバグを調査し、修正するつもりは ありません。 でも、他のemacs達のバグ修正パッチや、互換性を維持するボランティア活動は歓迎します。 はじめに謝辞セクションステータス追跡されていないファイルステージングとコミット履歴Reflogsバッファーをコミット差分を取るタギング再設定隠しておく分岐ブランチマネージャどうなってんのー？マージリベース書き換えプッシュとプル2分割表示サブモジュールMagit拡張機能の使用直にGitを使用カスタム化よくある質問 1
Better Commit Messages with a .gitmessage Template
It can be tough for your team to know exactly why they need the changes you’re proposing in a pull request. What if we could give them more context? There’s an episode of The Weekly Iteration where a simple trick was mentioned. After adopting it myself, I have noticed my co-workers commenting on how useful these messages have been in providing context. The trick is simple. Split your PR message in
レジストリファイル (UTF-16) をdiffやGitで扱う - Qiita
$ file foo.reg foo.reg: Little-endian UTF-16 Unicode text, with CRLF line terminators レジストリファイル (.reg) はテキストファイルであるが, UTF-16は, 以下のようにバイナリとして認識されてしまうため, 適切に処理できない. $ less foo.reg "foo.reg" may be a binary file. See it anyway? $ grep HKEY foo.reg # 何も出力されない $ sed 's/HKEY/hkey/g' foo.reg # 変換されない $ diff foo.reg bar.reg Binary files foo.reg and bar.reg differ $ git grep HKEY # 何も出力されない $ git diff Bina
Gitのオブジェクトモデル(The Git Object Model翻訳)
Git Community Book から、1章2節の The Git Object Model を翻訳。ライセンスは、 GPLv2 。 多くのGit解説本と違い、まずGitの内部モデル解説から入るという、おもしろい構成の本です。人によっては、このほうがわかり易いかもしれません。Gitは差分データを管理していると誤解されることがたまにありますが、それは誤りであるということがこれを読めばわかります。 SHA プロジェクトの履歴を表すのに必要な情報は、いずれも、40桁の「オブジェクト名」で参照されるファイルに格納されている。オブジェクト名は、このような形をしている: 6ff87c4664981e4397625791c8ea3bbb5f2279a3 このような40文字の文字列は、Gitのあらゆる場面で見られる。どの場面で出てくるものであれ、その名前は、オブジェクトの内容のSHA1ハッシュを取るこ
[してはいけないシリーズ] 誤ったcommitを消すためにブランチを消す - Qiita
してはいけない例 pushしてしまったcommitを消すためのHackとして、リモートブランチを消して再度pushするという方法が推奨されていたりするんですが、これは絶対にやめてください。 # 不要なcommit1と不要なcommit2を消したい $ git log --oneline hash789 不要なcommit2 67hash8 不要なcommit1 ha567sh 正しいcommit # 正しいcommitまで戻す $ git reset --hard ha777sh # リモートのブランチを消す $ git push origin :develop # ローカルをリモートにpushする $ git push origin develop 確かに消すことはできるんですが、そのリモートのブランチに紐付いているPull Requestが全部closeされてしまいます。 していい例
![[してはいけないシリーズ] 誤ったcommitを消すためにブランチを消す - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b78ea2ad0dd24e1789803dfa616e49a6657f2202/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgxJTk3JUUzJTgxJUE2JUUzJTgxJUFGJUUzJTgxJTg0JUUzJTgxJTkxJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgyJUI3JUUzJTgzJUFBJUUzJTgzJUJDJUUzJTgyJUJBJTVEJTIwJUU4JUFBJUE0JUUzJTgxJUEzJUUzJTgxJTlGY29tbWl0JUUzJTgyJTkyJUU2JUI2JTg4JUUzJTgxJTk5JUUzJTgxJTlGJUUzJTgyJTgxJUUzJTgxJUFCJUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUIzJUUzJTgzJTgxJUUzJTgyJTkyJUU2JUI2JTg4JUUzJTgxJTk5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1lNmVjMmU2ZGNjMWVhOWI1NjBjN2ZjNDU3NzY3NGViNw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzaGlidWtrJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03YzBiZTM0MDEzZjU0M2UyOGU0N2E2N2MxYTE1ZjY1ZQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dac613345c85c4d9e9d764ca674ba0d51)
分散型バージョン管理ツール「Git 2.5」リリース
分散型バージョン管理ツール「Git」の開発チームは、最新版となる「Git 2.5.0」を7月27日（現地時間）にリリースした。Gitのメンテナーを務めているのは、米Googleの濱野純（Junio C Hamano）氏。 UIやワークフロー、および機能面での新機能は、bashの補完スクリプトへのいくつかのオプションの追加、git diffコマンド使用時と--ws-error-highlightオプション併用時の背景の塗り潰し、git helpで表示されるコマンドリストのグループ分け、git p4でファイルがすでに開かれている際の正確なファイルタイプの認識などが追加されている。 パフォーマンスや内部実装については、既存のオブジェクト名に使用されるunsigned char [20]のstruct object_idへのコンバート、for_each_ref()コールバック機能によるstruct
gitのブランチを利用して秘密のフォルダを作る - Qiita
みなさん、人に見られたくない秘密のファイルはどこに隠してますか？ 「決算関連資料_第3四半期」フォルダですか？ 「TEMP_20120820」フォルダですか？ それともやはりクラウドでしょうか？ いくらバレにくいフォルダ名をつけてもうっかり開かれるかもしれない・・・。 クラウドに保存するのはさすがにちょっと気が引ける・・・。 zip圧縮して拡張子を変えるのもめんどくさい・・・。 隠しファイル用の専用ソフトを入れるのも、そのソフトを入れた時点で疑われる・・・。 なかなかベストな方法とは言えないですよね。 そこで、gitで秘密ファイルを管理する方法を考えてみました。 gitならインストールされていても不自然ではないですし、 さりげなくスマートにヒミツのファイルを隠すことができます。 方法 方法はこんな感じです。 【下準備】 ①Gitのリポジトリを作る。 ②秘密のファイルを突っ込む。 【PCを人
プルリク前にgit reset --softで簡単にコミットをまとめる方法 - Qiita
プルリク前にコミットを一つにまとめたい場合、良く有る方法としては新たにブランチを切り直して、 そちらのブランチにgit merge --squashしてコミットをまとめるという方法が取られると思います。 git reset --softの場合は以下の手順でコミットをまとめます。 git reset --soft ${ブランチを切った時点でのコミットハッシュ} git add . git commit -m "あらたなコミットメッセージ" 共同開発しているブランチであれば、レビュー用にブランチを新たに切ったほうが良いと思いますが、 個人で開発しているブランチで、自分以外がcheckoutしたりコミットしないブランチであれば、 git reset --softでまとめてしまうのが一番楽かと思います。 ※git reset --softはHEADが指し示すコミットを移動させる事が出来ますが、詳し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitで直前のコミットのAuthor(作者)とAuthor Date(作成日付)を変更する。 - Qiita
Git 2.5がリリース，ワークツリーをサポート，三角形ワークフローやパフォーマンスなどを改善
「Git for Windows」v2.5.0が公開、プレビューを脱した初めての正式リリース
Git2.5のアップデート内容について - Qiita
