【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
Gitblit 試した - 2012-04-17 - marsのメモ
世界のymnkさんのつぶやきで知ったのだけれど，GitblitというオープンソースのGitリポジトリ管理ツールがあったので試してみたよ。 んで，そのGitblitってのが，これ。Javaでできてる。 What is Gitblit? Gitblit is an open-source, pure Java stack for managing, viewing, and serving Git repositories. It's designed primarily as a tool for small workgroups who want to host centralized repositories. http://gitblit.com/index.html サーバ型のツールなので，warファイル（Gitblit WAR）かTomcat付きのスタンドアロン版（Gitblit
Git Legit
gitleg Comments Off on Mengenal 3 Fungsi Utama Penggunaan Bahasa Pemograman Pada GIthub Untuk Para Developer Mengenal 3 Fungsi Utama Penggunaan Bahasa Pemograman Pada GIthub Untuk Para Developer Mengenal 3 Fungsi Utama Penggunaan Bahasa Pemograman Pada GIthub Untuk Para Developer – Github merupakan jenis website yang bisa digunakan dalam menyimpan serta mengelola suatu kode pada suatu produk. Anda
エンタープライズ向けGitのWebフロントエンド·KoshiNuke MOONGIFT
KoshiNukeはGitを企業内で用いる際に使えるアプリケーションライフサイクルマネジメントシステムのモックアップです。 Gitが徐々に企業でも利用されるようになっている中、Gitをベースにしたアプリケーションライフサイクルマネジメントが求められるようになっています。そこでモックアップとして紹介したいのがKoshiNukeです。 コードをダウンロードした場合の表示です。 デモ阪の画面です。格好いいです。 リポジトリの履歴です。 コードツリーも表示できます。 コミットログです。個々のコミットログ詳細は見られませんでした。 ブランチグラフです。GitHubと違って縦に進んでいきます。 Wikiは編集機能が備わっています。 Wikiの編集履歴です。 KoshiNukeはあくまでもモックアップなのでビューのみですが、それでも十分に便利そうな機能がそろっているのが分かります。後はバックエンドをRE
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
gitだからこそできるチケット駆動開発のやり方 - kunitの日記
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
Git Log in Calendar View
For those interested, here’s how I made the git logs into the calendar view in the previous excuse-ridden post on why edgeyo‘s development has been slow the past 1.5 months. Thehe git log is piped into a csv file: xuanyi@gallifrey:~$ git log master --date=short --pretty=format:"%h%x09%an%x09%ad%x09%s" > edgeyoCommitLog.csv Here’s what the csv looks like A table of commit counts is created with Exc
コマンドラインから今いるgitレポジトリをSourceTreeで開く | MemeTodo
2012年1月6日金曜日 コマンドラインから今いるgitレポジトリをSourceTreeで開く タイトルままですが、コマンドラインからSourceTreeを開く方法 open -a SourceTree /path/to/repo のような感じで、SourceTree.appで指定したレポジトリを開く方法は知っていたのですが、 わざわざ開きたいレポジトリのルートを指定しないと行けないのが面倒でした。(大抵そのレポジトリ内にいるので) How do I open a repository in SourceTree from the commandline (CLI) ? - Atlassian Answers gitレポジトリのルートとなるディレクトリを取得する方法もあるようなので、それを入れて # sourceTree alias st='open -a SourceTree `git
Gitリポジトリに蓄積された歴史を可視化、グラフ化する·GitStats MOONGIFT
GitStatsはGitリポジトリを解析して静的なHTMLファイルとグラフを出力するソフトウェアです。 Gitにaddしてcommit、addしてcommit…そんな日々の努力の結果をビジュアル化してくれるソフトウェアがGitStatsです。社内プロジェクトで使ってみても面白そうです。 supybotのGitリポジトリから作られたHTMLです。 アクティビティです。コミット数などをグラフ化しています。 時間数が出たりするのも面白いです。 コミット数を見ればプロジェクトの栄枯盛衰が分かります。 タイムゾーンごとのコミット数もユニークです。 開発者の一覧です。 ファイル数のカウントです。 拡張子ごとというのも面白いです。 コードの行数です。 タグ一覧です。 GitStatsはアクティビティ、ファイル数、コード数、タグ、開発者と言ったデータをリポジトリから抽出してグラフ化します。静的なHTMLで
GitHubでプルリクエスト用ブランチを保守するメモ - なんたらノート第三期ベータ
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
GitHub Flow – Scott Chacon
Issues with git-flow I travel all over the place teaching Git to people and nearly every class and workshop I’ve done recently has asked me what I think about git-flow. I always answer that I think that it’s great - it has taken a system (Git) that has a million possible workflows and documented a well tested, flexible workflow that works for lots of developers in a fairly straightforward manner.
New community features for Google Chat and an update on Currents
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
[git] branch名に、チケット番号仕込むと、良い事あった。 - こいばな - riskriskと時々鼻メガネ -
本日、ちょこっとつぶやきで、 gitのブランチ名にチケット番号を仕込んでおくと、コミットログ書く時に確認しに行かなくてすむ。— ｒｉｓｋ - 鼻メガネさんさん (@riskrisk) 1月 18, 2012 っていったら、神様から @riskrisk も一歩進んで、チケット番号をコミットログに自動的に埋め込んじゃうようにしませう！— 残念なbleis(実際残念)さん (@bleis) 1月 18, 2012 って言われたので、やってみることにした。 最初は、gitのソース追わないとダメかなぁと思ってたけど、 このブログの名前つけた人から @bleis @riskrisk masterブランチへのコミットを拒否、かー。ツールがチケット駆動開発を加速させますね。すばらしい。github.com/bleis-tift/Git…— Takayuki KONDOさん (@cointoss1973)
![[git] branch名に、チケット番号仕込むと、良い事あった。 - こいばな - riskriskと時々鼻メガネ -](https://cdn-ak-scissors.b.st-hatena.com/image/square/87e620cde860b48a7961bb55d0505b841f63d8c1/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729910136%2F12704346814673886493%2F1326904249)
GitLab
1. Keep your source code at your server! Your own lite app for projects/repositories hosting on your server. Fast, secure and stable solution based on ruby on rails. 2. Use Git! We use git as version control system for projects 3. Browse source-code, issues, comments. Manage team access to repository
GitHubでgitflowを使う - maoeのブログ
gitflowが便利で気に入っています。人のプロジェクトをforkしたときは、どういう流れで使えばいいのかまとめている文書が見つからなかったので書いておきます。 プロジェクトをfork 手元にclone upstreamの登録など git flow init git flow feature start XXXX いい感じに編集 git commit git flow feature publish XXXX GitHubのSwitch branchesからXXXXを選択 Pull requestボタンを押してリクエスト送信 レビューされる 取り込まれたらgit flow feature finish XXXX 僕は先日featureブランチをfinishしてからpull requestを送ってしまいまったんですが、GitHubのヘルプにはpull requestはトピックブランチからやれ
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
Route 477(2011-09-08)
■ [git] どの段階で混入したのか全く分からないバグが発生したので、git bisectを使ってみた 気づいたら、BiwaSchemeのmakeが通らない状態になっていた。 java -jar bin/yuicompressor-2.4.2.jar lib/biwascheme.js -o lib/biwascheme-min.js [ERROR] 16082:51:invalid property id [ERROR] 1:0:Compilation produced 1 syntax errors. 数日前までは通っていたんだけど、それから結構な回数コミットを行ったので、どれが原因なのか分からない。 でも大丈夫、こんな時こそ(存在は知っていたけど使う機会のなかった)git bisectを使うチャンスだ。 git bisectは、「OKなコミット」と「NGなコミット」の2点の間を二分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
visionmedia's git-extras at master - GitHub
Gitifier: Git commit notifier for MacOSX
Git pre-commit hooks and the Clang Static Analyzer — Fraser Speirs