複数のgitリポジトリを履歴を残したまま統合する - kitak blog
引き継いだプロジェクトが、foo_pc, foo_sp, foo_commonみたいなかんじでリポジトリが分かれていて、同じ機能の開発やっているのにそれぞれにPullReqだしたり、リリースノートを書いたりするのがしんどいので、統合した。以下に統合した時の手順をまとめておく。 まず、新しくリポジトリを用意して、以下のように統合したいリポジトリ毎にディレクトリを作成して(.gitkeepとか用意して)、コミットする。 foo ├── foo_common ├── foo_pc └── foo_sp 次のようなスクリプトを実行する。git 2.9 から無関係なヒストリもってるブランチ同士をマージするときは --allow-unrelated-histories つけないとエラーになるのがハマりどころ。 for repo in foo_pc foo_sp foo_common; do git r
gitクライアント「GitKraken」を使ってみました | iret.media
新しいgitクライアントが出ました。 いつもは、SourceTreeを使ってるんですが ずっと試してみようと思ってたGitKrakenという gitクライアントを時間ができたので、試してみました。 サイトはこちら https://www.gitkraken.com 初期セットアップ インストール Macを使ってるので、ディスクイメージをダウンロードしてインストールします。 起動 ユーザー登録があるので、登録します。 登録をポチッと押します。 そうするとメールが届くので、チェックのリンクを押します。 クライアントに戻って、完了です クライアントで、まだ認証していないようでしたら リポジトリ リポジトリを開く このブログ自体は、gitを使って管理してるのでこのローカルのリポジトリを開いてみます。 ヒストリーがなかなか良い感じです。 ステージにあげます ボタンを押してください コミットする プッ
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
Gitの最初のコミットは空コミットにしよう
# リポジトリ作成 git init # 最初のコミット git commit --allow-empty -m "first commit" 解説 Gitの最初のコミットを修正したいとなると以下のようなことをする必要がある git commit --amend で最初のコミットを修正する(コメントで教えてもらいました!) この方法なら楽にできますね git rebase -i --rootでrebaseする git update-ref -dで参照を更新する 参照 First commit が git rebase -i できない問題 → git rebase -i --root でできる 初回のコミットを取り消したいときにはgit update-refを使う 上記のよう面倒くさいので first commit は空コミットにしておくと良い。 こうすることで2回目以降が本質的に意味のある
git 2.9 の Beautiful diffs を活かす設定 - Qiita
昨日リリースされた git 2.9 の新機能のうち Beautiful diffs 関連の設定を自分の gitconfig に足してみたのでそのメモ。 設定ファイル gitconfig diff-highlight が使えない場合は cat にフォールバックするとか、コピペするだけで使えるよう環境に配慮もしてみた。軽く動作確認したところ問題なく動いてる。 diff --git a/config/git/config b/config/git/config index 3b78506..971396f 100644 --- a/config/git/config +++ b/config/git/config @@ -15,6 +15,14 @@ open = browse [core] autocrlf = false +[pager] + log = (diff-highlight 2>
「Git 2.9」リリース、「git diff」や「git log」での表示変更などが行われる | OSDN Magazine
Git 2.9.0は3月に公開されたバージョン2.8からのアップデートとなる。 UI、ワークフロー関連では、Gitリポジトリへのプッシュ時にメールで通知を送信する「git-multimail 1.3.1」がサポートされた。また、「git diff」や「git log」などのコマンドでファイル名のリネームをデフォルトで確認できるようになった。オプション設定によってこれを無効化することも可能。 新たに「interactive.diffFilter」設定変数が加わった。これを利用して、「git add」コマンドでインタラクティブに変更点を追加するための「-i」オプションを使用した際のdiff表示方法をカスタマイズできる。そのほか、git tagコマンドでは明示的に「-a」や「-s」オプションを指定していない場合でも「annotated tag」を生成できるようになった。「tag.forceSig
たった 8 つの alias で git を大幅にわかりやすくする - Qiita
こんにちは。皆さんは git を使っていると思います。が、 「 git は好きだが、 git の command 体系はどうにも我慢ならない」 という方が多いようです。実を言うと私もそうです。そこで私は alias をいろいろ定義して、 command 体系を少しでもましなものに近づけようとしています。今日はそんな私の気に入っている alias を紹介します。 その 1 g -> git まずはこれです。 git なんて日に 100 回くらい打つ command ですから、 1 文字にしてしまいましょう。 その 2 stage -> add git のわかりづらさの原因の一つは、同じ・ほぼ同じ概念に違う言葉が当てられていることではないでしょうか。その一つが stage にまつわる言葉です。 stage add cache の 3 種の言葉が、 stage 関係の操作に使われています。そこで
Gitを使った開発に慣れるまでの学習方法 - Qiita
こんなタイトルですが、未だに違うブランチで作業してそのままコミットしたり、addし忘れたままプッシュしたりしてます。これまで自分がgitについて学んだことを改めて振り返るためにも、備忘録としてまとめます。 基本的な学習 便利なサイトや書籍 Git をはじめからていねいに タイトル通りGitについて詳しく丁寧にわかりやすく説明してる。初心者はまずこれを読むべし。 サルでもわかるGit入門 これも初心者はまず読むべし。基本的なコマンドを思い出すときによく参考にする。 こわくない git margeやrebaseなどわかりにくいと言われてるところを素敵なデザインでわかりやすく説明してる。リベースこわくないよ！ LearnGitBranching これはすごい。コマンドに応じてぬるぬる動くよ！ チーム開発実践入門 これはgitの解説というよりは、チームで開発する際のバージョン管理のフローについて紹
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
Pull Request / Merge Request の違い - Qiita
結論から言うと featureブランチを開発マスタ用ブランチにマージするなど、あるブランチをあるブランチにマージする依頼を出す点は同じ。 GitHub と GitLab では使い方の違い上、使われる言葉が違う。 ※ GitHub では、開発する際にリポジトリをForkしてローカルブランチを作成することが想定されている。 Gitlab では、開発する際に同一リポジトリ内で開発ブランチを作成することが想定されている。 Merge RequestまたはPull RequestはGitマネジメントアプリケーションで作成され、指定した担当者に2つのブランチをマージするよう依頼します。GitHubやBitbucketでは最初のアクションとしてfeatureブランチをプルするため、Pull Requestという名前を使用します。要求され、最終的に行うアクションという意味でGitLabやGitorious
普段づかいで捗る略語展開のご提案 - Qiita
こんにちは。 この記事にたどり着くような皆様は、普段からTerminalからバシバシ文字を打ち込んでいるかと思います。 当記事の目標は、あまりに便利なZshの略語展開機能を活かし、タイプの手数を極限まで減らし、腱鞘炎などとは無縁なヘルシーな生活を送っていただくことにあります Zshの略語展開 EmacsやVimユーザーの皆様にはお馴染みかと思いますが、略語展開とは特定の文字列に反応して対応する文字列で置換（展開）する機能のことを指します。 例えばhogeという文字列を入力した際に、あらかじめ登録しておいたhoge fuga piyo bazで置き換えられる、みたいな動作になります。 http://qiita.com/matsu_chara/items/8372616f52934c657214#2-2 上記の記事がとても参考になります。 概念がわかったところで、略語展開ができるように.zsh
Git submoduleの押さえておきたい理解ポイントのまとめ - Qiita
みなさんgitのsubmoduleって理解して使ってますか？ 親プロジェクトをpullしたら、submoduleがmodifiedになって混乱してgit addして...あばばばば。みたいな事ないですか？ 私はsubmoduleがなかなか理解できずに結構苦労しました。^^; ブランチ単位で管理する通常のリポジトリと違い、submoduleはCommitID単位で管理するというのが一番理解しにくい部分だと思います。 今回は、プロジェクトにsubmoduleを追加、更新、削除の動きを更新を掛ける側のプロジェクトと更新を受け入れる側のプロジェクトの2つの視点から追いながら、CommitIDで管理するとはどういう事なのかを解説していきます。 (結論だけ見たい人は末尾のまとめへ) 準備 「submoduleを開発する役割のプロジェクト test_app_A」と「submoduleを取り入れる役割のプ
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Git-it - 手を動かしながら習得できる日本語対応のGit/GitHub学習アプリ | ソフトアンテナ
GitやGitHubの使い方を学習することができるデスクトップアプリ「Git-it」。Electronで作られていて、Mac / Windows / Linux用の実行ファイルをGitHubよりダウンロードすることができます。英語表記のみだけでなく、日本語に対応しているところもありがたいところです。 使用方法 Git-it自体は問題集のようなもので特別な仕掛けはありません。画面の指示に従いローカルの環境でGitを使いながら学習を進めていきます。Git-itではGitHub Desktopの使用を推奨していますが、実際の運用を考えてターミナルでGitを勉強してみるのも良いでしょう(Windowsの場合若干めんどくさいですが)。 Git-itでは、Gitのインストールから始まり、リポジトリの作成やコミット、GitHubの使い方、最終的にはプルリクエストの送信方法まで学ぶことができます。 プルリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git 2.9がリリース，merge/rebase/commitなどに新機能を追加
CentOS7 Gitリポジトリをsmart http + nginxで共有する - Qiita
Git初心者が学習するためのおすすめサイトをまとめてみた
Git | ブランチルートから変更のあった全ファイルを一覧する - Qiita
こっそり始めるGit／GitHub超入門
サブモジュールの改善，ID処理，Windowsサポートを加えたGit 2.8
