http経由の git コマンド(push,clone,fetch..)等がなんかうまく動かないときにデバッグする方法 - tanacasinoのメモ
git push、git pull なんかがどうにもこうにもエラーだなーって時に使えるかもしれないワザ。 リモートレポジトリのURLがhttp/https の場合に限るです。 GitBucketを使った際に、 git cloneできない問題 に引っかかった時にデバッグで使用しました。 環境変数「GIT_CURL_VERBOSE=1」を設定しておくと、通信内容(curl)のDEBUGを出すことができますという話。 $ GIT_CURL_VERBOSE=1 git clone http://localhost:18080/gitbucket/git/root/test01.git Cloning into 'test01'... * Couldn't find host localhost in the .netrc file; using defaults * About to connec
https時代のgitアカウントを使い分ける方法のメモ - ひと夏の技術
時代はhttps https://help.github.com/articles/set-up-git/ GitHubではhttps推奨になっているし… httpsのほうがclone速度はやいし… まとめに書くけどhttpsにすると覚えることが1個だけでラク SSHでアカウントを使い分けるときはどうしていたか ~/.ssh/configを作成して host github.com-main HostName github.com IdentityFile ~/.ssh/id_rsa_github User git host github.com-sub HostName github.com IdentityFile ~/.ssh/id_rsa_github_sub User git みたいなことを書いてssh-add -K ~/.ssh/id_rsa_githubして $ git clo
私の使うGitコマンドまとめ 見る編 - what is it, naokirin?
前回はGitを使う上で絶対に必要なコマンド（+オプション）について書いてみました。 実際には他にも必要なコマンドはたくさんありますが、今回はそのうちでも「見る」ということに焦点を当てたコマンドをまとめてみようと思います。 git status (現在の状態を見る) git diff (差分を見る) git ls-files (管理しているファイルを見る) git shortlog (軽くコミットログを見る) git log (コミットログを見る) git reflog (HEADの遷移を見る) git show (コミットの詳細を見る) git grep (ワークツリーのファイルを検索する) git blame (ファイル内の行ごとの最終更新を見る) git status (現在の状態を見る) まずは現状を知ることから。 git statusとすると、現在のブランチとコミットされていない、
Gitを使い始めたら一番最初にやりたい `git config`設定メモ - ねこの足跡R
Gitで一番最初にやる設定をよく忘れるのでちょっとメモしておきます。 git config 初期設定 ユーザー名とメールアドレス push方式 pull方式 merge commitを作成するか rebaseするか デフォルトのブランチ名 プロキシ 改行コードの自動変換 ファイル名の大文字と小文字を区別する 使い勝手を向上する 文字色 エディター エイリアス 日本語ファイル名をエンコードしない 認証情報をキャッシュする セキュリティを向上する パスワードの登録を禁止 GPG署名 設定内容の確認 設定内容を削除する ここまでの~/.gitconfig 書籍 参考サイト git config Gitの設定を行うにはgit configコマンドを利用するか、設定ファイルを直接作成＆編集します。 git configコマンドを実行すると自動的に設定ファイルが作成されます。すでに設定ファイルが存在し
Gitでバージョン管理したastahファイルの差分を確認する方法
こんにちは。UMLモデリングツールastah*のプロダクトオーナー山本です。 今回は、astah*のプロジェクトファイルをGitで管理する場合に、コミットハッシュ値を指定するだけで差分を確認できる方法について書いてみたいと思います。 任意のバージョンのファイルを比較する方法 SourceTreeを使用して比較する方法 プロジェクトを通して構成管理すべき成果物は企画、開発、運用、保守、プロジェクトマネジメントを通して多岐に渡ります。その中にastah*のプロジェクトファイルも含まれていると思います。これらの異なる種類の成果物についてGitで統合的に扱うには、Sourcetree等の専用ツールを利用するのが妥当だと考えます。この時気になるのは、リビジョン間の差分をどう確認するかではないでしょうか。 astah*には、プロジェクトの比較機能というものがあります。これをコマンドラインから利用できる
Gitコンフリクト解消ガイド（git mergetoolの使い方） - Qiita
ファイル編集がコンフリクトした場合 下記はよくある（忌々しい）コンフリクト画面ですね。 皆さんはコンフリクトのmergeはどんな方法でやっていますでしょうか？ vimやemacsで直接編集している方が多いイメージですが、実際開いてみると、下記のように差分が表示されていると思います。 この画面を見ただけではどのようにmergeすればよいのかわかりません。（Objective-CのARC/MRC双方の開発経験がある人は目をつぶってください・・） gitにはこのようなコンフリクトのmergeを支援するgit mergetoolコマンドが搭載されています。 このままEnterキーを押すと下記のような画面が立ち上がります。 画面幅の都合でフォントが小さいのですが、ここで「mergeしたい差分が作られる直前の状態」と「mergeしたい差分」に注目してみます。 この2つを見比べると、@propertyの
[Git] 脱初級！誤コミットはもう怖くない - Qiita
一通り最低限必要なコマンドは覚えました。 普通にコミットしてrebaseやmergeを行ってプルリクを出すことが出来ます。 誤コミットをreset HEAD^で取り消すことも出来ます。 でも、commit --amendやrebaseで誤コミットしてしまってパニック！！ そんなあなた(ちょっと前の自分)に必要な知識をまとめました。 コミットしたものは消えない そう、消えないのです。 たとえ、git commit --amend やら、git rebase で既存のコミットを編集しても、 編集前のコミットがそのまんまの状態で残っているんです。 どういうことかというと。 コミットが、A -> B ->C と行われた状態から、 Cに対して git commit --amend すると、 このように新しいコミットC'が作られブランチが付け替えられているだけなのです。 なので、ブランチの情報を元のC
![[Git] 脱初級！誤コミットはもう怖くない - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/847c7ba56f216002753c39d446dd432d2140cb12/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-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCR2l0JTVEJTIwJUU4JTg0JUIxJUU1JTg4JTlEJUU3JUI0JTlBJUVGJUJDJTgxJUU4JUFBJUE0JUUzJTgyJUIzJUUzJTgzJTlGJUUzJTgzJTgzJUUzJTgzJTg4JUUzJTgxJUFGJUUzJTgyJTgyJUUzJTgxJTg2JUU2JTgwJTk2JUUzJTgxJThGJUUzJTgxJUFBJUUzJTgxJTg0JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1iNGJhNjdiYzI1Yzk2N2U2YWU0ODQwNzhjY2ZjOWNhOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBmb3Jlc3QxJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MDg1MmFmNjQ3MDk1ZDM2N2JjNWE1ODlmNzNmYWI3Yw%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D140b25ae618e3bee9833d64d2c5b4989)
GitHubを使うなら最低限知っておきたい、プルリクエストの送り方とレビュー、マージの基本
本連載「こっそり始めるGit／GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回の記事「これでもう怖くない、Git／GitHubにおけるリモートリポジトリの作成、確認、変更、更新時の基本5コマンド」では「リモートリポジトリ」に対する基本操作を解説しました。 連載第10回目の本稿では「プルリクエスト」の基本機能や手順について解説します。 本稿で解説する作業は、前回の記事で作成したリポジトリをベースに進めていきます。リポジトリを作成する作業をまだ行っていない場合は、前回の記事を読みながら準備を進めてみてください。 プルリクエスト
やさしいGitの内部構造 - yapcasia2013
Presentation slide of my session of Groovy at JJUG CCC 2015 Spring Amazon SageMaker is a fully managed service that enables developers and data scientists to build, train, and deploy machine learning (ML) models quickly. It provides algorithms, notebooks, APIs and scalable infrastructure for building ML models. Some key features of SageMaker include algorithms for common ML tasks, notebooks for de
超絶便利なGitクライアントのtigのすすめ - Qiita
mainビュー m mを押すとmainビューが表示されます。 tigの起動時にも表示されるビューです。いわゆるgit treeのビューです。 enterでそのコミットの詳細を見れたり、C(shift+c)でcherry-pickしたりできます。 statusビュー s sを押すとstatusビューが表示されます。git statusのビューです enterでファイルの変更内容を見れたり、stage/unstage(add/reset)をしたりできます。 refsビュー r rを押すとrefsビューが表示されます。branch, tagsなどが一覧されます。 enterでmainビュー(git tree)が見れたり、C(shift+c)でcheckoutしたりできます。 logビュー l lを押すとlogビューが表示されます。git logです。 enterでそのコミットのdiffが見れたり
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
ローカルで作ったリポジトリをgithubに初めてpushする方法 2013-05-05 - 未来のいつか/hyoshiokの日記
例えば以下のようにローカルにgitで管理していて、ふとgithubあたりで公開したくなったとする。はじめからgithubにレポジトリを持っていた場合は、それを $ git clone して、ローカルでごにょごにょして $ git push すればいいのだけど、その順番が逆の場合。 $ git init $ git add . $ git commit -m "initial commit" ... ここで、あー、githubにpushしたいなーとふと思う。 おもむろにgithubにsign inしてrepositoryをnewする。仮にユーザ名がuser-nameでリポジトリがrepositoryというのを作ったすると、ローカルからのpushは下記のような感じになる。 $ git remote add origin git@github.com:user-name/repository 最
個人的なXcode用.gitignore – LexTech
こんにちは、mitoです。 先日ヴィエナコーヒーというものを初めて飲みました。みなさんヴィエナコーヒーをご存知でしょうか? コーヒーの上に甘いクリームがのったやつです(実際はもう少し記述すべき特徴はあるのでしょうが、とりあえずつたない描写でご勘弁ください)。 はじめは白と黒のモノトーンが綺麗に分離していて、それはそれでミニマムな美しさがありますが、時間が経つにつれて次第にクリームが溶けてミクストされたコーヒーになっていく姿を見ると、2度おいしい気分になりますね。 とそんなどうでも良い前置きからはじまりましたが、本題です。私が日頃使用しているXcodeのgitignoreを公開致します。 .DS_Store *.swp *~.nib build/ # Xcode project files except for the project file #*.xcodeproj/* #!*.xcod
Xcode プロジェクトをうまく .gitignore する - ヤルキデナイズドだった
2015年11月9日追記：以下の内容は Xcode 4 までに対応しています。最近の Xcode に対応するには github.com/github/gitignore の Objective-C.gitignore を使うことをお勧めします。（追記終わり） Xcode で作ったプロジェクトを Git で管理するにあたってめんどくせえーのは、 .xcodeproj の中にプロジェクトのデータとユーザデータが一緒に入ってる点です。普通に空のプロジェクトを作るとこうなります： Xcode 3: - $PROJ.xcodeproj/ - project.pbxproj - $USER.mode1v3 - $USER.pbxuser Xcode 4: - $PROJ.xcodeproj/ - project.pbxproj - project.xcworkspace/ - xcuserdata/
gitの使い方メモ - メメメモモ
githubを使い始めたので、gitについての使い方メモです。 gitをインストールしたところからの作業になります。 初期設定 コミットした時などに表示されるユーザ名とメールアドレスを設定します。 $ git config --global user.name "memememomo" $ git config --global user.email "memememomo@gmail.com" また、コマンドからの出力を読みやすくするために、color.ui設定をautoにします。 $ git config --global color.ui auto 以上の設定は「$HOME/.gitconfig」ファイルに記述されます。 $ cat $HOME/.gitconfig [user] name = memememomo email = memememomo@gmail.com [colo
K8 カジノ - 「K8 カジノ」で勝利の興奮を味わおう！最高のゲームと魅力的なボーナスが待っています。リアルなカジノ体験を楽しんで、夢の一獲千金を目指そう！
The Best Fluffy Pancakes recipe you will fall in love with. Full of tips and tricks to help you make the best pancakes.
操作体系から見る、GitとMercurialの8つの違い
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】