ローカル作業でのgitリポジトリ管理とコーディング環境の話 - すずけんメモ
gitを改めてちゃんと使おうという人がまわりで増えてきたのでメモとして貼っておく。 現状の設定はこんな感じ。1年くらい変わってなかった。 https://github.com/suzuken/dotfiles/blob/cbf8e7168c96029d535d69f981337d23aacfa51c/gitconfig 特にaliasまわりは普段つかっているのであげておく。 [alias] # http://oli.jp/2012/git-powerup/ # http://blog.blindgaenger.net/advanced_git_aliases.html alias = !git config --list | grep 'alias\\.' | sed 's/alias\\.\\([^=]*\\)=\\(.*\\)/\\1\\\t => \\2/' | sort b = b
Git で過去にさかのぼってタグ付けする (git tag) - 肉とビールとパンケーキ by @sotarok
もうだいぶ歴史を進めて開発進めてたんだけど、そういやあのプロトタイプが動いたときタグうっときゃよかったなーなどと思ったんだけど、意外と情報がなかったからメモ。 git-flow 使って、develop で開発進めてたりして、リモート/ローカルで push/pull も頻繁にしてるリポジトリ。現存するのは、develop, master のみ、だいぶ昔に feature/hoge からマージした段階に戻って master にマージしてタグ付けしたい、みたいな要望（割とあるよね？あるよね？ $ git log --all --graphとか見ながら、コミットオブジェクトのハッシュ確認。例えば、「38fef39」が対象のコミットだとする。 そのハッシュをチェックアウト。 $ git checkout 38fef39 Note: checking out '38fef39'. You are in
GitHub を用いた開発フロー テンプレート - ペパボテックブログ
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope
git と mercurial の diff を美しく表示するために必要なたった 1つの設定 (原題: diff-highlight 1.0.0 をリリースしました) - Hack like a rolling stone
Git の diff を美しく表示するために必要なたった 1 つの設定 #git にインスパイアされて作り始めた diff-highlight にあれこれ手を入れ、1.0.0 として正式リリースしました。 diff-highlight と git-contrib/diff-highlight の違い 差分の中で +/- の行数が一致していないときのハイライトの扱い git-contrib/diff-highlight での表示 +/- の行が一致していないとハイライトされません。 diff-highlight では、マッチする行を認識してハイライトします。 +/- の行数が一致しても、文字単位でのハイライトをしてくれないケースがある git-contrib/diff-highlight での表示 差分の 1行目同士を比較しているため、pager の行がハイライトされていません。 diff-
Gitの驚愕の真実：1億行のファイルに1行追記するとレポジトリ容量が200MB増える[※補足あり] · DQNEO日記
１億行のファイルに１行追記するだけでレポジトリ容量が２倍になった 以前の記事「Gitレポジトリはパッチの集積ではなくてスナップショットの集積である。」を確認するために、１億行のファイルを作って実験してみました。 結果は、なんと１行追記しただけでレポジトリ容量が200MB増加し、サイズが２倍になりました。 実験手順 空のレポジトリを作る １億行のファイルを作ってgit addしてgit commit コミットする そのファイルに１行だけ追記してgit addして git commitする 空のレポジトリを作る $ git init １億行のファイルを作る １億行のファイル(１から1億までの数字が書かれたファイル)を作ります。 $ seq 1 100000000 > numbers.txt この時点で、ワーキングツリーとレポジトリ容量を調べてみます。 $ ls -lh 合計 848M -rw-
![Gitの驚愕の真実：1億行のファイルに1行追記するとレポジトリ容量が200MB増える[※補足あり] · DQNEO日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f7de7c0278993661a11fbc3637f96292ba773aa/height=288;version=1;width=512/http%3A%2F%2Fdqn.sakusakutto.jp%2Fimages%2Fkali.jpg)
tech.Uni-Q | ［デザイナー向けGit解説］ エンジニアと同じブランチで作業する日
前のGit解説の続き。 Gitでは色んな作業の仕方があります。 デザイナーとエンジニアの間でよくある作業の流れをイメージ描きつつ説明してみようかと。 今回は「エンジニアとデザイナーが同じブランチで作業する」です。 まず朝出社！ 今日は検索ページを作るお仕事をすることになりました。 このイメージにそって説明してみます。 イメージ内：P-1 エンジニアがみんなの場所（remoteとか呼ばれてるところ）から最新の「master」ブランチを持ってきて… そこから「search」というブランチを作りました。 イメージ内：P-2 エンジニアは「search」というブランチで、検索フォームのあるページを作成しました。 デザインはまだ入ってません。 イメージ内：P-3 エンジニアは「git push」というコマンドで みんなの場所remoteに「search」ブランチを置きました。 だいたい14時くらい！
Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
pull request を利用した開発ワークフロー
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
git rebaseを使うときのルール | Yakst
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
GitHub初心者はForkしない方のPull Requestから入門しよう // qnyp blog
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
bat365旧网址bat365旧网址首页-bat365旧网址首页
2023年4月26日上午，鸿远电子创新中心暨企业总部项目奠基仪式，在丰台科技园东区三期1516-53地块隆重举行。中关村科技园区丰台园工委副书记、管委主任赵春丽，管委办公室主任杨绮伟、规划建设处处长贾岚等领导出席活动；鸿远电子副董事长郑小丹、董事会秘书邢杰、财务总监李永强、副总经理刘利荣、监事会主席陈天畏、董事长助理盛海等公司领导和员工代表，以及项目施工、监理、造价单位的领导及代表等参加了本次奠基仪式。在喜庆热烈的气氛中，公司领导与现场嘉宾一起手握金铲，挥锹培土，共同为项目奠基，见证这一难忘的历史时刻。 鸿远电子创新中心暨企业总部项目，对公司未来发展具有重要意义。项目建成后，将承载公司高端前沿科技创新、人才引进及总部办公等功能，全面提升企业办公环境及企业形象，吸引更多优秀人才，加快推进企业科技创新与成果转化，进一步增强企业发展新动能。未来，鸿远电子将继续秉承“发展企业，有益员工，服
GitとJenkinsを使ってChefを運用する - GeekFactory
Chefはリポジトリをバージョン管理する仕組みを持っていますが、チームでの協調作業を考えるとバージョン管理システムを使う方が運用しやすいと考えます。本稿では、GitとJenkinsを使ってChefを運用するための1つのパターンを考えます。 以下があることを前提とします。 Chef Server Chef Client Gitリポジトリ Jenkins 基本的な考え方 CookbookをGitリポジトリで管理します。開発者がgit pushすると同時にChef ServerのCookbookが更新されるようにします。これにより、GitリポジトリとChef Serverが同期されるようになります。 また、後続ジョブとして各サーバでChef Clientが実行されるようにします。ビルドパイプラインを組むことで、Staging EnvironmentにおけるChef Client、Producti
綺麗なpull requestを送るための3つのポイント - Qiita
これはGit Advent Calendar / Jun.20日目の記事です。前回は、fukajunさんの変更を一時的に退避！キメろgit stashでした。 この記事ではgithubでpull requestを送る時に私が気をつけていることを共有したいと思います。 私が気をつけていることは次の3つです。 masterにコミットしない 簡潔なコミットメッセージを書く コミットを1つにまとめる この話の前提 以降では、次の2つのリモートリポジトリが登録されている前提で説明します。 upstream: fork元のリポジトリ origin: upstreamからforkされた自分のリポジトリ masterにコミットしない 修正作業は必ず新しいブランチを作ってから行ない、masterブランチはあくまでupstreamの更新を取り込むためだけに使って下さい。 このルールを守らないでpull req
Git リポジトリ同期ツールつくった - Gosuke Miyashita
欠勤してるのにブログを書いていて解雇された、という話があったなー、ということを思い出しながら、このエントリを書いてます。(体調悪くて会社休んだ上に、まだ回復してない。) 最近仕事で GitHub を利用してるのですが、デプロイも GitHub 経由なため、GitHub がダウンしてしまうと、緊急で直さないといけないバグが発生したりすると困るなー、とか、それ以外にも、バックアップリポジトリがあればいろいろ安心かな、ということで、Git リポジトリを同期するツールをつくってみました。 https://github.com/mizzy/gitpusher GitHub の自分のアカウント(または指定された Organization)以下のリポジトリを、すべて Bitbucket に同期する、という動作をします。 今のところ、GitHub から Bitbucket への同期しか対応してませんが、逆
「こわくない Git」というスライドを発表しました - kotas.tech
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Flow (Japanese translation)
git で modified なファイルを抽出して vim で開く - Qiita
GTUG Girls原稿