ある日、 PR の内容を見ずにマージすることを岡島(ピッチャーの)というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね!— そーだい@初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい@初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
Git subtree を使うとリポジトリを他のリポジトリのサブディレクトリとして追加することができます。Git プロジェクトがプロジェクト依存関係を管理する方法はいくつかありますが、これはその一つです。記憶力の良い人は、私が以前に Git submodule の代替の記事でこのコマンドの使用法と利点について書いたことを覚えているでしょう。 Git subtree の基本 それでは git subtree があなたにとって有益かどうかを判断するため、基本を振り返ってみましょう。想像して下さい。あなたは自分の持つリポジトリに外部プロジェクトをいくつか追加したいが、あなたや同僚の日々の利用するものにたくさんのものを追加したくはありません。このような場合に subtree コマンドは役立ちます。 例えば vim 設定を保存しているリポジトリに vim 拡張を追加したい場合はこのようにします: こ
#!/bin/bash # Check arguments if [[ -z $1 ]]; then echo "too few argument" 1>&2 exit 1 elif [[ ! $1 =~ ^(((https?|git)://)?github.com/)?[A-Za-z0-9_-]+/[A-Za-z0-9_-]+(\.git)?$ ]]; then echo "$1: invalid github.com URL" 1>&2 exit 1 fi # Format username/reponame uri="$(echo "$1" | perl -pe "s/^((https?|git):\/\/)?(github\.com\/)?//;s/\.git$//")" username="${uri%/*}" reponame="${uri#*/}" # Destination
gitでは様々な方法でコミットログを書き換えることができます。 その一例として1つのコミットを複数のコミットに分割する方法を紹介します。 問題 先日紹介したgitで複数のコミットを1つにまとめる例ですが、そこでは以下のコミットログを: $ git log -n 4 --oneline --reverse 0000001 Add a neat feature X into the library 0000002 Update to use X 0000003 Fix a typo in X 0000004 Fix a bug in X $ git rebase -i HEAD~4 [detached HEAD b000001] Add a neat feature X into the library 8 files changed, 94 insertions(+), 9 deletion
Emacs上で動作するGitクライアント「Magit」の開発チームは8月15日、最新版「Magit 2.2」をリリースした。多数のコマンドが追加されている。 Magitは、Emacs上でバージョン管理システムGitを操作するためのパッケージ。Gitの主要コマンドをEmacs上から操作できることを目指しており、現時点でもGitユーザーが利用するほとんどのタスクをEmacsから行えるという。 Magit 2.2は7月に公開されたMagit 2.1に続く最新版。6週間に19人から合計321のコミットがあったという。パッケージマネージャELPA(Emacs Lisp Package Archive)で提供される「with-editor」および「magit-popup」パッケージが「async」パッケージに依存するようになり、「async-bytecomp-package-mode」モードを有効にす
ブランチの派生元間違えた!! 本当はdevelopブランチから切らないといけないのに、masterブランチからfeature/hogeブランチを切ってしまった もう3回くらいコミットしてしまった...(´;ω;`)ブワッ ブランチ作りなおしてcherry-pickするか....... こんなとき!! $ git log --graph --all --decorate --oneline * 08733a5 (HEAD -> feature/test) test 1 * e7872a3 (master) master 2 | * 09140ba (develop) develop 1 |/ * 8c001b5 master 1
MagitユーザーマニュアルMagit は、バージョン管理システムGitリポジトリへのインターフェースで、 Emacsへの拡張機能として実装されています。 Magitは、GNU Emacsのバージョン22以降をサポートしています。 それは、他のemacs達も動作するかもしれませんが、Magit開発者は、サポートされていないバージョンで表示されたバグを調査し、修正するつもりは ありません。 でも、他のemacs達のバグ修正パッチや、互換性を維持するボランティア活動は歓迎します。 はじめに謝辞セクションステータス追跡されていないファイルステージングとコミット履歴Reflogsバッファーをコミット差分を取るタギング再設定隠しておく分岐ブランチマネージャどうなってんのー?マージリベース書き換えプッシュとプル2分割表示サブモジュールMagit拡張機能の使用直にGitを使用カスタム化よくある質問 1
It can be tough for your team to know exactly why they need the changes you’re proposing in a pull request. What if we could give them more context? There’s an episode of The Weekly Iteration where a simple trick was mentioned. After adopting it myself, I have noticed my co-workers commenting on how useful these messages have been in providing context. The trick is simple. Split your PR message in
Git Community Book から、1章2節の The Git Object Model を翻訳。ライセンスは、 GPLv2 。 多くのGit解説本と違い、まずGitの内部モデル解説から入るという、おもしろい構成の本です。人によっては、このほうがわかり易いかもしれません。Gitは差分データを管理していると誤解されることがたまにありますが、それは誤りであるということがこれを読めばわかります。 SHA プロジェクトの履歴を表すのに必要な情報は、いずれも、40桁の「オブジェクト名」で参照されるファイルに格納されている。オブジェクト名は、このような形をしている: 6ff87c4664981e4397625791c8ea3bbb5f2279a3 このような40文字の文字列は、Gitのあらゆる場面で見られる。どの場面で出てくるものであれ、その名前は、オブジェクトの内容のSHA1ハッシュを取るこ
分散型バージョン管理ツール「Git」の開発チームは、最新版となる「Git 2.5.0」を7月27日(現地時間)にリリースした。Gitのメンテナーを務めているのは、米Googleの濱野純(Junio C Hamano)氏。 UIやワークフロー、および機能面での新機能は、bashの補完スクリプトへのいくつかのオプションの追加、git diffコマンド使用時と--ws-error-highlightオプション併用時の背景の塗り潰し、git helpで表示されるコマンドリストのグループ分け、git p4でファイルがすでに開かれている際の正確なファイルタイプの認識などが追加されている。 パフォーマンスや内部実装については、既存のオブジェクト名に使用されるunsigned char [20]のstruct object_idへのコンバート、for_each_ref()コールバック機能によるstruct
みなさん、人に見られたくない秘密のファイルはどこに隠してますか? 「決算関連資料_第3四半期」フォルダですか? 「TEMP_20120820」フォルダですか? それともやはりクラウドでしょうか? いくらバレにくいフォルダ名をつけてもうっかり開かれるかもしれない・・・。 クラウドに保存するのはさすがにちょっと気が引ける・・・。 zip圧縮して拡張子を変えるのもめんどくさい・・・。 隠しファイル用の専用ソフトを入れるのも、そのソフトを入れた時点で疑われる・・・。 なかなかベストな方法とは言えないですよね。 そこで、gitで秘密ファイルを管理する方法を考えてみました。 gitならインストールされていても不自然ではないですし、 さりげなくスマートにヒミツのファイルを隠すことができます。 方法 方法はこんな感じです。 【下準備】 ①Gitのリポジトリを作る。 ②秘密のファイルを突っ込む。 【PCを人
プルリク前にコミットを一つにまとめたい場合、良く有る方法としては新たにブランチを切り直して、 そちらのブランチにgit merge --squashしてコミットをまとめるという方法が取られると思います。 git reset --softの場合は以下の手順でコミットをまとめます。 git reset --soft ${ブランチを切った時点でのコミットハッシュ} git add . git commit -m "あらたなコミットメッセージ" 共同開発しているブランチであれば、レビュー用にブランチを新たに切ったほうが良いと思いますが、 個人で開発しているブランチで、自分以外がcheckoutしたりコミットしないブランチであれば、 git reset --softでまとめてしまうのが一番楽かと思います。 ※git reset --softはHEADが指し示すコミットを移動させる事が出来ますが、詳し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く