Git
The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com. The version found here has been updated with corrections and additions from hundreds of contributors. If you see an error or have a s
git-bigfiles – Caca Labs
git-bigfiles - Git for big files git-bigfiles is our fork of Git. It has two goals: make life bearable for people using Git on projects hosting very large files (hundreds of megabytes) merge back as many changes as possible into upstream Git once they’re of acceptable quality Features git-bigfiles already features the following fixes: git-config: add core.bigFileThreshold option to treat files la
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
人様の git リポジトリを milkode で簡単に管理するインタフェース「gitomb」を作った - tomykaira makes love with codes
tomykaira/gitomb Milkode は数万のファイルでも軽々動く、ソースコード検索エンジンです(製作者は id:tuto0621 さんです）。 しかし、数万ファイルもあるリポジトリなんて管理しますか?普通。 ソースコードを検索する回数がもっとも多いのは、既存のライブラリの使い方がよくわからないときに、ドキュメントに乗っているメソッド名を手掛かりに検索して、望みの機能を発掘していくような時のはずです。いままで、ライブラリのコード検索をしようとおもったら、 ライブラリを落としてくる そのディレクトリに移動する git grep かなんか ヒットしたファイルをエディタで開いて、まわりを見回す 見付かるまで検索をくりかえす みたいなことをやっていました。milkode web を使うと、次のようになります。 ライブラリを落としてくる そのディレクトリに移動する milkode
Simple, Flexible, Trustworthy CI/CD Tools - Travis CI
language: python python: - "3.7" - "3.8" - "3.9" # Command to install dependencies install: - pip install -r requirements.txt - pip install pytest pytest-cov # Command to run tests script: - pytest --cov=./ tests/ # Specify branches to build branches: only: - main - develop # Cache pip dependencies cache: pip # Run jobs in parallel jobs: include: - name: "Lint" python: "3.9" before_script: - pip i
master ブランチで pull request してもいいのは覚悟のあるヤツだけ - ヤルキデナイズドだった
GitHubへpull requestする際のベストプラクティス master ブランチで pull request していいのは小学生までってこともない このへん読んでて思ったことです。 master から pull request して reject されたとしましょう。この master は上流の master と食い違ったままになります。 しかし、自分のブランチと上流の同名のブランチは一致しているか、自分のブランチのほうが進んでいる状態にあると面倒事がなくて好ましいです。食い違った master をふたたび一致させる手段は2つ： さらに master を変更して再度 pull request し、どうにか merge してもらう master に変更を加える前のコミットを強制的に push し、 master のコミットをなかったことにする 1つ目の手を取るなら、なんとしても pu
git で過去コミットを修正する
Git でバージョン・コントロールをしていて、時々、古いコミットで入れてしまったバグを見つけることがある。その解決方法。 本エントリーの内容は、Git ユーザマニュアル (バージョン 1.5.3 以降用) のほとんどコピーと言っていい。このマニュアル大き過ぎる。すぐにバグ修正したい時に、肝心の部分へ辿りつくのが大変。なので、自分用のエントリーにしてみる次第。 下調べ バグのあるコミットは、どこかの集中リポジトリーに git push されていないこと。もし、git push されていると、整合性が取れなくなるので、この作業はしないこと。その場合は、素直にリポジトリーのヘッドにバグ修正のコミットを追加する。 前提 バグは、トピック・ブランチ new-feature の中で入れたこととする。 バグを入れたコミットのハッシュ値は 123456789... とする。 ハッシュ値は gitk もしく
Github の README ファイルを wiki 書式で書く
github にプロジェクトを登録したら、README ファイルを用意しておくと良い。すると、github はそのプロジェクトのトップページに、その「README」ファイルの中身を表示する。初めてそのプロジェクト・ページにアクセスした人は、README ファイルを開かずに概要を知ることができる。プロジェクトを公開する側も、使おうと考えている側にとってもメリットは大きい。 一般に README ファイルはテキスト・ファイルで用意してやれば良い。 しかし、中には README ファイルも HTML の様に「綺麗」に表示されることを望む人も居ることと思う。URL があれば、それがリンクになることを望むことと思う。ヘッダーは大きな文字で表示される方が嬉しかろう。 そんな人のために、github は wiki の書式を README に入れる仕組みを用意している。 README に wiki 書式を
Git ユーザマニュアル (バージョン 1.5.3 以降用)
(訳注：この資料は、http://www.kernel.org/pub/software/scm/git/docs/user-manual.html に掲載されている 内容を日本語訳したものです。 英語が得意でないので、誤訳があるかもしれません。 必要な場合は、原文を参照してください。) git は高速な分散リビジョン管理システムです。 このマニュアルは、基本的な UNIX コマンドのスキルをもった人が読むことを想定していますが、 git に関する前提知識は必要ありません。 Chapter 1, リポジトリとブランチ と Chapter 2, 履歴の探索 では 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する際は、
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
Git入門 ゼロから始めるGitドリル
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm（Git Hosting参照）にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bitbucketの使い方
Hi! I cleaned up your code for you! by GunioRobot · Pull Request #231 · mojolicious/mojo
An Interview With Linus Torvalds: Linux and Git - Part 1 30 Years Of Linux
GitHub Learn: Your Personalized Learning Experience
削除したファイルをgit rmするコマンド - t-taira blog
Github上のPerlソースからpod2htmlするブックマークレットだよ- jamadam weblog2
cpanm-github at master from tokuhirom's toktools - GitHub