An interactive Git visualization tool to educate and challenge!
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
git rebaseについてのtips | けーこ in サンフランシスコ
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
■ - hitode909の日記
コミットメッセージちゃんと書こうっていうの，まあそうだけど，どれくらいちゃんとしたらいいか，よくわからない． たぶん，コード読んで分からなかったらコメント読んで分からなかったらコミットメッセージ読んでわからなかったら社内Wikiとか検索しまくるみたいな感じだと思う． コードとコメントは普通にファイル開いたら読めるから，そこで分かるようになってれば，コミットメッセージ適当でいいと思う． GitHubとか使ってレビューするなら，コミットメッセージが全面に出てくるから，作業の説明をまとめる変わりに，コミットメッセージ読んでください，くらいで済むと思う． けど普通のソフトウェアを理解しようというときに，コミットメッセージをめちゃくちゃ利用しようということはあまりなくて，困ったときに読むみたいな感じだと思う． コミットというのは変更であるから，変更の理由とか事情を説明をして，コードそのものはコミット
英語でコミットを書こう
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
コミットの粒度 - プログラマの思索
コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。 【元ネタ】 git commit するまえに考えるべき10のこと | Act as Professional - hiroki.jp by HIROCASTER 「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組 GitやMercurialがCVSやSVNよりも優れている点は、ブランチ管理の容易さと豊富なマージコマンド。 特に、ローカルにブランチを作り、プライベートなブランチとして開発者は好き放題にコミットすればいい。 そして、masterに最終的にコミットする時、必要なパッチのみまとめて送ればいい。 コミット履歴を改変する必要があるのは、masterのコミット履歴を綺麗にする場合だろう。 ローカルのブランチは自分だけが好きなようにコミットしてもいいが、masterのコミット
git flow でのチーム開発ワークショップ資料 - Yamashiro0217の日記
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
Lightweight git hook management tool その名も git-hook を作りました - 鳩舎
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
死んで覚える本当のGitの使い方 - mizchi log
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
レビューに便利な git alias 作った « blog.udzura.jp
git run-features-jhw HEAD~5 #=> spec diff between HEAD~5..HEAD # spec/models/hoge.rb # spec/controllers/fuga_controller.rb # ..... git alias tips ! pwd とかってやると、どこで実行してもリポジトリのルートで実行したことになってるのが分かる（サブディレクトリごとにプロジェクトを作ってる場合に注意） !head=${1:-HEAD~} sh -c ... みたいにやんないと上手に $1 が渡んない（内部で $head は問題なく参照できる）。zshだから？ zsh はリダイレクト先を複数指定できて、ruby -pne \"STDERR.puts \\$_\" | は cat 2>&1 | で済んで凄い。参考 git diff --name-onl
Set up Git - GitHub Docs
Using Git To use Git on the command line, you will need to download, install, and configure Git on your computer. You can also install GitHub CLI to use GitHub from the command line. For more information, see "About GitHub CLI." If you want to work with Git locally, but do not want to use the command line, you can download and install the GitHub Desktop client. For more information, see "About Git
A Rebase Workflow for Git | RandyFay.com
Update October, 2014: Lots of things have gotten easier over the years. These days, the easy way to fix this set of things is with the Pull Request workflow, which is essentially the Integration Manager workflow discussed here (probably). Use github or bitbucket or somebody that makes the PR workflow easy Delegate a person as integration manager, who will pull or comment on the PR Require contribu
Linus「C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる」
/15 [4] (21:54) 原文: http://lwn.net/Articles/249460/ From: xxx To: xxx Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST) Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Git のソースコードを最初に見たとき、ヘンだと思ったこと: > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、 > そんなのウソに決まってるから。 *あんた* のほうこそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Log in with Atlassian account
gitのコミットログなんて"fixed"だけで十分だろ！エンジニアならコード読め！ - hogehoge @teramako
powerful-code.com-蒙城县郭侠熟食有限责任公司-网站
良い Commit Messageを書きましょう(翻訳)
Git Flow Setup
GitHub - lolcommits/lolcommits: :camera: git-based selfies for software developers
