Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
プロジェクトのGitサーバをWindows機で構築する機会があったので、簡単に手順をまとめておきます。 通常はLinuxで構築することが多いと思いますが、今回はプロジェクトの制約でWindows機を使うことになりました。 ここで紹介する手順は、小規模な社内環境を想定していますので認証、セキュリティは考慮していませんが、「最小の構成でよいから手軽に構築したい」といった場面でのご参考にしていただければと思います。 環境 インストール 共有リポジトリの作成 外部接続の設定 接続確認 1. 環境 今回、構築する環境は以下のとおりです。 共有GitリポジトリはWindows機上に構築 GitにはmsysGitを用いる 共有Gitリポジトリとの接続はgitプロトコルを用いる クライアント側のGit環境は構築済みとする 接続にgitプロトコルを用いることで、SSH鍵等の準備する手順を削減しています。 2
つい先日、SVNからMercurialに移行するべき8つの理由をまとめたが、Twitterやはてなブックマークのコメントを見ていると、同じ分散バージョン管理システムとしてGitとMercurialとの比較に関心が高く、Windowsでの動作でMercurialを評価する人が多いように感じられた。 それも一つの側面で間違いでは無いのだが、日々の開発作業で使っていくと、むしろ操作体系の方が気になるものだ。GitとMercurialの両方を使う機会があったので、操作体系の面で気づいた違いを列挙した上で、Gitに対するMercurialの優位点を考察してみる。 1. 管理対象ファイルの指定方法 .gitignoreや.hgignoreで管理外のファイル名を指定でき、正規表現も使える点は良く似ている。 しかしGitはcommit前にコミット対象を毎回git-addで指定するが、Mercurialは一
2012-08-20一部訂正 githubにdotfile上げてる人は結構多いですが、 github.tokenなど、一部の設定は公開されると困りますね。 そんなときはincludeディレクティブを使うとローカル用の設定を別ファイルに出来るので捗ります。 [include] path = .gitconfig.local [core] editor = emacs pager = lv whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol excludesfile = .gitignore こんな感じでやると.gitconfig.localを読み込んでくれるので、 github.tokenなどは.gitconfig.localに書いておくといい感じになって捗ります。 参考: http://stackoverflow.com
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
最初のコミットに紛れていた要らん子を歴史から抹消する - 裏紙より。 「最初のコミットだからめんどくさい」と読み取った。つまり、最初のコミットを付け足せれば二番目じゃん! ※思いつきです。実用性なんて知りません。 まず初期状態を作る。 echo a>a echo x>x git add . git commit -m'最初のコミット' echo b>b git add . git commit -m'二番目のコミット' echo c>c git add . git commit -m'私はたぶん三番目のコミットだと思うから' echo d>d git add . git commit -m'四番目のコミット' echo e>e git add . git commit -m'そろそろめんどい五番目' echo f>f git add . git commit -m'六番目' echo g>
gitleg Comments Off on Cara Membuat Interface GitHub yang Interaktif dengan Python Cara Membuat Interface GitHub yang Interaktif dengan Python GitHub adalah platform populer yang digunakan oleh pengembang untuk mengelola dan berbagi kode mereka. Salah satu cara untuk meningkatkan pengalaman pengguna dengan GitHub adalah dengan membuat interface yang interaktif. Dengan Python, Anda dapat memanfaatk
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
Emacsのgitフロントエンド'magit'が便利です。 gitoriousにソースは置いてあります。 http://gitorious.org/magit/mainline 以下紹介記事です。 http://d.hatena.ne.jp/gom68/20090524/1243170341 http://zagadka.vm.bytemark.co.uk/magit/magit.html 僕が利用している細かい便利機能を紹介しておきます。 最近リリースされたものも含みます。 git amend magitの画面から c を押すとコミットメッセージのバッファが表示されますが、そこでC-c C-aを押すと amend状態になって、直前のコミットに差分を追加できます Untrackのファイルも含めてすべてaddする magitのSキーだけだと、Untrackのファイルはaddされないのですが、
GitHub - mhayashi1120/git-emacs: Yet another git mode on emacs for newbies 前から気になっていた git-emacs の使いづらさや不具合を多少でも改善すべく github で fork しました。 今のところ、概ね以下のような変更を施しています。 dired サポート ファイル内にマルチバイト文字を含んだ際の ediff bugfix blame モードの bugfix それにしても、海外産 elisp の coding-system の取り扱いはどれもひどいもんです。そこそこ有名なものであっても、まったく考慮されてないです。最近の環境ならすぐ直せるので大きな問題じゃないのですけどね。 ヨーロッパは文字化け問題が日本よりひどいという噂を聞いたのですけど Emacs ユーザが少ないのでしょうか。英語圏のプログラマなら
git-diff-grepはGitリポジトリの指定回数分の過去のコミットDiffの中から検索できるツールです。 Gitは自分のローカルにリポジトリがあるので何かリポジトリ操作をしたい時にも高速に行えるのが便利です。現在のコードにはない内容を検索するときに使えるのがgit-diff-grepです。 インストールはGitHubからcloneしてファイルに実行権限を付与してパスの通ったところに配置するだけです。 実行例です。履歴の差分からGrepしています。 そのままだと日本語が文字化けしてしまうのが難点です。 ヘルプです。検索するコミット数を指定します。 git-diff-grepを使うと過去の差分から検索してくれるので、以前に誤って削除した情報を探すのが楽になりそうです。 git-diff-grepはBashスクリプトで作られたソフトウェア(ソースコードは公開されていますがライセンスは明記さ
(本記事は @suer, @mallowlabs, @mzp がノリノリで共同執筆しました!) 近代的なソフトウェア開発に必要なツールは3つある。 分散バージョン管理ツール ITS CI ツール 私はこれに AsakusaSatellite (以下AS)を加えたいと思う。 以上の4ツールを使用することによって、迅速なコミュニケーション、洗練された自動化をベースとした開発リズムを体験することができる。 このあとの節では具体的なユースケースをベースに、上記ツールの連携方法及びそのメリットをみていく。 ユースケース:開発中にソースコードの特定行で例外が発生した原因を探る ここは codefirst の開発室。 @suer と @mallowlabs と @mzp はリズム良くコードを書いています。 そんなとき、ビルドの異常を知らせるポップアップが表示されます。 さっそくAS 上でミーティングがは
隣の人がバリバリ働くので僕が暇そうにしていると「仕事するか開発環境を整えるかどちらかやれ」と言われたのでRedmineのプラグインを書きました。 Redmine リポジトリインクリメンタルサーチプラグイン Redmine のリポジトリ閲覧機能は目的のファイルに辿りつくのにとても苦労します。特にJavaなんかで jp > co > ... なんてやってると途方に暮れてしまいます。 会社ではコードレビュープラグインを入れて、レビューコメントを入れたりするんですが、上記の理由でとてもイライラします。 そこで、目的のファイルにショートカットするためのプラグインを書きました。 例によって、世界のどこかには同じプラグインがあるかもしれない。。。 リポジトリ https://github.com/suer/redmine_incr_code_search 機能 ファイル名をインクリメンタルサーチします。
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Note: On July 30th, the post-receive’s JSON will change. See before and after examples further down the page. If you supply a post-receive URL, GitHub will POST to that URL when someone uses git push on that repository. What we’ll send is JSON containing information about the push and the commits involved. Here’s the template we use in Ruby to generate the JSON: { :before => before, :after => aft
Setting Up Tell git your user name and email address Providing your SSH Key Addressing authentication problems with SSH How to not have to type your password for every push How to clone from github with ssh tunnels Working with git Git Screencasts Git Podcasts Git for Mac Compiling git on OS X Leopard Get git on Mac Setting up a remote repository using GitHub and OSX Issues with TextMate set as gi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く