You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Tip: If you clone GitHub repositories using SSH, then you can authenticate using an SSH key instead of using other credentials. For information about setting up an SSH connection, see "Connecting to GitHub with SSH." GitHub CLI GitHub CLI will automatically store your Git credentials for you when you choose HTTPS as your preferred protocol for Git operations and answer "yes" to the prompt asking i
I followed these instructions to the letter, including the part about password caching. It seems like the instructions are wrong, because every time I git push origin master I get this error: git: 'credential-cache' is not a git command. See 'get --help'. ... at which point I am forced to enter my username and password. After doing so, I am presented with the same error message again, followed by
Git Community Book から、1章2節の The Git Object Model を翻訳。ライセンスは、 GPLv2 。 多くのGit解説本と違い、まずGitの内部モデル解説から入るという、おもしろい構成の本です。人によっては、このほうがわかり易いかもしれません。Gitは差分データを管理していると誤解されることがたまにありますが、それは誤りであるということがこれを読めばわかります。 SHA プロジェクトの履歴を表すのに必要な情報は、いずれも、40桁の「オブジェクト名」で参照されるファイルに格納されている。オブジェクト名は、このような形をしている: 6ff87c4664981e4397625791c8ea3bbb5f2279a3 このような40文字の文字列は、Gitのあらゆる場面で見られる。どの場面で出てくるものであれ、その名前は、オブジェクトの内容のSHA1ハッシュを取るこ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. (英語勉強しないと..) 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 (仕事でDeprecateとか滅多に使わんし) 同僚に聞きつつ10つあげてみた. 以下列挙 (例は実際の同僚やOSS上でのコミットメッセージです.) Add *A to *B AをBに加える
ある案件で, 「エンドユーザーがスクリプトファイルを実行したら, HKCU 配下のレジストリツリーへの書き込みと, クライアントソフトウェアのインストーラーのダウンロードと, インストールの実行がひととおりおこなわれるようにしてほしい」 という要件がありました. 本当は, ウェブページ上のリンクを 1 回クリックするだけで, それら一連の作業がすべて自動的に実行されることを期待されていたのですが, ブラウザーのセキュリティ設定を大幅に緩めることでもしないかぎり難しそうなので, エンドユーザーさんにはせめてスクリプトファイルのダウンロードと実行をおこなうという労力を負担していただくことで妥協することになりつつあります. ちなみに, そういう顧客企業の個別の要望に応じたきめ細かなカスタマイズは日本企業の得意とするところなのかと思いきや, どうも弊社のようなパッケージベンダーの責務らしいというこ
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
Git repositories on chromiumNameDescriptionAll-ProjectsRights inherited by all other projectsAll-UsersIndividual user settings and preferences.android_apksandroid_ndkandroid_toolsangleangle/anglePortable OpenGLaospRepos that are mirrored/forked directly from https://android.googlesource.com/aosp/platform/external/dbus-binding-generator(MOVED) Merged into src/platform2/chromeos-dbus-bindings/ again
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 以下
Yesterday, I posted a question on how to clone a Git repository from one of my machines to another, How can I 'git clone' from another machine?. I am now able to successfully clone a Git repository from my source (192.168.1.2) to my destination (192.168.1.1). But when I did an edit to a file, a git commit -a -m "test" and a git push, I get this error on my destination (192.168.1.1): git push [emai
About passphrases for SSH keys With SSH keys, if someone gains access to your computer, the attacker can gain access to every system that uses that key. To add an extra layer of security, you can add a passphrase to your SSH key. To avoid entering the passphrase every time you connect, you can securely save your passphrase in the SSH agent. Adding or changing a passphrase You can change the passph
備忘録がわりにいつも忘れてしまうgit(git-svn)とsubversionのコマンドの対応表をまとめました。 コマンド対比表 subversion git git-svn 更新 svn update git pull git svn rebase コミット svn commit git add → git commit git commit -a (gitコミット後) git svn dcommit git push <url> 追加 svn add <file> git add 削除 svn rm <file> git rm <file> 移動 svn mv <file> git mv <file> 変更取り消し svn revert <file> git checkout <file> ログ svn log git log 差分 svn diff git diff スイッチ svn
忘れがちなので.. % git checkout-index -a -f --prefix=../hoge/ prefix は末尾に / をちゃんと入れないと悲惨なことになる.
I've been wondering whether there is a good "git export" solution that creates a copy of a tree without the .git repository directory. There are at least three methods I know of: git clone followed by removing the .git repository directory. git checkout-index alludes to this functionality but starts with "Just read the desired tree into the index..." which I'm not entirely sure how to do. git-expo
こうしてみると、 svn と git のコマンド体系は非常に似ていることが分かりま すね。Subversion 使用者は Git を比較的自然に覚えられるのではないでしょうか。 注1 git-init を実行すると、カレントディレクトリに .git というディレクト リが作成されます。 Subversion とは異なり中央集権のレポジトリを作成する必要はあ りません。 cg init を実行したその場所があなたのレポジトリです。 なお、git-init コマンドは以前 git-init-db コマンドでした。 古いバージョンの git の場合は git-init-db コマンドを実行してください。 注2 Subversionはレポジトリがひとつしかありませんが、Git では各個人がレポジトリを所 有しています(もしかしたら一人でいくつも持ってるかも)。 git-commit -a は自分の
svn exportみたいに、ファイルをエクスポートする機能を見つけたのでメモメモ。 例: $ git checkout-index -a -f --prefix=export/ -a 履歴管理されているすべてのファイルをエクスポート。省略した場合は明示的にファイルを指定する 例) $ git checkout-index -prefix=export/ ファイル1 ファイル2 ... -f エクスポート先に同名のファイルが存在する場合は上書きする --prefix エクスポート先 --prefixを指定する場合は、末尾に'/'を付けないと悲惨なことになるので要注意。 次のコマンドの場合 $ git checkout-index --prefix=.merged- Makefile.merged-/Makefileではなく、.merged-Makefileという名前でエクスポートしてしまう
Eclipse EGit™ About This Project EGit is an Eclipse Team provider for the Git version control system. Git is a distributed SCM, which means every developer has a full copy of all history of every revision of the code, making queries against the history very fast and versatile. The EGit project is implementing Eclipse tooling on top of the JGit Java implementation of Git. Andrey Loskutov (Advantest
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く