Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖いHPC
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
プロとしての行為 Act as Proffesional
Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
