Windows用のSSHの設定 EGitを使ってGitHubにアクセスする為に、SSHの設定が必要になる。[2012-03-04] Cygwin上でssh-keygenコマンドを使ってSSHの鍵を作った場合、「D:\cygwin\home\hishidama\.ssh」の下にid_rsaやid_rsa.pubといったファイルが作られているはず。 この鍵がそのまま使える場合は環境変数HOMEは「D:\cygwin\home\hishidama」にしておけばいい。 というのは、現状では、パスフレーズありの鍵だと上手く動作しない(パスワードを入れても認証がはじかれる)為。 (Eclipse3.7のSSH2はAESに対応していない為らしい。→ang65さんのEclipseのEGitで既存のSSHのprivate keyが使えないときの解決策、eclipse BUGSのBug 326526 - eg
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
さて、まったくブログを更新していないtfmagicianです。 こんにちは。 先月は1記事しか書いてないですね。今年は月10記事以上を目標に、楽しみながら書いていきます。 今日は、Gitをネタに取り上げます。 前回はプロジェクトに関するGitネタでしたが、今回は個人的なモノ。 Gitと一緒にCakePHPを楽しむ – CakePHP Advent Calendar 2010 6日目 あなたの宝物が詰まったホームディレクトリをGitで管理してみます。 ホームディレクトリの”なに”を管理するか これは人によって異なります。 例えば、あなたがMac使いで、Mac上でGitを使うというなら、ドキュメントも管理したくなるかもしれない。 例えば、あたながLinux使いなら、設定ファイルだけGitで管理出来れば良いかもしれない。 .gitignoreをうまく設定出来れば、どちらのパターンも対応出
Git for windows 1.7.10 ダウンロード http://code.google.com/p/msysgit/downloads/list TortoiseGit 1.7.5.0 unicode対応 ダンロード http://tortoisegitjapan.com/install-tutorial-01/ 追記 設定 Git\etc\inputrc set meta-flag on set input-meta on set output-meta on set convert-meta off set kanji-code utf-8追記 set kanji-code utf-8 は必要。 文字化けしてたのは、フォントの設定とおもわれる。 Git\etc\profile alias ls='ls --color=auto --show-control-chars' gi
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット?ジット?俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの?なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは?と思い、 今回はgit入門の入門、gitってなんだ?というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに? プログラムを書いていて、こんなことありませんか?私はあります…
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
INDOSPORT99 adalah platform slot gacor har ini yang sudah lama dikenal dan dipercaya oleh para pemain yang gemar bermain slot online, terutama bagi mereka yang mengincar kemenangan besar yang pasti dibayarkan. Untuk bergabung, pemain hanya perlu mendaftar akun di situs slot ini. INDOSPORT99 juga telah bekerja sama dengan berbagai provider terkenal seperti Pragmatic Play, PG Soft, Slot88, Habanero,
2011/05/12のブログで.gitconfig を晒した後に増えたエイリアスを少し解説。 最新の.gitconfigはgithubのsinsoku/dotfilesに置いてある。 git ft ft = fetch -n --pruneタグは後述するfttで取得するため、-n(--no-tags)を設定している。 また、削除されたリモートブランチは自動的に削除するために、--pruneを設定している。*1 git pl pl = pull --no-tagsタグは後述するfttで取得するため、-n(--no-tags)を設定している。 普段はftを使うので、ほとんど使わない。 git ftt ftt = fetch -n --prune origin refs/heads/*:refs/remotes/origin/* refs/tags/*:refs/tags/origin/*自分が
「Git」使ってますか? 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
github 超入門という記事を以前書いてからずいぶん経っていますが ここ最近になって続きはまだ?とか、いい加減 github にアップさせてくださいといった声をもらうようになったので 重圧に耐えかねて「もうちょい入門」を書いてみようと思います。 新 MBA が出て Win から Mac に乗り換えたり、サブマシンとして用意した人々が これを機会に開発環境を一新する or 整えようの一環として、 git を導入しようと考えている人が多いのかなーと野暮な勘ぐりをしてニヤニヤしてみたり。 前置きはこの辺にして、本題に入っていこうと思います。 冒頭でも述べましたが、今回は github へアップするところまでやってみたいと思います。 まず github にアップするためには、前提として github のアカウントが必要になります。 github のアカウント作成方法については、
This document summarizes the key differences between centralized version control systems (CVS) and distributed version control systems (DVCS). It explains that DVCS allow for non-linear development with features like rebasing and branching that are not possible in CVS. Examples of DVCS like Git and Mercurial are given. The document also discusses how to migrate from CVS to a DVCS and advantages of
Mercurial for Git users Git is a very popular DistributedSCM that works very similarly to Mercurial. Both are built upon such similar concepts that most repositories can be converted to and from Mercurial and Git without any significant data loss! There are, however, significant design and conceptual differences that may cause trouble when coming from Git to Mercurial. 1. High-level Comparison Mer
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く