「This repository’s size is over 1 GB.」と Bitbucket に注意されました。 limit があるので 1GB を越えたところで警告するよ、ということのようです。 What kind of limits do you have on repository/file/upload size? – Bitbucket – Atlassian Documentation限定的ではありますが、対応してみました。 今後のために作業手順をメモしておきます。
2.45.1 → 2.47.1 no changes 2.45.0 04/29/24 2.44.1 → 2.44.2 no changes 2.44.0 02/23/24 2.43.1 → 2.43.5 no changes 2.43.0 11/20/23 2.42.2 → 2.42.3 no changes 2.42.1 11/02/23 2.42.0 08/21/23 2.41.1 → 2.41.2 no changes 2.41.0 06/01/23 2.40.1 → 2.40.3 no changes 2.40.0 03/12/23 2.39.1 → 2.39.5 no changes 2.39.0 12/12/22 2.38.1 → 2.38.5 no changes 2.38.0 10/02/22 2.35.1 → 2.37.7 no changes 2.35.0 01/24/
I'm developing a jQuery plugin that's being hosting on GitHub. It has a demo included of which I'm manually copying and pushing to the branch gh-pages, what I'd like to do is have it so when I push a change to master it is automatically pushed to gh-pages, or at least a setup where they are mirrored. I've already seen this question but not sure if it really answers my question with regard to these
github has this feature where you can publish "Project Pages" if you create a new branch gh-pages in your project. For full description see http://pages.github.com/ My project is just html/images, so I just want to serve the master branch. so how do I create a new branch called gh-pages that is just exact copy of master? some kind of link operation? Thanks
id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 （これ以降の記事中のリモートは全てoriginとします。） このコロンは何？？ リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか？ 実用Git 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型本購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p
削除されたか確認 $ git branch -r origin/HEAD -> origin/master origin/fuga 解説 $ git push --delete origin hoge 普通はこっちを使えばよいでしょう。 コロン記法と動作は同じです。 $ git push origin :hoge この構文の覚え方を説明します。 ２つポイントがあります。 なぜ"git push"でブランチが削除されるのか。 なぜブランチ名を":hoge"と書くのか なぜ"git push"でリモートブランチが削除されるのか。 考え方としては、「"無"を送りつける」「nullで上書き」です。 Linuxいう/dev/null みたいなものです。 なぜブランチ名を":hoge"と書くのか よい質問です。 そもそも、git pushの構文を確認しましょう。 git push [remotenam
Git GUIについて Git for Windowsには、シンプルで使いやすいGUIクライアント「Git GUI」が付属しています。Source TreeやGit Extensionsに比べると機能は少ないですが、画面がごちゃごちゃしていない分、Git初心者には理解しやすいのではないでしょうか。 日本語表示の対応状況 Git for Windows Ver.1.9.5付属の「Git GUI」では、普通にインストールするだけでUIが日本語で表示されていました。しかし現在(2016/1/8時点)の公式バイナリであるVer.2.7.0をそのままインストールしても、残念ながらGit GUIの画面表示は全て英語になってしまいます。どうやら、Ver.2.x.xのバイナリには、多言語表示用のメッセージ定義ファイルが同梱されていないようです。（理由は不明です。調べれば分かるのでしょうが...） そこでV
長年MinGW/MSYSを使い続けているのですけど、最近あまりアップデートされません。例えば、bashは9年前のversion 3.1のままです。世間ではversion 4.2, 4.3が使われているのに。 MinGW/MSYSの後継らしきMingw-w64とMSYS2の組み合わせに替えようかと思ったのですが、Git for Windowsがあれば十分な気がしてきました。 内容： MinGWとMSYS ディレクトリレイアウトとPATH環境変数 Mingw-w64とMSYS2 Git for Windowsのシェル環境 まとめ MinGWとMSYS MinGWとMSYSは一緒に使っている人が多いと思いますが、目的が異なる2つのシステムです。MinGW/MSYSとよく比較されるCygwinは、単一のシステムとしてWindows上にPOSIX環境を実現するものです -- 目的も方式も明快です。こ
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
gitが大きくなると時間かかってしゃーないと思っていたら、ちょうどatlassianのブログにこんな記事があった。 How to handle big repositories with git - Atlassian Blogs 巨大なリポジトリ を Git で上手く扱う方法 直訳ではなく、読んだことを参考に自分用にメモを記す。これは本当にメモ代わりなので原文を参照した方がいいと思う。 gitが重くなる原因は、「長い歴史」と「デカいファイル」の2つがある。その2つの対処法。 長い歴史に対処する shallow cloneを使う gitのhistoryが積み重なると、git cloneに時間がかかる。そのときはshallow cloneを使って、深さを限定してcloneする。 git clone --depth depth remote-url 手元の環境だと23sくらいかかっていたのでも
例えばgit-resetなどをする時などにHEADの2世代前のコミットにHEADを移す場合は HEAD^^としたりHEAD~2としたり。でもHEAD^2という指定もあります。そのへんのまとめ 題材としてアイドルマスターシンデレラガールズ(以下モバマス)で考えます。 まず、適当にリモートリポジトリを作った後git-cloneして最初のgit-commitを行います。 その後、運営の犬であるちひろさんを追加します。ここまでは共通作業ですのでm@sterブランチで行います モバマスはキュート、クール、パッションの3属性があるので3属性分のブランチを作ります。 次に、いわゆる2コスと呼ばれている各属性のコスト2アイドルを追加していきましょう。 キュート:島村卯月 クール:渋谷凛 パッション:本多未央 キュートブランチ $ git co master $ git co -b cute 島村卯月はノー
次回以降の流れは？（2016/04/11 0時 追記） マンガでわかるGitの構成は、ざっくり下記の構成を考えています。 最初の一歩： Gitとはなんぞや？ 第一フェーズ： １人で使ってみる 第二フェーズ： 複数人で使ってみる 第三フェーズ： 実務上でのハウツー（応用） これは、まだ私が頭の中で考えているだけの仮段階のものですので、細部はみなさんからのコメント・需要を拝見しながら変更していくと思われます。 ちなみに、はてブコメントで要望の多かった「SVNとGitの違い」 → こちらのマンガ化はやってみたいですね。 #マンガでわかるGit 全体の構成（仮）考えるの楽しい♫ Gitってそもそも何？メリットは？ ↓ 一人でGit😃 ↓ 複数人でGit😃😃 の流れで考えています。 はじめてコミット、チェックアウトしたときの感動といったら！ pic.twitter.com/uyCl1zAxAF
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
git rm 使い方 ワークツリーとインデックスからファイルを削除する file.txt を削除するには git rm file.txt とする。このとき、ファイルは削除されてワークツリーからなくなり、 インデックスに削除の情報が追加される。 また、拡張子 .txt のファイルを削除するには git rm *.txt とする。このときに、*.txt にマッチするがリポジトリに登録されていないファイルが あるときには fatal: pathspec 'test4.txt' did not match any files というようなエラーが出る。 これは「–ignore-unmatch」オプションをつけると無視してくれる。 git rm --ignore-unmatch *.txt 再帰的にディレクトリを削除する ディレクトリ dir の中のファイルを再帰的に削除するには git rm -r
git rebase パート1の続きです。 fixed(コメントは変更せずにコミットをまとめる) fixed は squash と同じく1つ前のコミットとまとめる機能がありますが squash と違うのはコメントはそのままにするということです。 squash と同じ説明になりますが 70b3379 の メソッド名のタイポ修正 を何事もなかったかのようにしたい時は cce19c9 とまとめてしまいます。いつものように [kengo@tkengo-mac] $ git rebase -i cce19c9~1 こうして pick cce19c9 通信用のクラスの実装とテストの追加 fixed 70b3379 メソッド名のタイポ修正 pick aebf22c テストが落ちてたので修正 とします。すると squash の場合はこの後にコメントを入力する画面が出て来ましたが fixed の場合はそれが
1. gitの基礎（言葉の意味） ワーキングツリー[working tree]：最新のファイルの状態 インデックス[index]（ステージ[stage]）：コミットするためのファイルの状態 ローカルリポジトリ[local repository]：ファイルの変更履歴を記録（手元で管理） ヘッド[HEAD]：最新のコミットの状態 リモートリポジトリ[remote repository]：ファイルの変更履歴を記録（みんなで共有） add：「ワーキングツリー → インデックス」への反映 commit：「インデックス → ローカルリポジトリ」への反映 push：「ローカルリポジトリ → リモートリポジトリ」への反映 2. git resetを使いこなす git resetには--hard、--mixed、--softの3つのオプションがある。 ※厳密にはもっとあります。詳しくは`git reset
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く