Git 17
レス数が1000を超えています。これ以上書き込みはできません。
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured git revert ハッシュ
で打ち消しコミットが作られるけど
コミットではなく編集までにとどめるにはどうしたらいいの？
いったんコミットまでやっちゃってresetするしかない？ 5/8にzoom の sun lin という人が簡単なパッチを投げる。
=> レビュアーに指摘を受ける
=> 何度もパッチを投げる
=> 何度もレビュアーに指摘を受ける
7/12に17回目のパッチを投げる。
17回目のパッチもHamano氏に指摘を受ける
=> その後sun linさんはパッチを投稿せず
9/3 HAMANO氏がどうなってんの？メールを投げる。
cooking in git.git には Expecting a reroll. と書かれる。
https://public-inbox.org/git/pull.781.v16.git.git.1594544903477.gitgitgadget@gmail.com/T/#t
MLを見ていると簡単に採用されるパッチもあるし、何度もやり直しさせられて
20回以上作り直してやっと採用されるパッチもあるし、いろいろ大変ですな。 仕事は別として個人プロジェクトのやつは
パッチはそれなりにOKだったらマージすることにしてる
自分でやったほうが早いし、継続的に参加するわけでもない
簡単なパッチ提供者にプロジェクトの方針とか伝えるのは
面倒だしお互いに苦労するだけで実りがない >>6
Hamano氏が「圧」したら、sun lin 氏からパッチの返信が来た。
cooking in git.git は Will merge to 'next'. に変更されて
次の次( 2.30? )でマージされそう。 チェリーピックをした際に、コミットログに 元ネタのコミットハッシュを書きたいんだけど
どうやって書けばよいですか？ -n でコミットしないで置いとかれるから、手動でコミットする。
後からamendなりrebase -iする方がやりやすいかもしれない。 porcelain全部です
わたしがよく使うのはinit、clone、add、add -u、status -sb、commit -q --no-verbose、commit --amend、commit --fixup、checkout、checkout -b、diff、diff --cached、merge --no-ff、merge --squash、reset、reset --cached、rm --cached、tag、tag -d、push、push -u、push --tags、push --delete、pull、branch -d、branch -D、rebase --onto、rebase -i --autosquash、cherry-pick、clean -dxn、clean -dxf、あとはgitk --allです。
gitrevisionsの知識は必須です。 >>14
ありがとうございます
それ全部覚えて兄貴の隣の席で仕事ができるようになりたいです https://github.com/yuto-te/msword-test
ms wordのファイルが管理できると聞いて試したけど
git clone https://github.com/yuto-te/msword-test
cd msword-test
git wdiff test.docx
git: 'wdiff' はgitコマンドではありません。 'git --help'を参照してください
で動かない
となって そのレポジトリのaliasにwdiffの設定書いてあるみたいだけど。 cloneやpushなどでリモートホストとファイルやり取りする際にファイルの同一性はどのように担保しているのでしょうか？
例えばブラウザでファイルダウンロードしたときにたまにファイルが壊れていることがあったりしますが
gitでそういったことは起きないのでしょうか？ ありがとうございます
ファイル等gitオブジェクトはSHA-1で格納されているらしいということまではわかったのですが
受信時にこれを使ってベリファイしてるんでしょうか SHAで格納とかいう時点でエラーチェックについて全くわかっていない。
チェクサムかパリティビットから勉強しろ。 横だけど、同一性のためのチェックはSHA-1で、ってことでしょ。 いまファイルを編集中でコミットしたくないんですけど
別件で修正依頼が来たのでそれの修正をしてそれだけコミットし、編集してた状態に戻すまでのコマンドを１から教えてください >>25
すみません書き方が悪かったです
SHAハッシュ値をフォルダ名とかファイル名にして格納してるという意味でした
詳しそうなのでgitが同一性の確認をどのように行っているのかご教示いただけませんか >27
git stash save
他の作業
git stash apply
でもなコミットを忌避する理由は無い。
gitはコミットを編集できるから作業はとにかくブランチでやってバンバンコミットしてamendとかrebaseとかsquashとかresetする方が良い。
stashだって無名のブランチみたいなものだぞ。 横からだけど
master で作業中
git stash save
他の作業 (branch B を造ったとして)
git stash apply
ここで master に戻るんじゃなくて B の続きでってどうするの？ >>29
SHAハッシュ値をフォルダ名とかファイル名にして格納するのだから、格納するときにチェックすればいいだろ
実際にチェックするタイミングは臨機応変だよ
新規ファイルをコミットするときにはそのファイルのハッシュ値でフォルダ名やファイル名決めるのだから自然と一致するし
ファイルを上流からfetchしてきたときはファイルと一緒にハッシュも一緒にダウンロードするだろうからそこでチェックできる
git fsck みたいなコマンドで手動で強制的にチェックすることもできる >>31
stashのapplyやpopは、saveしたブランチでなくてもできるよ
必要ならマージしてくれるし、当然コンフリクトもする >>29
どのプロトコル使っても整合性チェックすると思う。もしかしたらGit Internalに書いてあるかもしれないけど、どうしてそれを思ったの？webブラウザ使ってるときにデータが欠けてるか気になる？ >>32
ありがとうございます参考になりました
>>35
本来の用途と違いますが簡易的なファイルバックアップ目的で使えるかなと思いまして
これだけ使われていてデータ化け等のトラブルを聞いたことがないので
何らかの同一性をチェックする仕組みがあることは予想できましたが具体的に仕組みを知っておきたかったのです あとは自分でソースコード読んで調べます
お世話になりました いやだからSHA-1が何か知っていれば十分。
gitのソースなんか常識的なことしかやってない。 そもそも差分で保持していることすら理解できてなさそう 差分で保持？Subversionあたりと勘違いしてそう バイナリ弄くって中身を直接改竄したらどこで気付けるの？
githubにプッシュする段階で弾かれる？ 簡単に試してみると
status チェックしない
checkout チェックしない
diff チェックしない
clone チェックしない！
pull チェックする
fsck 当然チェックする すまん、SVNと勘違いしてた
スナップショットだったな >>43
チェックしたかどうやって調べたんですか？ >>47
status
エラーが出ない。改竄されて無いかのような結果を返す
checkout
エラーが出ない。改竄されたファイルをcheckoutできる
diff
エラーが出ない。改竄されたファイルとの差分が表示される
clone
エラーが出ない。改竄された状態のままクローンされる >>48
cloneでチェックしないのは驚き。
pullするまでわからないの？
pullとfsckはどんなエラーが出るんです？
pushはさすがにチェックするよな？リモートレポジトリ壊れちゃうぞ
ちなみにblobを改ざんしたんだよね？
treeやcommitと整合取れなくてエラーが出るってことなのかね？エラーはどこで検知されるんだろう。 >>50
blobのオブジェクトの中身を改竄
ファイル名のハッシュ値と中身が一致しない旨のエラーが出る
clone も pull も同じファイルシステム上で試して、pullだけエラーになった
ネットからのcloneならもしかしてエラーが出るかもね gitのコマンドで、ファイル毎のコミットハッシュを一括で取得するようなコマンドはありますか？ git rev-list ブランチ名 -- ファイル名 Git v2.26でプロトコルバージョン2がデフォルト
↓
Git v2.27でプロトコルバージョン2が非デフォルトに
↓
Git v2.29でプロトコルバージョン2が再度デフォルトになる予定 プロトコルバージョンが2になるとなにがよくなるんでしょうか？ おそらくGitHub特有の相談になるんだけどここでいいかな？
全体としては公開リポジトリなんだけど
ある理由（ライセンス制限、期日まで非公開にしておきたいデータ等）により
特定のファイル(secret.txt)もしくはディレクトリ(SecretFiles/)のみ非公開にしたい。
・【必須】バージョン管理はしたい
・全体と非公開ファイルは一体であり、非公開ファイル単体では意味をなさない
・開発中は公開/非公開を意識したくない
こういうとき、どういう方法を取ることが多いでしょうか >>58
非公開のファイルは別リポジトリに分離してgit submoduleで参照するのはどうだろう ありがとう
ただ、（必須条件ではないとはいえ）この２つが気になってる
> ・全体と非公開ファイルは一体であり、非公開ファイル単体では意味をなさない
> ・開発中は公開/非公開を意識したくない 英語のフォーラムとかも漁ってみたけど
「submodule、ただしお前さんの開発のフローに合致するかどうかは知らん」
って感じみたいね
下手すると1ファイルだけのリポジトリとか
作る羽目になりそうだけど仕方ないか…
リポジトリ本体とサブモジュールでコミットの足並みをそろえたり
本体のコミット履歴にサブモジュールのそれを流し込んだり出来るものなのかしら？ そもそも足並み揃えなきゃいけない理由がわからない
2つのリポジトリから取ってくるじゃダメなのか 足並み揃ってることが大事なら
sub の方にバージョン番号も入れておいて
main の方は sub のバージョンが正しいかどうか確認して動作する構成にしたら医院で内科医 >>64
ライブラリなり単独プロダクトなり論理的に分割できるものではなく
本来であれば他ファイルと一緒に管理するべきものって前提ね
具体的な方法はともかく
本リポジトリのコミットAのタイミングで、サブ内のファイルBが更新された
というのが追えるのが望ましいかなと
>>65
あー、なるほど
バージョン番号というよりはコミットハッシュのほうが良いかもしらん
やったことないけど多分自動化出来るだろうし Yahooとかamazonみたいな巨大なサイトって1つのリポジトリでWebサイトのソースコードを管理しているのでしょうか？ GAFA: Google Apple Facebook Amazon
Yahoo Microsoft Twitter Mercari LINE googleはgitじゃないけど1つのリポジトリで全てを管理してるんだよな googleの巨大リポジトリはgitを改造して作ってるんだろ。
っていうか、そのためにHamano氏が雇われてると予想してるんたが。 lan内、複数人、全部windowsマシンの環境で、vssからgitにしようとしてまっす
結局、gitサーバーって必要なの不要なの
bareレポジトリを共有フォルダにすればいいだけでっすか local で運用したいなら
git と ssh のみで ok 共有しないならローカルだけでgitを使うのもいいよ。
文書作成とかローカルgit重宝するんだけど、あんまり流行らないよね。 コードレビューしないなら別にホスティングいらないんじゃね 文書ならSubversionの方が使いやすい
Gitはサブディレクトリをチェックアウトできないのが致命的 自然文書じゃマージしようないし、Gitの設計は根本的に当てはまらなくなるな どっちみちマージできないんだからロックした方がマシだわな GitはWordExcelファイル管理してるとすぐにリポジトリ肥大化する問題もある ファイルサーバ的な使い方だと、フォルダ単位のアクセス制御とかファイルロックとかでSubversionが使いやすい
Gitみたいなスナップショットで管理する設計は大規模な非ソースコード管理には向かない 自然言語はプログラミング言語と違って構造化されてないからね 自然言語は構造化されてないが
ドキュメントは構造化されてる 文章も markdown みたいなテキストベースで書いて git で管理すると極楽だよ 日本語だとか英語使う以上どうにもならん
それよりも、markdownって糞面倒くさい
リストの先頭にスペース4個だ8個だ、1. 1. 1.でナンバリングとかいかれてる
リンク貼るのは面倒だし、テーブル書くのは悪夢だし、slackがmarkdown止めたのも納得
wiki記法でもasciidocとかマシな選択肢他にある フォーマットの良し悪しはどうでも良いよ
問題は普及してるかどうか
客先とかにメールで躊躇なく送れるフォーマットでないと使わない
gitで管理するためにテキストベースならありがたいが、優先度は低い >>90
pandoc で word に変換して送る >>91
それって、wordフォーマットで貰って加筆して送り返す場合も、元の書式が完全に再現されるの？ pandoc での変換は word への一方通行だよ 「Git for Windows 2.29.0」が公開 ～セットアップ時にデフォルトブランチ名を設定可能
https://forest.watch.impress.co.jp/docs/news/1284871.html
「Git for Windows」ではこれに加え、“git init”コマンドで利用されるデフォルトのブランチ名をインストーラーで設定できるようになった。
「Git」の開発チームはデフォルトのブランチ名を従来の“master”から“main”に変更する意向で、「Git for Windows」もそれに追随する構えだ ぶっちゃけ日本人としてはmaster（ご主人様！）でもmainでも
どっちでもいいんだが、gitが変えるならmainでいいとして
masterとmainを同一視する機能作らないの？
エイリアスブランチとかいう名前にしてさ、どちらからでも同じようにpullできる >>97
互換性が保たれる
各自好きなときに変更を入れられる
誰にも影響がない ブランチなんだからブランチ操作のときの互換性に決まってんだろ
アホかｗ mainにする必要を感じないユーザーは今後もmainを使い続ければいい
互換性の上で何も困らない
上司が新しいブランチをmainで作りやがったけどオレはmasterが慣れてるんだ！オレの快適のために便利機能を開発しないGitはクソ！とか言い出したら立派なクレーマー 書き間違えた
×今後もmainを使い続ければいい
◯今後もmasterを使い続ければいい >>102-103
な？そういうときにmainとmasterがエイリアスの関係になってれば
問題は全く起きないやろ >>105
誤字は訂正すりゃ済む話だろ
誤字の責任をGitに転嫁し始めたらお前と同じだが
自分が欲しいと思い付いたものは皆欲しいに違いないし
それを提供する大人は疑い無く奉仕すべきってのは子供の発想 >>107
誤字の話なんかしてないけど、どっから持ってきた（笑） >>105
誤字の話じゃないとすると、「問題」ってどういう状況のことを言ってるの？ > 上司が新しいブランチをmainで作りやがったけどオレはmasterが慣れてるんだ！
ここに決まってるだろ
エイリアスがあれば上司はmainを使えるし
オレはmasterを使える
何も意識せずにだ
問題解決 >>111
リモート oritin/main に対してローカル master で作業すれば問題ないのでは？ >>112
だからその作業をユーザーにやらせるなってこと >>114
最初の1回だけでしょ？
・・・あー、リモートブランチ名省略して git push origin できるのは名前が同じ時だけか。
なるほどちょっと面倒になるね。
と思ったけど push.default を upstream にしとけば git push origin でいけそう。
https://git-scm.com/docs/git-config.html#Documentation/git-config.txt-pushdefault >>108
まあ確かにリリースブランチとか定期的に切り替えるときには便利だな
masterとmainの互換性はわからんけどw >>115
ブランチ名省略してgit push originなんて怖くてやったことないけど使う人いるのか？ >>117
怖いのは無知だから。勉強すれば怖くないよ
俺はいつもgit pushだな。originも不要 >>117
怖いなら-v ---dry-runでもつけてどうなるか確認してみるといいよ 君のGit... ギットギトだね。。。
ほら。。。フォースプッシュ。。。
本番ブランチ。。。 $ git push origin master
error: src refspec master does not match any.
error: failed to push some refs to 'https://github.com/hogehoge/hogehoge.git'
糞だな git branch master
git checkout master
git merge main
git push origin main
git branch -D main
git push --delete origin main
git gc
消したったわ 久しぶりにgit使ったらbranchがデフォルトでmasterじゃなくてmainという表記になっていたのだが ローカルのgitがmasterでリモートのgithubがmainになってるね
クローンからリモートするならすんなりいくけど
その逆だと気づかずにプッシュするとmainへのリクエスト扱いになっちゃう
configでデフォルトのブランチ名変えられないのかな git remote set-head origin master https://ngyuki.はてなblog.com/entry/20120827/p1 散々ニュースで言われてるのに今頃になって対応とか遅くない？ >>130-131
設定できるのかー
①githubで新規リポジトリ作成
②ローカルのリポジトリディレクトリに移動して$ git init
③$ git add . $ git commit -m 'ローカルスタート'
④$ git checkout -b main $ git branch -d master
⑤$ git remote add origin https://github.com/[user name]/[repository name].git
⑥$ git push -f origin main
ってやってる・・ もうつぎからはリモートスタート（クローンスタート？）だとローカル側もmainブランチで始まるから
空リポジトリをクローンする方法でやる 「gitのメインブランチは昔はmasterだった」
「嘘乙」
「なんでmasterからmainになったんですか？」
「masterは奴隷差別を連想させるからだよ
」 releaseとかsummaryとか使うところ出てくるかな？
integrationとかは無さそうかね。 昔から develop ブランチを使ってるとこが多いでしょ git flowしてたらreleaseブランチは普通にあるでしょ 「使うところが出てくるのかな？」に対して「既に使ってるところはあるやろ」って返しだから何もおかしくない 開発当事者でもないのにブランチ名変えろと
ポリコレissue投げまくる事件起こりそう tortoisegitでマージコミットを選択すると、親１との差分、親２との差分という形で別れて表示されますが、これを3-way表示にさせる方法はありますでしょうか？
テキスト比較できないファイルを外部ツールでdiffしており、競合の編集時はその外部ツールで3way表示できるように設定しています。
マージコミットからダブルクリック等でその外部ツールの3way表示が開くのが理想なのですが、そのような設定や手法はありませんでしょうか？ すまんすまん、デフォルトブランチを変える話な……と思ったけど、開発観点からはgitのデフォルトブランチなんてどうでもいいか。
>>144
mster使わないのは別に構わないけど、開発者なら技術的な利点を主張して欲しいわ。
技術屋が形だけでも同意できる理由も用意せずにねじ込もうとするポリコレバカはくたばって欲しい。 わかったわかった、ポリコレに配慮してブランチ名はすべてsha1ハッシュにしよう 秋葉でお帰りなさいませ御主人様が聴けなくなる日も近いか メイド自体も主従関係の歴史を想起させるのでNG
家事の主体たる職業名を採用しメイドカフェはハウスキーパーカフェになります
衣装はズボンとエプロン ホットドッグにマスタードかけるのも禁止になりそうだな ファストフォワードマージと分岐するマージはどっちを利用するべきなんでしょうか？ pythonの場合
distディレクトリとegg-infoディレクトリは
git rmしますか？
それとも更新するたびにsetup.pyして最新版の.tar.gzもpushするのでしょうか。 ホームディレクトリに.ignore設置して云々とかあるけど
全部コマンドでできればいいのに・・ 全部コマンドで、というか
git config で・・ そういうのはリポジトリの .gitignore で除外するだろ
言語に対応した .gitignore を自動生成する仕組みとかあるからググれ >>160
gitignore自体gitの管理対象なんだから、ファイルのほうがいいだろ。 git config の core.autocrlf について教えてください
リモートのリポジトリにAとBというブランチがあります。
２つのブランチのファイルの改行コードはLFになっています。
下記手順でAとBをチェックアウトし、各ブランチの改行コードを見ると、AもBもCRLFとなっていました。
①git config --global core.autocrlf=true を実行しAのブランチをチェックアウト
②git config --global core.autocrlf=false を実行しBのブランチをチェックアウト
一度チェックアウトした後にcore.autocrlfの設定を変えても、その後にチェックアウトしたブランチには適用されないのでしょうか？ autocrlfを気にするということはWindowsでの開発だと思います。
autocrlf=trueでコミットしたんじゃないかと思います。
コミット内容はオプションを変えても変わりません。
これはレポジトリはLFにして、作業コピーはCRLFで扱うオプションです。
個人的にはこのオプションは、勝手にファイルを変えるものなので使う場面は限られると思います。
最近はWindowsでもLFが使えるようになってきてるのでLFだけにするか、もしくはWindowsだけで開発するならCRLFでそのままコミットしてよいと思います。 あ、ブランチはLFって書いてありますね。ふむー。AだけがCRLFのはずだが。
LFであることと、チェックアウトしたファイルがCRLFであることはどうやって確認したんですか？
エディタがCRLFに変換してるってオチじゃないですよね？不安ならodとかでダンプしてみるといいです。 >>166
ご回答ありがとうございます。
LFであることの確認はgithubからソースをzipでダウンロードしてソースファイルをEmEditorで確認しました。
CRLFであることの確認はローカルにチェックアウトしたソースファイルを同じくEmEditorで確認しました。
odというもので再度確認してみようと思います。 同じエディタで確認してるなら改行コードの取り違いはなさそうです
ファイルの内容とか拡張子はなんですか？attributeが悪さをしてるとかだろうか
いずれにしてもautocrlfの理解は合ってると思います ちなみにgit configのヘルプにはname=valueではなくて、スペース区切りの指定に見える。
autocrlfを変えたあとにconfig --getしてみたらどうなります？変わってなかったりして。 VSCode を使え！
GitLens などの拡張機能も色々ある 便乗で質問
LF管理でCRLFへ自動変換はよく見るのですが
逆に
リポジトリ上ではCRLFで管理
ローカルではLFに自動変換も可能
みたいなことって出来ますか？ リポジトリ上ではどう管理されてるかなんて気にする必要がない 設定としては存在しない
そしてリポジトリ上でCRLFにするのは非推奨 設定としては～、ということはやり方が無きにしも非ずと
まだまだ触り程度しか使っていないので、必要になったらまた勉強します
ありがとうございました 非推奨ってどこに書いてある？
Windowsだけで使ってるからいつもCRLFで入れてるよ Gitの場合、テキストファイルもバイナリファイルも関係なくハッシュ作って管理してるだけ >>178
ハッシュしか持ってなかったら元データを復元できないのでは >>173
自動変換するわけがない。普段、改行コードをあまり意識していないだけでしょ。 >>179
ハッシュ変換とハッシュ変換したデータを使う仕組みがごっちゃになってるよ。 >>173
git hooks で調べろ。何でもできるぞ。
間違えてgithubの記事を見に行かないように。gitの機能だからな。 >>173
なぜ改行コードを変えたいのかがわからない。 どうでも良いけど下手な環境で作業すると
保存する度に行間が開いていくよね >>186
自動変換の設定を確認してないという話だろ 最初のautocrlfの人戻ってこないな
解決したのか gitattributesの改行と文字コードのデフォルト値ってどっかに一覧ないですか？
改行と文字コードの自動補正はしてほしいけど想定外の補正されると困るんで把握しておきたいです gitの初心者です。質問してもよろしいでしょうか？
共有フォルダの[A]フォルダにリポジトリを作り作業するファイル類を入れてあります。
これを2人で共同で使うためそれぞれ[B]と[C]というクローンを作り、そこで編集します。
それぞれ[B]と[C]で更新して、1日の終わりに[A]を最新の状態にしておきたいのですが、
クローンして、更新してCommitして、最後にpushで合っていますでしょうか？ 内容によるけど
全員 master で作業するんか？
branch して commit push して
確認後 merge する気は無いんか？ >>194
エディタで修正してaddしてcommitするだけよ めちゃくちゃ細かい修正のときって-mはどうしていますか
考えるのがめんどうなので'更新'とか'修正'でいいですよね？ >>196
そこは回答が分かれるところですね。
自分だったら、主にどっちを採用したっていう概要とその理由を書くかな。
細かい差分はdiffで見れるから、後で見ても分からないものは書いておくよ。
他の人にも聞きたいんですが、コンフリクト解消ってどこまでやりますか？ビルド通って動かせるところまで？
evil mergeになるのが気になる。 コミットを分けるか、という意味です。言葉足らずですみません >>193
いつまでmasterなんか使ってんだ？ お帰りなさいませご主人様～ とかも駄目になるのかぬ 言葉狩りに嫌気さしてきたからブランチの名前をslaveとかblackとかにしたい >>200
まだまだ言葉足らず過ぎないか？
不特定多数の見る5chやでえ
マージをしているなかで互いの処理の競合を調停するための新規コードが必要になったとき二つの選択肢があると思う
1.テストが一部通らないことをコメントで断った上で、新規コードをマージコミットに混ぜるのを避ける
2.競合回避のための新規コードが混ざったことをコメントで断り、マージコミットで全部やる
個人の好みと程度問題じゃないかな
俺は差分を共有しやすいから1が好き >>205
ブランチをマージするときの話ですよよ。文脈は把握されてますか？ご存知なければ無理にレスしなくて大丈夫ですよ。 >>206
evil mergeを避ける派ですね。
丁寧なレスありがとうございます。
言葉足らずなところを指摘、補足していただいてありがとうございます。 >>202
変える技術的なメリット無い限りはそのまんまだろ。
技術的なメリットを説明しろよ。 作業ブランチで機能追加やクリーンナップを地道に進め、
最後にmergeした結果を見ると、コーディングを最初から一気にやり遂げた錯覚になり、
スカっとするな。
という一連の流れを脳内再生してから --squash のオプションを思い出す俺。 >>210
お前エセだろｗ
作業ブランチで作業をしている途中で
あれ？これバグじゃね？
先にリファクタリングするべきだったなと
後から気づくことがある
そういうのを別のコミットに分けて
順番を並び替えつつ作業していくと
いきあたりばったりで作業したのではなく
綿密な計画にそって作業したように見える
それは錯覚ではなく、最終的にそうなったので
それをマージしたりしたときに後から修正を追いやすくなる
--squashしたら一つにまとまるからダメじゃん そんで author date を変え忘れていきあたりばったりがバレる >いきあたりばったりで作業したのではなく
>綿密な計画にそって作業したように見える
他人にバレてるのに自分じゃこう見えると思ってたら恥ずかしいってだけ >>214
どうでもよくね？
重要なのはソースコード、完成した結果だよ
途中の作業なんかどうでもいい ほんと、どうでもいいと思うよ。
>綿密な計画にそって作業したように見える
こんなの気にするのは>>211くらいｗ >>216
気にしてるのはお前だよ。「ように見える」なんだからどうでもいい部分
実際に重要なのは、意味があるコミットになっていてレビューや他のバージョンへの適用がしやすい点
いつまでもどうでもいい部分を気にしてるなよｗ gitの開発MLを見てればわかるが、
内部のテストからもmasterという文字列を完全に抹殺すべくパッチが投稿されてる。
個人的には言葉狩りは好きでは無いが、
リベラルに中途半端は無いから、
早めにmasterからmainに変えた方が良いかも。 外部のキチガイが、内部に入り込んで包丁振り回すかもしれないぞ WindowsでSourceTreeを使ってみたら、Shift-JISのファイルがプレビューで文字化けしてるんだけど、
Gitで管理するときは大人しくすべてUTF8に変換するべきなんでしょうか Git関係なくUTF-8にするべき
Visual StudioのプロジェクトならUTF-16とかもあるけど
少なくとも全部Unicodeにしとけ Visual Studioでsjisファイルのプレビューを見てみたけど文字化けなんかしてないけどなあ >>225
git自体はUTF8だろうがSJISだろうが管理できるよ
文字化けするのはSourceTreeの問題 Visual Studioがうんこだから仕方なくVSで管理する用のソースファイルはBOMつきUTF-8にしてる
本当はBOMなしUTF-8がいいけど
（/source-charset:utf-8の存在は知ってる） >>230
visual studioもEditorConfig対応しているってよ。 Gitは文字コードを管理できないというか実質的にUTF8強制になる
改行コードも固定するしかない Visual Studioのプロジェクトにはプロジェクトファイルやリソースファイルも含まれていて、
UTF16やShift-JISで自動的に生成されるものが多いけど、
これらのファイルもUTF8にして運用するのがGitのやりかたということでしょうか？
MacやLinuxなどに持ってくることは考えていないです。 UTF-16でもUTF-8でもいいよ
Unicodeならどっちでもいい Gitだと文字コードや改行コードが考慮されないから、Windowsだけで開発するならUTF8以外でもいいいけど、いずにせよ固定しないといけない SJISでもいいといえばいいけど、LinuxユーザーやMacユーザーがメンバーにいると困ることになると思う >>237
質問者はWindowsだけって言ってるだろ WindowsだけならSJISはまずいな
海外のWindowsじゃ使えない
やっぱりUTF-16じゃないと SJISのファイルを英語版のWindowsに持っていったら、Windows Indexとかどうなるんだろうな batファイルがCHCPだけで問題なく使えれば全部UTF-8にできるんだがなあ
現実解でいえば多少Shift JISのソースが混ざることもあるよ
Gitでは困らないけど統一できるならしたいところ >>241
バッチファイルだけだよって言ったほうがわかりやすいｗ >>241
Power Shell使わせたら？
バッチファイルしか使えないような環境は未サポートでいいだろ。 何度もすいません。必ずしもUTF8にする必要はないということは、
SourceTreeで差分などが文字化けするのは諦めた上でということですか？
それとも、Shift-JISやUTF16のファイルが混ざっていても
文字化けさせない方法があるのでしょうか？ gitはファイルしか管理していない。
ファイルパスを保存しているからディレクトリが有るように見えるだけ。 >>245
差分はwinmergeがおすすめよ
文字コードの認識能力は高いし、多くの改行コードにも対応してる
難点は、いろんな文字コードや改行コードが混ざってても気づかないところかw
gitとの連携もできるしね >>251
改行コードが混在してるときはMixedってステータスバーに表示されたかと >>247
作業ディレクトリなどのように中身のファイルを無視したい場合は、.gitignoreを例外として全ファイルを無視する.gitignoreを入れておくといい。 >>246,251,252
ファイルごとの文字コードは無理に統一せずに、
UTF16やShift-JISのときはSourceTreeの差分表示は文字化けさせたまま、
WinMergeで比較を行うということですよね？
WinMergeは普段から使っているので、
SourceTreeで文字化けしていてもGitの管理上は問題ないのなら、
それが楽かもしれないです。 WindowsユーザーのGit初心者はTortoiseGitを使うのが一番楽だと思う
同梱のdiffツールも十分実用的
シェル統合は好き嫌い別れるけど文字化けのようなトラブルを独力で解決できるなら好きなツールを使えばよろし 開発初心者なら、こだわりのエディタとかないだろうから
Visual Studio Code + Git Graph
を使わせるのが一番いいと思う。
gitの機能がeditorに統合されているとやっぱり楽よ。 コミットの改ざんを直感的なUIで出来るアプリほしい
コミットをくっつけたり
変更範囲の広いコミットを分割したり
コンフリクトを解消したり すいません
初心者なのですが、以下の状況に陥りました
1.origin/masterからブランチAを作成した
2.作業が途中だったが、他の作業が発生したのでAをコミットせずにスタッシュした
3.origin/masterからブランチBを作成した
4.ブランチBをコミットしてorigin/masterへマージした
5.ブランチAの作業を再開しようとしたらコンフリクトが発生した
ブランチAのチェックアウトもプルもスタッシュの復帰もできないのですが、
どの手順でAの作業を再開すればよいのでしょうか？ >>258
6.テキストエディタでソースコードのコンフリクトした箇所を修正しAの作業を再開した
これだけ svn脳だと、ああコンフリクトしてしまったと天を仰ぎ
一体全体どうすればいいんだと嘆き悲しみ、大混乱が発生し
やがてコンフリクトとそれを引き起こした人に対して憎悪を抱くようになるが
git脳では日常的にある作業の一つでしかない >>259
以下です
The following untracked working tree files would be overwitten by checkout.
〇〇(ファイル名） コンフリクトしているのでもう一度スタッシュし直したら
チェックアウト時に上記のエラーとなりました。 だからテキストエディタでソースコードを修正してコンフリクトを直せと コンフリクトという用語を知らないなら
テキストエディタでソースコードを修正して動くようにしてコミットしろ >>267
>>258の話です
皆さん、ありがとうございました
とりあえずマージしてみます >>258
visual studio code + git graph
IntelliJ
みたいなテキストエディタ含めてgitと連携する環境をしっかり作ったほうがいいよ。
ややこしいコンフリクトもずいぶん楽になる。 >>271
>>266にしたいならマージよりもリベースじゃないかな GitだろうとSubversionだろうとコンフリクトしたら、一つ一つソースコード読んで正常動作する状態にエディタで修正するしかない >>270
とりあえずブランチAのコミットまで出来ました
ブランチAのチェックアウトが出来ないのはAに原因があると誤解していました
作業中のブランチに差分が出てしまっていたのが原因でした
お騒がせしました 何もできなくなる時がたまにあって困る
cloneからやり直し >>272
ありがとうございます
導入します
>>273
ブランチの途中コミットはそれほど大切ではないのでリベースにするかもしれません
>>274
慣れるよう精進します 途中コミットが大切ではないってのはリベースとスカッシュを混同してそう stashってさ、やってる事は臨時ブランチでコミットと同じ認識で合ってる？
イマイチ存在理由がよくわからんのだが あと存在理由がわからんやつは、プログラマじゃないだろうな
あれだろマージ担当者とかだろｗ その理解でいいと思いますけど、ブランチと同じように使おうとすると、別ブランチでpopしたときに悲しいことになります。(確か現在の作業領域にpopするだけでしたよね？)
自分だったら素直に臨時コミットを作ります。add . && ci -m "tmp"だけで済みますし。
あとツールの問題もあって、gitkを使ってるんですけど、最後にstashした位置にしか表示されないのでわかりづらいです。最近使ってないので直ってるかもしれないですが。 間違ってpopしたらまたstashするね
popが怖いなら常にapplyするね
stashにはHEADがstashを指すことがないので現在地を意識不要という利点もある
楽さを取るか、作業ブランチ一本槍のシンプルさをとるか、好きにするよろし stashが起点に縛られないという性質は、割とどこにでも適用できるという利点の裏返しでもある
急なインスピレーションで作業開始して、あとで然るべき適用先を探すようなアブノーマルさも優しく受け入れる懐の深いいいやつ 俺はdiffをファイルにしておいてあとでpatch適用するわ windowsでdiff-highlightを使う方法を教えてください github上に残したくないあるディレクトリ以下のファイルを全て履歴から削除したいんですが
コミットするときにそのディレクトリだけでなく、他のディレクトリの残しておきたいファイルも一緒にこみっとしてます
どのように履歴から消せますか？ >>301
具体的な手順はいくつかあるが、例えば
不要ファイルを削除するコミットを作って、rebaseして不要ファイルを追加したコミットにsquashしてやる。 めんどくさ
コミットをエクスプローラーで開いてセーブしたらコミットが上書きされる単純明快な機能があればいいのに そんなことができたんじゃ何のためのSCMでリポジトリなんだかわからんな。 変更履歴を管理するというとイミュータブルな印象を受けるけど
実用上は別にイミュータブルである必要はない
というか履歴を後から整理して追跡しやすくしたほうがメンテナンス性は上がるのだからむしろミュータブルであるべき 例えば物理的なコミットAには論理的な変更1と変更2が含まれてるとしてだ
* コミットAの後ろに新規コミットBを挿入
* コミットAをチェックアウト
* 変更2を手動で取り除く
* コミットAを保存
とすると履歴が変更1と変更2に綺麗に分かれる
こうしたほうが履歴が遥かに綺麗になる
SCMはこういう操作がもっと直感的に簡単にできるべきなんだよ >>304
どうやって複数のファイルの修正を一つのコミットにまとめるんだ？（苦笑） >>308
* 変更2を手動で取り除く
* コミットAにgit commit --amend
* CTRL+Zを押して変更を手動で戻す
* コミットBとして保存
もっと簡単にできるが？ >>310
エクスプローラーにそんな機能はありません
新しい機能の仕様を書いてください こうかな？
git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch フォルダのパス'
BFG Repo-Cleanerを使うともっと性能がいいらしい >>313
直感的だろ
前のコミットを修正して
次のコミットを追加するだけだ 別にいいんでないの？
pushするときにコミットまとめる機能があれば エディタとかエクスプローラの操作でgitコマンドが発行されるソフトを作ればいいんでないの まんまTortoiseGitの設計思想っぽいな
ディレクトリツリーに加えて歴史という時間軸があるからエクスプローラという枠を大分越えてるだろうけど
しかも今回みたいなお題はTortoiseではなくfilter-branchみたいに時間軸に対して効くコマンドを使わないと手作業が増えて堪んないと思う 巻末（？）の妹「ワンピースみたいな漫画かいてよ！」
→わんぴいすというこんな漫画を書いてるよ
は涙モノなのにな GitHubなどのサイト上では、ファイルごとの履歴を見ることはできないのでしょうか git diff --name-onlyで削除したファイルは表示しない方法を教えてください >>325
Historyをクリックしたら見れますよ >>327
完全に見落としていました。ありがとうございます。 >>326
git diff --name-only --diff-filter=d かな？ 「わかばちゃんと学ぶGit使い方入門」という本を読んでるのですが、
140ページのコンフリクトの解決って、本の通りにできますか？
元々のmasterは5月6日開催なのに、5月6日の方を採用したら、
変更なしになってコミットできなくなってしまうのですが。 git subtreeでハマってます。どなたかお助けを。
まず以下のコマンドで別のプロジェクトのHogeを取り込みました:
git remote add Hoge <HogeのURL>
git subtree add --prefix=sub/Hoge --squash Hoge master
で、Hogeのmasterで変更があったので、取り込みたいと思い
git subtree pull --prefix=sub/Hoge --squash Hoge master
これが Can't squash-merge: 'sub/Hoge' was never added. というエラーで
失敗してしまいます。実際 git subtee add の時点でsub/Hogeにはちゃんと
ファイルができてるんですが、never added とはどういうことなんでしょう。 subtreeをaddしたということを一度pushしなくていいの？ >>333
ああすみません、subtree addのあと、commit, pushをしました。
あと省略してしまいましたがsubtree pullの前にはgit remote add Hoge <HogeのURL>と
git fetch Hoge masterをしています。 Git ってソースコードなしのアイデアノートみたいなの投稿しまくったら怒られる？
公開しなければ大丈夫か、公開しても大丈夫か、そもそもダメなのか
バージョン管理できて過去に間違った事書いてたのも確認できたら良さそうだけど あ、ごめん、GitHun のことね、もしくは GitLab でも 法律とか条例みたいなものまでGitHubで作る時代になにいってんの 誰に怒られるんだ、githubの利用規約を気にしてるのか？
gitで管理できるものなら何でも、常識の範囲内で使えるサービスだと思うぞ master から main に名前変えるって話上に書いてあるけど、
git blame の方が嫌な名前じゃね？
日本人ですら抵抗感じる名前なんだけど それを言ったらkillコマンドもダメだな
なにも悪いイメージの言葉を全部狩ってやろうって話ではなくて、ポリコレ的に問題になるのは差別と通じるものがあるかどうか
程度問題や是非はさておき、差別は基本的人権を脅かすのが理由
blameは非難という和訳だけで覚えてるとキツいけど、blameが持つ責任の所在を明らかにするという概念を認識しているネイティブにはそこまでキツく感じないんだと思う black listに黒人差別は関係ないという話は
無視されたわけですが 黒人を少しでも悪く言えないように黒人の話題を全て書き込み禁止にしてほしい Git v2.30.0-rc0
Git 2.30-rc0 Released With More Work On "Main" Branch Renaming, Fixes
https://phoronix.com/scan.php?page=news_item&;px=Git-2.30-rc0-Released あいつら上級地球民だから
俺たち下級とは違うんだよ
もちろん100%皮肉な gist コマンドって、git と違って、何かしら技使わないと grep できないってことでいいん？ エロ画像管理に向いてる？
エフェクト掛ける程度です ローカル死ぬと怖いから秘密守ってるれるホスティングサービスあると嬉しい >>353
ローカルをディレクトリごとバックアップしときゃいい >>353
暗号化ストレージにリモートリポジトリ作ったら？
git-secretとかgit-cryptもあるみたいだな。使ったことないけど。 あたしの彼氏、今日の俺は今日だけのワンタイムトークン！とか
携帯を勝手に覗き見てトークンチェック！とか言ってくる…
もぅﾏﾁﾞ無理。 GitHubってパスワード使えたのか？ SSH認証だけだと思っていた。 みんな SSH でやってるでしょ
ほとんどの人が影響なし 前いたとこはみんな https でやってて credentil.helper でパスワード保存してたな
これも使えなくなるのかな まあ確かに会社のPCに秘密鍵置いておくと
取られる可能性はあるからな
そのPC固有のトークンのほうが安全か
もちろん俺は秘密鍵にパスコードかけてるけど 2段階認証あるある:
割とでかいコードをチェックアウトするためにコマンドを走らせたままにして後で見たら、
認証が期限切れになっててチェックアウトが全部失敗していた。
面倒な世の中になった。 作り話やろ？ｗ
認証は最初に1回やるだけなんだから gitとgoogleToDoがリンクしたらいいなーと思っている
思うだけ >>376
あああの渡辺満里奈と結婚した...
自分は今でも人に物を頼むときについ「タノムサク」と口走りそうになることがある。 macではgitconfigのPAGERに何を指定したらいいのでしょうか？
macにlessが入ってなくて .gitignore.gitignoreってこと？ .の右側の名前が拡張子だけど
こんな質問するようなカスがGit使うのかよ ドットファイルはLinux系の命名ルールで、Windows系以外では拡張子にあまり意味がない
.gitignoreの拡張子はgitignoreであるとも言えるし、拡張子はないとも捉えられる
ドットファイルの拡張子は何かという質問自体にほとんど意味がない
どのように扱われるかはツールやコマンド次第 >>385
ありがとうございました
>>382-384
もうちょっと分かりやすく質問したほうが良かったですね
ごめんなさい windowsのexoplorerで拡張子表示しない設定がデフォだが
.gitignoreの様ないわゆるドットファイルは全部表示されなくなるのか 試してみればいいだろ。どうせWindowsを叩くネタ探ししてるだけだろうけどなｗ >>387
表示しないのは登録されている拡張子だけでは？ 俺は許す。だが第二、第三の許さいないやつが登場するかもしれないがな！ まあ使う分にはコミットがスナップショットでも差分でもどっちでもいいけどな
しかし、>>390でgitが過去のバージョン管理に比べて動作が速いのが納得できた
頭のいいやつの考えることは凄いわ まじめな話 git のコミットは思想的にはパッチセットだけどな。
古い rcs系はスナップショットとして管理して内部的には差分として保存。
gitは逆でパッチとして管理し内部的にはスナップショットとして保存。
この辺が技術的に面白いところだけど、混乱したりバカな記事書いたりするやつが多い。 どういう意味？
～で管理して…で保存、の前後が何を言ってるのかわからない
管理と保存の違いを詳しく教えてくれ はてブコメントを見てると勘違いしてる人が結構いるのがわかる gitがリビジョンを差分で管理してるみたいな勘違いは何年たっても減らないな
これとかもそうで、はてブとかでボロクソに言われて逆ギレしてるし
https://qiita.com/kaityo256/items/81e7951a1ca2706955a4 >>401
内部的にはスナップショットで持ってるけど、管理の単位（コマンドの操作対象）はパッチセット（差分集合）ってこと。
前者と後者の区別できないやつ（前者だけ主張するやつと後者だけ主張するやつと両方いる）が変な誤解が湧く原因。
stash とか例外はあるけど、内部実装の議論しないんなら git ではスナップショットとか忘れて良い。一方で内部実装からむならスナップショットが特徴。 gitのコミットがスナップショットであるって基本原理を理解しておかないと、コミット間の差分比較が速いとか、リポジトリが肥大化するとか、svnの部分チェックアウトとか、gitの長所短所の理由を理解できない 長所の「理由」とか知ってる必要ある？
普通に使うだけなら理由は知らなくても結果の特徴だけ知ってれば十分。
ガソリンの燃焼の仕組み知らなくても車は運転できる。
技術者なら知っとけ損はないから、とは思うけど使う上で必須ではない。
それより内部実装と管理対象の混同の方が問題。嘘主張するくらいなら内部実装は忘れてもらった方が。 管理の単位ってなんのことか知らんけど、git diffするにしたって、Git内部のどこかに差分ファイルがあってそれを表示してるんじゃなくて、スナップショット間でその都度差分作ってる
だからSubversionと違って、任意のコミット間、任意のブランチ間の差分も素早く作れる
逆にこのせいでSubversionに劣る機能もある コミット毎にスナップショットを保存というのは、データサイズはやっぱりでかくなるん？
そのへんのトレードオフは割り切ってる感じなんかな？ 連レスごめん
個人用のメモとかのリポジトリでも、あんまり頻繁にコミットするのはデータ量増えてくだけだからよくなくて、
１日ごとの記録をまとめてコミットしたりとかの方がいいのかな
「コミットはドラクエのセーブみたいなもんだ」ってのを最初に見たから、なんか「こまめにセーブ」しちゃうんよね
プライベートリポジトリで > 「コミットはドラクエのセーブみたいなもんだ」ってのを最初に見たから
それが本なら捨てたほうがいいレベル
バージョン管理というのは「バージョン」を管理するためのもの
バージョンというのは機能の違い
このバージョンで追加された機能、修正された機能はなんですか？
という質問に答えられないようなコミットは作ってはいけない ここでいってるバージョンっていうのは1.0.0みたいな
公開用バージョンじゃなくて1コミット＝1内部バージョンっていう意味な
リビジョンとも言う 困ってないのにデータ容量とか速度を気にするやつは
素人の証拠だろうな うん、パブリックな作業だとそうなんだろうけど、
プライベートで作業してるメモとかのリポジトリの話ね ちょっとググったら、コンセプトレベルだとスナップショットで保存してるという事になってるけど、
実際にデータストレージに格納する際は、普通にデルタで管理してるみたいね
https://stackoverflow.com/questions/8198105/how-does-git-store-files >>410
内部で圧縮だとか重複排除だとのかの機能が働いてるのでテキストなら全く気にすんな。
変更箇所が小さいということは他のスナップショットとの間での重複が大きいので、その分圧縮がよく効いて結局小さくなる。
逆にいうと重複排除や圧縮の効かない画像や音声などのバイナリは小さくならないのでディスクを食いまくる。 肥大化するのは、Gitがブランチ作りまくって運用するって思想なのもある
DLLとかアセットを大量に扱いやすいゲーム開発でSubversionが好まれやすいのは、Subversionがバイナリーもデルタで管理するから ブランチ作りまくるのは、ブランチ作ったほうがいいから
gitだからブランチを作るのではない
作りたいから作るのだ
作りたいのにsubversionは面倒だから
作るのが億劫になる 上にもあるけど、blob/tree/commitの違いを意識しないでスナップショット/差分の議論をしているから混乱するのかなと思った。
それと"パッチ"と"スナップショットでないもの"（=同じ内容を重複保存しない）も混ぜてるのも混乱の元だと思う gitはスナップショットと言っていいと思う。
blobは厳密にスナップショット。
tree, commitもスナップショット。ただし、すでに保存されているblob, treeがあるときはハードリンクする。
これでどうだ。 BLOBが完全にスナップショットってことは
平均100バイトのソースを通算100万回変更してコピーが作られたとしても所詮100MB単位なので問題なしとして
100MBの神Excelを1000回コミットすると100GB肥大化しちゃう？ GitのホスティングサービスってGitHubとかBacklogとかどこも1ファイル100MBまでとか全体で2GBまでとかに制限してるか、または推奨してる
Gitとしては巨大なリポジトリは分割して複数のリポジトリで管理するのを良しとしてる ただ、GoogleとかFacebookとかApache Foundationとか巨大なシングルリポジトリでソース管理してるとこも多くて、そういうとこじゃGitは使えない Androidはrepoという、沢山のgitレポジトリを集めたようなやつになってるよね。
でルートの.repoというディレクトリの下が結構でかくなる。何十GBとか。 >>425
それgitの制限の話なの？
ホスティングサービスとしての容量制限じゃないの？ それくらいがリポジトリ分割の目安ってこと
GitHubとかBitbucketとかたいていのプロジェクトで使うし >>429
いや説明になってないけど
技術的にgitの限界というなら知りたいとこだが バージョン管理システムはソースコードを管理するためのもので
差分見たり、ファイルの一部分を取り入れたりできなければ意味がない
100MBとかソースコード（テキスト形式）ではありえないようなサイズは
Git LFSを使ってファイルとして管理するのが推奨されてる >>417 >>422
このレベルの理解でドヤる奴が多いので混乱する
だいたい >>422 の理解でいいのだけど、
Packfile という仕組みで blob はスナップショットから別のblobとの差分へ変換される
この仕組みはコミット時に動くのではなくて、適当なタイミングで非同期的に行われる
ほぼ公式のこれ読んどけ
https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-Packfile >>422 のハードリンクというのは違うか、同じハッシュを参照するだけ >>435
コミット（というかインデックスファイル作るときなのでadd）したときにはスナップショットが作られる（記事内のlooseオブジェクト）けど、
gcで差分に変換される（=packfile）ってことか。勉強になるわ。
差分はどういうフォーマットなの？たぶんdiffではないよね？
あとハードリンクってのは概念的な類似(inode)から口走っちゃったけど、>>436のつもりです。ブランチと同じようにハッシュ向けるだけ。 >>416だと保存しないとトリガーが発動しないから保存を忘れてしまえば効果が無いな 一番最初のコミットしたファイルにパスワードが含まれるファイルがあるので
パスワードを空にしてそのコミットを修正する方法を教えてください
そのファイルは２回目以降にもぼちぼち編集してますが
パスワードの行は変更しておりません >>439
BFG Repo-Cleanerを--replace-textオプションで実行 Git って今、SHA-1 と SHA-256 どっち使ってるの？ git switch と git branch があったら、git checkout ってもう使い所ないですか？ 自分のHTMLやcssの履歴を残したいのでgitを使い始めたのですが、
コミット(B)した後に、1ファイルの1行だけ修正してからコミット(A)してしまって
前々回のコミット(B)に取り込んで、コミット(A)を消す事はできるのでしょうか？
コミット(B)をrebaseをしてintaractiveを選んだのですが、コミット(A)は消えず
変化もありませんでした、Visual Studio Codeを使用しています >>444
--> B --> A を
--> B'(B+A) にしたいってことですね。
interactiveを使おうとしているということはコマンドラインは使えますね。
git reset --soft @^ && git commit --amend です。
Aの先に既にコミットしている場合や、作業領域がダーティの場合は、このコマンドではダメなので言ってください。
慣れてないなら、コマンド実行前に git rev-parse @ で表示される文字列をメモっておいてください。 gitとgithubが似たような仕組みって昨日知ったわ
ありがとう >>445
rebase用にファイルを用意してみたのですが、
rebaseテスト> git reset --soft @^ && git commit --amend
&&は前のコマンドが成功したら次のコマンドを実行するとは思いますが、
発生場所 行:1 文字:21
+ git reset --soft @^ && git commit --amend
トークン '&&' は、このバージョンでは有効なステートメント区切りではありません。
&&は対応していないようです。
前のコマンドだけ入力してもエラーでした。
rebaseテスト> git reset --soft @^
fatal: ambiguous argument 'g': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]' 最後のエラーが謎い…環境を教えて下さい。
・gitのバージョン
・コマンドラインを実行しているシェル(bashではない？)
git reset --soft HEAD^
これはどうなります？ >>448
Visual Studio Codeで動くpower shellだと思います
> git --version
git version 2.24.1.windows.2
でした。
> git reset --soft HEAD^
変化がありました！
自分のレスを引用していますが
>>コミット(B)した後に、1ファイルの1行だけ修正してからコミット(A)してしまって
コミット(A)が消えて、直前に戻ったという感じです。
コミットのアンドゥと言ったところでしょうか。
そのままもう1度同じコマンドを打つと、内容を保持したままコミット(B)が消えたので
そこでコミット(B')みたいな形ではやりたいことはできました。
VSCodeのResrt to Previous Commit -> --soft を押しても同じ結果になりました
2回soft resetをしてからコミットするという感じで目的は達成できそうですが
最初の目的であるrebaseが動かなかったのは何か条件があるのかな・・ 目的は果たせたようでよかったです。
powershellは分からないですが、たぶん@と^は使わないほうがいいんだろうと思います。 皆さんってGUIのGitツールって使います？
使っているとしたらオススメとかってありますか？ GUI使うのはIDEのgit連携機能くらいですかね
Visual Studioとか SourceTree使ってるけど、バージョンアップで時々変なバグ入れてくるのでおすすめしない gitkでツリー確認して操作はコマンドラインだな。 TortoiseGitばっかり使ってる
エクスプローラとの連携が便利だからね、、 皆さん、情報提供ありがとうございます。
参考にさせていただきます。 質問させて下さい。
開発の為に開発用branchを作り、開発が完了して、master branchにマージした後、その開発用branchは削除すべきなのでしょうか?
仮に削除するのだとすると、開発用branch内の履歴が消えてしまうような気がするのですが、なにか良い方法はありますか?
よろしくお願いいたします。 >>458
fast forward マージをした？
git log --oneline --decorate --graph --branches --tags --remotes
↑
これを使ってみて >>451
git bashは一度起動させたらそのまま移動して使い回す
更新履歴見るときだけgitk呼んでる
操作自体はgit bash
過去の履歴が使えるので専用シェルは都合が良い
@win10 tig便利
元々Linux使ってたけどGit for Windowsに付いてくるようになって嬉しい mingwのコマンドいっぱい入っているからcygwinがわりにもなるな。 git reset --soft <commit>
<commit> を省いた時の動作って、
git reset --soft HEAD
と同じ意味になる？
マニュアル見ても書いてないように思うんだけど
つまり、
git reset --soft
ってのは、reflog で見れる足跡情報が増えるだけで、
それ以外にはなんにもしないコマンドって理解でいいです？ man git-reset の最初の何行か読めばそう書いてあるだろ The <tree-ish>/<commit> defaults to HEAD in all forms. Windows で開発してるうんｋなんで、
git bash を VS Code で植え込んだ時におならが出るくらい感動した powershell はコマンドが長ったらしいだけでもう無理
エイリアス設定できたとしてももう無理
なんか powershell 開いただけで蕁麻疹出る >>472
ちょっとどこが良いのかその良さを bash とか zsh とかと比較して語ってみて powershellは
bashやzshより使いやすい すまん、プレステとサターンどっちが強いってイキってる小学生から成長してないやつがいるとは思わなかった
アレルギーって自分で分かってるんだから好きなの使えばいいのにね 利点を教えてと言っただけなのに、何でどちらが強いとかイキってるとかの話になるんだ… 無理、無理、蕁麻疹出ると畳み掛けた奴が「教えてと言っただけ」と嘯くか
こういう輩が被害者ぶってる様を見る方がよっぽど無理だわ そういう喧嘩はどうでも良くて、
普通に powershell に利点があるなら知りたいだけなんだけど
自分は powershell 全然使い込んでないし >>481
教えてくれてありがとう
スレお気に入れてチェックだけはしといてみるよ PowerShellは.NET Frameworkが使えることが最大の利点。
それ以外のメリットがないのが最大の欠点。 >>483
そういうのをやりたければPowerShellスレでやれ
git関係ないだろ マイクロソフトの影響が強まっているから仕方ない部分もある 質問です
あるプロジェクトをgit cloneしてローカルでbuildしたのですけど、
その中で必要なSDLのソースが404でダウンロード出来なくて、中断する状況。
メンテナに聞いてみたら"update the git hash."とのこと。
「HASH更新するのね、了解」って思ったんですが、それってどうするの？状態です。
gitのオプション見ても適当なコマンドは見たらないし、cloneしてbuildする位しか
git自体使ってない程度なのでさっぱりさんです。
どなたか教えてください。 ぬ、了解です。
github.com/EmuELEC/EmuELEC
で、Odroid Go Advance用にmake imageしたもので該当エラーになります。
build環境はamd64のdebian9です。 package.mkのPKG_SHA256弄るっぽいです。
すんません、git関係無いかも。 >>489
これで正解だったようです。
お騒がせしました 質問をさせて頂きたいのですが、
GitはGPLらしいのですが、注意することはありますか？
例えばGitを用いて公開したコードは商用利用出来ないのですか？ ライセンスに関わることは正確にやりたいこと言わないと答えられないぞ
なおGPLは商用利用を禁止していない >>492
gitのソースコードを修正する時になったらまた来てください
それまでは何も気にする必要はありません git「で」ソースコードを修正するときではなく
git「の」ソースコードを修正するときです GPLのソフトを組み込んだソフトもGPLになるんだよね
gitを組み込んでる商用IDEはソース公開義務を持つのかな？ gitのソースコードを修正しない限り自由に組み込める
いくらコピーしてもOK。自分で作った部分のソースコード公開の義務はない 答えてくれた方ありがとうございました
>>493
Git(やGitHub)でWeb上に公開したコードについてですが、
まあ大体は商用利用ではないと思うのですが、
後々になってお金を頂くようなものを作る可能性もありまして
でも大丈夫なんですね
>>494
つまり、Git自体のコードをどうこうするのではなく、
Gitのサービスを単に利用するだけであれば、
GPLはあまり気にしなくていいということなんですかね？ >>498
GPLは、
a) gitユーザーに自由にgitを使ってもらうために、
b) git開発者・gitを組み込んだプログラム開発者を制限する
ライセンス。
a,bの違いを意識しないといけないからちょっと面倒。 >>499
ありがとうございます
GPLって書かれてるとちょっとビビってしまいます GPLで作られたソフトの「ソースコード」を
どうにかしない限り、何の成約もない >>501
GPLのコードを静的リンクしたらGPLに感染するし、動的リンクもグレーじゃない？ GPLの解説読むとGPLソフトを組み込んだソフトはソース改変してなくてもGPLライセンスになってしまうようにしか受け取れないけどな >>502
動的リンクは OK、スタティックリンクは OUT とか、もうほとんど意味不明ですよね
そもそもハードディスクも物理メモリも、メモリ空間も富豪的な現状で、動的リンクの存在価値はどこにあるのでしょうか？ >>502
せやね。リンクしない限りOK
>>503
>ソース改変してなくてもGPLライセンスになってしまう
それはなにをしてもそうならない
ライセンス違反になるだけで、勝手にGPLライセンスになることはない
もし「○○○ライセンスになってしまう」というライセンスの強制上書きが許されるとしたら、
オレオレライセンスを組み込んだソフトは、どんなライセンスのものでも
オレオレライセンスになってしまう。というライセンスだって作れる。
GPLだろうがなんだろうが、そこにオレオレライセンスのソフトを混ぜると
GPL等のライセンス効果はなくなって、オレオレライセンスになってしまう
という強力なライセンスを作れると思うか？
>>504
そういうことだな。標準入出力でやり取りするブリッジプログラムを作れば
GPL感染すること無く利用することができる > GPLソフトを組み込んだソフトは
これは、同梱という意味じゃないことに注意
当たり前だが、DVDに一緒に配布してもGPLライセンスに感染しない
それはRedHatなどがやってること
LinuxディストリはGPLとそれ以外を一緒に配布している >>505
ライセンス違反にはなるけどしらを切れというスタンスか >>507
例えば、逆にGPLのソフトが間違って、互換性がないライセンスのコードを使ってしまったとしよう
もしかしたらそのコードは有料で利用可能にしているコードかもしれない
悪いのはそのGPLソフトだ。どうすべきだと思う？
そのコードを消して謝れば許す？
それとも損害賠償すべきだと思う？
それともGPLのライセンスを、別のライセンスに変更すべきか？ >>507
なんか誤解してる。
ライセンス違反だとしても勝手にGPLになったりしないってこと。 ライセンス違反したことは悪いが、
だからといってGPLに変更すれば許してやるよというのは
傲慢な脅しに過ぎない
ライセンス違反した場合に、GPLに変更するのは
ライセンス違反とい問題を解消するための、選択肢の一つでしかなく
両者の合意、または裁判によって個別に決めることでしかない
GPLに変更することで大損害を受けるのであれば、それは選択肢にならない
その場合は損害賠償を行うことで解決することになるだろう
合意が取れない場合に裁判を行うと、結局そうなる
GPL（事実上無料）にどれだけの損害を認められるか知らんがな
まあGPLを使ったことによる利益とかから算出されるんじゃね？
どうでもいい部分の利用程度なら、損害の程度も低いだろう いちいち裁判で争ってたら仕事にならんからやっぱりGPLは避けるのが無難だな ライセンス違反しなければいいだけだろ？
リンクしない限り何も影響なく
自由に利用できる せっかく開発者が自由に使ってくださいって提供してるんだから
便利に使ってやらなきゃ可哀想だろう
LinuxだってGPLだ。便利に使える。 >>504
GNU公式見解では動的リンクもOUT
Linuxカーネルがとりあえず動的モジュールOKなのはリーナス含む大勢の著作権者が不問にしてるだけ
そして動的リンクの意義はLinuxカーネルみたいなものなら自明だろう >>514
私には自明にはみえませんが‥‥
カーネルモジュールのことをいっているのですか？ >>516
ドライバ全部入りのカーネル使いたいの？
それともドライバ組み込むたびにカーネルリンクしたい？ どっちにしても配布物にGPLなソフトウェアを同梱しなけりゃセーフ 余計なリスクを抱えるのは避けたいからBSD・MIT・Apacheライセンスのライブラリを使うわ ライブラリをGPLにしてしまうと、静的・動的リンクのためライセンス違反になるので
そうならないようにライブラリ用にLGPLというライセンスが存在する
GPLのライブラリのほとんどはよく読めばLGPLになってるはず >>517
MS-DOS では必要に応じてデバイスドライバを後から読み込むことができますが、MS-DOS のデバイスドライバを指して「動的リンク」とは当時は言っていませんでしたよね…
またアプリケーションに関しては、動的リンクはトラブルのもと（アプリではなく動的ライブラリが原因、とか、アプリの記述で手を抜くとアプリが暗黙に得体の知れないところの動的ライブラリをしれっとリンクする、とか）だった気がします
いわゆる Windows の DLL HELL ってやつですよ‥‥ 例えばglibc（GNU C Library）はLGPLなのでリンクしても問題ない
https://en.wikipedia.org/wiki/GNU_C_Library
License LGPLv2.1 >>522
LGPLはもともとLibrary GPLという名前だったことからもわかるように
ライブラリ用のGPLとして作られた
https://www.weblio.jp/content/GNU+LGPL
> LGPLとは、コピーレフトの考えを導入したGNUのライセンスのことである。
> 以前は「Library GPL」の名称で呼ばれていた。
>
> LGPLはGPL（GNU General Public License）をベースとしているが、
> LGPLの元で公開されたソースを利用したソフトウェアを開発しても、
> その独自開発部分のソースコードの公開を強制しないという特徴を持っている。 >>521
LinuxはWindowsでいうDLL HELLを避けるために
全てのパッケージが使用するライブラリを厳密に管理してる
それがディストロの仕事で、例えば次のUbuntu 21.04をリリースすべく
いま頑張ってる作業の内容がそれ
Linuxでは一般に動的ライブラリのユーザーによるインストールが
事実上禁止されてる（動作保証しない）ことによりDLL Hell相当を防いでいる
しかしそれではライブラリのバージョンが古くて困るので
独自作成のアプリ（どちらにしろ動作保証がない）では
好き勝手ローカルディレクトリにライブラリをインストールしたり
Dockerを使ってアプリにライブラリをバンドルしているｗ >>525
＞好き勝手ローカルディレクトリにライブラリをインストールしたりDockerを使ってアプリにライブラリをバンドルしているｗ
WWWWW >>521
MSDOS界では歴史的にリンクでは無いかもしれないが、Unix界では歴史的にドライバはリンクだよ
動的にロードできるようになった今でもDOSとは違ってロード時にシンボル解決してるし gitからzipでダウンロードして
ソースいじったりしてるやついるの？ >>527
DOS の時代であっても、一旦 OS が起動しきって command.com に制御が移った後であっても、任意の時刻に追加でデバイスドライバをロードすることは可能でしたよ‥‥
まあ DOS 的にはデバイスドライバには厳しい縛りがあるのでデバドラと動的ライブラリが同一とは主張したりはしませんが
ただ一ついえることは、2021 年現在、DLL が本当に必要なのか？という疑問はもっともっと考慮する価値がある、という点でしょうか ここでGitHubについての質問もしていいですか？ >>531
ですよね～
>>532
そんなスレッドがあったんですね
ありがとうございます htmlとcssをローカルでgit管理しているのですが、
たとえば商品ページみたいなのを作っていて、cssなどを触っている時に
トップページのcssを1行だけ変更するとなると、
細かく言えば、商品ページの部分ではない部分のcssを触るのですが、
コミットしてしまうと、2つの目的が同じコミットになってしまいます。
編集部分が異なるところを分ける扱いとかはできるのでしょうか？ コマンドラインから git を利用するプログラムは GPL に感染しない
git のライブラリを直接読んで実行するプログラムは感染します（動的リンク）
ICO っていう PS2 のゲームは、GLP 違反で廃盤になってます（ソースコード公開しやがらなかった）
RMS の団体がいくつか訴訟起こしてるみたいだけど、
日本でGPL関連の裁判は多分いまだに一個もない
そもそもGPLの強制力自体法的にグレーらしいからね
多分日本で裁判起こされても負けないと思う 仮に裁判に負けないとしてもいちいち訴訟起こされたら仕事にならないし時間の無駄だからGPLのライセンス違反は避けとくわ git checkoutで過去のコミットに戻ったあと、元いた未来のコミットに進むにはどうしたらいいの？ あ、git log --all & git checkoutでいけました。 git checkout -
でよくね
ICOもワンダと巨像も名作だったな git-checkout -
You may also specify - which is synonymous to @{-1}.
へぇ～しらなかった。cd - みたいだね。 git switch -
でもいいんやで
ところで、コミットメッセージ編集しても
コミットハッシュに影響しないようにするってのは駄目だったのかな
git の仕様的にコミットメッセージがコミットハッシュに影響しなきゃいけなかった理由ってなんだろ
これさえなければ、専用エディタとかでホイホイメッセージ編集しまくれそうなもんだけど ゴリゴリ適当に作業して適当にコミットしたい時ってない？
後で rebase で整理するのめっちゃ大変になるんだけど…
コミットせずに、
たまに別のブランチに移りたいときとかはスタッシュ上手く使えばいいのかな？ >>543
わかる。
特に理由はなくて、そこまでやる必要を感じなかっただけだと思う。
俺もコミットメッセージはメタデータなのでコミットのハッシュに含めるべきではなかったと思う。
ただしメッセージも履歴をとっておくべきだと思うので、ハッシュを個別に取って、両方合成でコミットを管理するとかだな。
ソース側のハッシュだけで新しい方にマッチするようになっていれば良い。 >>545
新しい方決め打ちじゃなくて選択させろという
要求でたらというか普通に出るから
最初から今のようにメタデータ込みの方がシンプル >>543
コミットメッセージまで含めて署名つけるためじゃないの？知らんけど 分散バージョン管理を何だと思ってるんだよ
履歴は複数のリポジトリに存在する可能性がある
特定のハッシュを指定すればどのリポジトリでも同じ履歴を指すのが重要
それなのにリポジトリ毎にコミットメッセージが違う可能性があるとか有り得んわ >>544
ブランチ作ってそこでガンガンcommitすりゃいい
で、後でまとめてmerge ―squash git notes はオワコン
github も表示するのをやめた
https://github.blog/2010-08-25-git-notes-display/
Update (August 14, 2014): Displaying Git notes on GitHub is no longer supported. 初歩的な質問をさせて下さい
作業用のディレクトリ内にREADME.mdファイルを作成したのですが、
このファイルはコミットした方がいいんですか？
それとも.gitignoreファイル内に記述して追跡されないようにした方がいいですか？ >>555
>>556
ありがとうございます
>>556
このリポジトリは練習用です、のような秘匿性は全くない内容です >>554
コミットしたほうがいいよ
このリポジトリをクローンしたひとが最初に読むことを書いとくといいよ そのリポジトリはGitHubとかにホスティングするの？ >>559
GitHub等のホスティングサービスでもいいしオンプレにgitサーバー建ててもいいしお好きにどうぞ >>558
>>559
ありがとうございます
>>558
分かりました
>>559
はい、GitHubのリモートリポジトリにコードを挙げようと思っています
コードも練習用で秘匿性はありません git svn使っててSVNサーバーが移動すると
対処法(svn switch --relocate相当)が微妙でちょっとドキドキしたわ
いろいろやり方あんのな
テスト用のリポジトリ作っていじり倒していると
半日ぐらいすぐに吹っ飛ぶのでヤバい gitの使い方について質問させて下さい
なんちゃってgit-flowっぽい運用をしています（開発中のブランチはdevelop）
ウォーターフォール型？のプロジェクトを複数人で開発しているんですが、担当範囲の
単体試験が終わるまで一切pushしないメンバーがいます。
そのメンバーいわく「UTが終わってない時点で正常に動く保証が無いのだから、そんな
コードはdevelopにpushしない」との事なんですが、これが一般的な考え方なんでしょうか？
結果、ものすごい量の修正がなされたソースが開発フェーズの最後にどかんとpushされて
プルリクがくるのでとてもレビューしきれないし、確実にコンフリクトも起きます
開発の最中って、各人のコードをどのくらいの頻度でプロジェクト共有のdevelopに
取り込むのが普通なんでしょうか？ >>563
コミュニケーションとfeatureの規模の問題でないだろうか。
・コミュニケーション：
一人はfeatureが固まるまではdevelopにマージしないのが普通と考えている。もう一人はdevelopが壊れてもいいから（そういうことでしょ？）マージしてほしい。
これは会話をしたり規約を決めて解決する問題だと思うね。
表面だけ見れば、個人的にはdevelopは壊したくないので同僚に一票。
理由としてはfeatureは担当者の私物に近いが、developは共有だ。参照されるライブラリを書いているような状況では、利用する機能を壊しかねない。他人に迷惑をかけるコードをマージしたくない考えには賛同できる。
文字通り（devへのマージでなくてfeatのまま）pushしてくれないということだとしたら、その必要性を伝えてみたらどうかな。
あなたが進捗を把握するためにpushしてほしいのか、レビューを先に細かくしておきたいからしてほしいのかは知らないけど。
あなたが熱心に説得しても、もし同僚が聞き入れないのであれば、それは柔軟性や協調性の問題であるから、上司に相談してみるといいかもね。（性格がPJに合わなかっただけなので、個人批判はしないこと） >>564
・featの規模の問題：
頻度はわからないが、どかんとコードがpushされるというのは、featに切り出した問題が大きすぎるのではないか？
開発方法が詳しくわからないが、アジャイル開発でやるようなプランニングポーカーでもやってみたらどう？
あなたが思っているよりも複雑で大きな機能なのかも。
レビューが大変なら、簡単になるようなサイズまで切り出してみたらいいんじゃないかな。
・あとは考えたくないけど、能力不足：
担当者か、レビュアーの能力が足りていないために、苦労している。
担当者目線では難しい機能で、時間がかかってしまい、フェーズの終盤までかかってしまう。
レビュアー目線では、担当者のコードを読み解くことができず、平均以上に難しさを感じている。 >>565
・最後に：
プルリクのコンフリクトは、feat担当者にマージできるように作らせるのがオススメ。（「develを壊さないようにfeatを作ってください」）
プルリク出す前に再度develからfeatにマージさせるようにすれば解決できる。（これ自体はgit flow標準ではない）
また、一定以上のコンフリクトが発生するものはacceptしないなど。
平和的に解決するように頑張ってください。 もう一点だけ補足。
説教になって申し訳ないです。
業界の普通を知ることは当然大事で、普通のことを普通にできるようにするのは大切なことなのですが、実際はチームの数だけやり方があります。
なので普通に合わせるよりも、うまく行かない現状がうまく行くような方法を適宜考えていくのが最もうまく行く方法だと考えます。
Gitと関係ないことを連々と失礼しました。 >>566
同感
コンフリクトが多くて実質マージ不能なプルリクは却下でいいだろ >>563
なんとなく問題は、本流以外だと動作確認しづらい何かがあるんじゃないかという気がする。
つまりgit以外の問題なんじゃないかと。 >>571
masterからmainへの名称変更は前回のv2.30で一段落付いて、
今回は普通のリリースになりそうです。 >>566
>>568
ローカルで最新devをマージしてコンフリクトを解決するのがgit flow標準になっていないのは、何か理由あるのかしらん？
後のリクエストに修正義務を課すのはわかりやすいルールだと思うけど、問題あるのかな？ 標準にしてないだけじゃないかな
プルリクとは限らないから、自分でマージしたっていいし 「Git」v2.15以降に任意コード実行の脆弱性 ～v2.30.2へのアップデートを
https://forest.watch.impress.co.jp/docs/news/1311031.html
「Git LFS」が“git clone”を実行する際使われる遅延チェックアウトの仕組みに脆弱性があり、細工が施されたリポジトリから任意のコードを実行できてしまう問題(CVE-2021-21300)が修正されている。
この脆弱性は「Git」v2.15以降に影響し、最新版へ更新することで解決できる。何らかの理由でアップデートが難しい場合は、以下の緩和策が推奨されている。
・“git config --global core.symlinks false”を実行して「Git」のシンボリックリンク対応を無効にする
・プロセスフィルタのサポートを無効にする
・信頼されていないリポジトリのクローンを避ける >>579
もしかして、gitとgithubを混同してる？ GitとGitHubを混同するのは、GitHubを使ったことのない初心者だからね。
書籍での説明もPCにGit、インターネット上にGitHubがある使い方を前提とした説明ばかりだから、一緒くたになるんだと思う。 知識レベルとしてはアスカの言うギフハブ=悪の組織と変わらんなw error: 7332 bytes of body are still expected MiB | 14.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
ゴミ
DL数稼ぎみたいなクズ gitのアカウント持ってるかって聞かれたことある？ あるよ。もってるならそのアカウントを会社で使うし
持ってない人や会社とは別にしたい人は新しく作る
今はしらんけど無料アカウントは複数持てないので
どちらかを有料アカウントにする要津がある gitのアカウント持ってるか聞かれて、bitbucketとか自前のホスティングサービスみたいなのを答えたらどうなるの？
こいつ空気読めねーなみたいな感じになるの？ そういうときに本当に空気読めないのは「えっ？gitにアカウントなんてないですよ」って言うやつじゃないか？ gitのアカウントも知らないんですかと馬鹿にしたように言われて
噛み合わないまま Gitのアカウントもあるからな。
Gitのローカルユーザー名が、OSのユーザー名だと知らないのもイタいな。 WebデザイナーがGitHubのGitしか、説明しないからおかしくなる。 どこにでも入り込んでくる
まるで覗き趣味の変態みたいだ ギフハブの正体
岐阜への移住応援サイト GIFU×HUB
https://docodoor.co.jp/web/gifuhub/
岐阜県への移住を応援する悪の秘密結社だった（？） 日本三名泉の心地よさに身も心も籠絡されてしまうわけか >>600
お前まだいたのか。何が犯罪的でgitが何故共犯なのか説明してくれよ kernel.orgにgitのコマンドや引数が網羅されているドキュメントがあったと思うんですが
URLをご存知の方おしえてください まさかと思ったけど、もしかしてmanページのことか？ おれもそっちのほうがいいと思ったんだけどkernel.orgの方を探しているみたいだったので… git add . とgit add -A とgit add -A .は何が違うの？
次の認識でいい？
1つ目が、カレント以下のディレクトリのみを更新(add, modify, remove)
2つ目がレポジトリのルートから全部更新
3つ目は1つ目と同じ。 windowsのandroid studioで、git/githubで管理してるプロジェクトがあるんですが、OSを新規インストールしてandroid studio/gitも新規インストールしました
ただ、プロジェクトは別のドライブにあるのでそのままですが、続きをやる場合は何が手っ取り早いのでしょうか?
一旦プロジェクトを削除してgithubからcloneしなおす以外に方法あったら教えてください >>620
Android Studioで別ドライブのプロジェクトをそのまま開けばいいのでは >>621
そうですか
githubのアカウントなどのリモートリポジトリの情報はどこに格納されてるのかなと思いまして
別のドライブのプロジェクト内に保存されてたらそのまま開けばよさげですが、その情報削除されてるならどうやって続きをと思った次第です >>615読んで気になったんだけどPR出してから歴史の改ざんって出来ないかな･･･
セルフチェックせずに勢いで出してからあそこ違う、ここ、そこもとなってforce-pushのログで汚れてしまった 他人のリポジトリに勝手にブランチ作れるわけねーだろ どういうこと？
取り込まれる前なら出し直せばいいし、
取り込まれたらもうできないでしょ 他人のリポジトリにforce-pushしてんのか
恐ろしい恐ろしい プルリク後にforce pushするとGitHubの方に記録が残ってしまう話では google colabでgithubから自作パッケージクローンしてpipインストール
その後、自作パッケージを変更してpip uninstall後に再pipインストールしても更新されない
colab内でpip showで辿った自作パッケージのソースコードは変更されてるのに。。
colabの「ランタイムを出荷時にリセット」てやってからだと当たり前だけどきちんと更新される
が、地味に時間がかかる・・
gitに限ったことじゃないけど
github + google colabで開発してる人はどうやって対応してるんだろ リベースして消えたけど 0666060 というコミットIDができたｗ featureブランチでの機能追加とテストが完了した後masterへのマージでコンフリクトが発生した場合、逆マージ(masterをfeatureにマージ)とリベースどっちで競合解決するのが普通なんでしょう？
身内で以下のような感じで意見割れまして
>逆マージ派
コンフリクト解消前のコミットログがそのまま残るので、コンフリクト解消後のテストで解消前には発生しなかった不具合が起きた場合に原因を追いやすい
Gitは切り戻しを担保するのも役割の一つであり、ログの見やすさのために情報を欠落させるべきではない
>リベース派
コンフリクト解消のコミットログは機能追加において本質的な修正ではなく、履歴を追う際ノイズになるので残すべきではない
コミットの単位が適切であればコンフリクト解消時にミスがあり不具合が発生したとしても原因特定に苦労することはない > コンフリクト解消前のコミットログがそのまま残るので、コンフリクト解消後のテストで解消前には発生しなかった不具合が起きた場合に原因を追いやすい
実際には追いにくい 逆マージの問題はマージが2回発生すること
featureブランチへのマージしたと
それをmasterブランチにマージしなければいけない
その仮定で二重にコンフリクトが発生することがある
ログの中に同一内容に見えるコミットが複数含まれることになる >>636
プロジェクトごとに考えは違うと思っていて、何を大事にするかで変わると思っている派の意見として聞いてください。
個人的には逆マージを採用します。
理由としては、コンフリクト解消のコミットを除けばfeatureの変更もリベース同等にわかりやすく、featureブランチの担当者に負担をかけないので、バランスがいいと思うからです。
解消のコミットが本質でないのはそうですが、避けられないものなら、feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられると思います。
リベースの場合は、上に書いたことの裏返しでもありますが、場合によってはコミット集合を作り直す必要があると思います。
また、作り直している間にmasterやdevが更新されてたりすると、ああ面倒。このようなケースで、コンフリクトが起きる頻度は、PJの規模や同時に走っているtopicの関係にもよると思いますが…
逆マージでは最後に払うツケを、リベースでは毎回払う可能性がありますよね。わたしはそれが開発のスピードを損なうノイズだと思っています。もちろん規模によります。
でも後で見たときにはキレイなので、そこにはメリットがあると思います。
保守性のためにコミットをきれいにしておくのは大切だとは思いますが、経験上diffとblameでなんとかなる場合が多いと感じていて、将来必要とされないことに時間をかけるくらいなら、現状の開発速度に重きをおいた方がよい、というのがわたしの主張です。
的を外していたらすみません。 >>637
解消前後でテストがpassかfailの二択なので追いやすいと思う。
追いにくい具体的な状況ってどういうものですか？ ありがとうございます！
>>639はほぼ私が考えていることと合致していて安心しました
>>638のケースは作業自体はリベースの方がかえって大変ですよね
逆マージはその代わりもっとログが汚くなるのでトレードオフかなと
>feature実装と解消を分けて考えられるので、不具合があった場合の混入原因の特定のしやすさ→その後の改善にも繋げられる
特にこれが正に私が逆マージ派である理由なんですが、>>637は意見対立してますね
できれば>>637の理由が聞きたい… >>636読んで逆マージ派なのかなーという気はしていましたが、
リベース派の知人の意見を整理してみるのもいいかもしれないですね。
リベース派の理由が曖昧な感じがします。
コミットの単位が適切であれば…苦労することはない、の部分が理由としては弱い気がするので。
まあここには省いて書いたのかもしれないですが。 あ、適切という言葉に客観性がほしいという意味です。
ここでは原因の追いやすさが、2つの立場の焦点だと思うので、
その適切さがどのようなものであれば、どう切り分けできるのか。 リベースで何度もコンフリクト発生するのって、単にfeatureの切り出し方が不適切だったり巨大なPRがずっと居座っていたりするように、開発のフロー自体に問題があるんじゃないの？ > コミットの単位が適切であれば…苦労することはない、の部分が理由としては弱い気がするので。
「コミットの単位が適切であれば苦労することはない」は理由じゃなくて事実
逆マージってログを見ないでしょ？
残っていればOK。あとから頑張れるはず（希望。実際には頑張ったことはない）
見ないログはなんの役にも立たないし汚いログも見れないのでこれも役に立たない
>feature実装と解消を分けて考えられるので、
分けて考えてる時点でダメじゃん
リベースしてしまえば、実装だけしか考えなくて良くなる
バグが見つかった時、実装と解消の２つがあれば
実装のバグかも知れないし解消のバグかも知れない。
バグの可能性が２つに増えてしまっている
リベースしてしまえばそれがなくなる
> あ、適切という言葉に客観性がほしいという意味です。
いきあたりばったりで作業するなということ
どうせ、こう修正した、気分が変わってやり直した、レビューの指摘があったから変えた
バグが見つかって対応した。って同じ箇所を何度も修正したのがコミットに残ってるんでしょ？
このコミットをあとから見て役に立つとでも思ってんの？
一連のブランチである箇所のコードを修正しているコミットを一つに保つように
随時リベースしていれば何も困らない。masterが更新されるたびにリベースしていれば
何も困らない。コンフリクトがほぼ発生しない。それが適切ということ コンフリクト解消のコミットでバグを作り込みやすいと考えるのか、それが重視されるほどのリスクではないと考えるのかで選択が変わるんじゃないかな
順不同で両方取り込めば済むようなほんの小さなコンフリクトであればrebaseの利点のみが優勢になるし、複雑なコンフリクトであれば逆マージの利点が優勢になる
複雑な解消作業までrebaseで混ぜてしまうともったいないし潔癖が過ぎる感じ
その辺をガイドラインにしつつ線引は各人のこだわりに任せるのがうまく回りそう >>642のおっしゃる通り友人の言うことがよく理解できてなかったんですが>>645でおおよそしっくり来ました
その上でもやはり、あるfeatureリリースによって別の機能がデグっていることが判明した場合などにおいて、逆マージコミットが残っていた方がよいのではないかと思いました
コンフリクト解消にてうっかり失敗したのか、新機能実装において意図を持って変えたのかが明確になるからです
>>646の仰るとおり複雑なコンフリクトであれば逆マージにしてそれ以外はリベースすると言うのが個人的な結論になりそうです 逆マージした後にさらにまとめコミットを作ってマージするのはダメかしらん？
（squashの手動版）
手間がかかるけど、詳細も概要も両方残るからマシな気がするけど。 > >>646の仰るとおり複雑なコンフリクトであれば逆マージにしてそれ以外はリベースすると言うのが個人的な結論になりそうです
複雑なコンフリクト＝開発に失敗したブランチ
開発に失敗したから逆マージするしか手がなくなってる
仕事だと期日まで仕上げろと言われて、みんな諦めるが
これがきっちりとしたオープンソースの開発だと、そんなものマージできませんでリジェクトされる >>646
> コンフリクト解消のコミットでバグを作り込みやすいと考えるのか、
「コンフリクトの解消でバグが発生」という事自体がナンセンスだよね
だって開発自体は問題ないって認識なんでしょ？
開発自体に問題ないのに、コンフリクトでバグが発生するというのなら
それはもはや、コンフリクト解消という名の追加開発じゃんｗ
開発終わってるのに開発続けてどうするの
マージが問題なく完了できるという所までが開発でしょ？ >>647
> その上でもやはり、あるfeatureリリースによって別の機能がデグっていることが判明した場合などにおいて、逆マージコミットが残っていた方がよいのではないかと思いました
> コンフリクト解消にてうっかり失敗したのか、新機能実装において意図を持って変えたのかが明確になるからです
いやさ、なんでコンフリクトが発生するのか理解してないの？
masterとブランチの両方でコードを修正したときなんだが
masterの修正は他の人がやってる。
コンフリクトが発生するってことは、他の人がやった開発内容を把握してないということ
コンフリクト解消時に他の人がやった開発内容を把握するなんて大変な作業をやるんか？
同じ箇所を修正してるのに、お前のコードはその他人の開発内容を踏まえた修正になってないだろ
ちゃんとテストしてるんか？してるわけないよなコンフリクト解消時に判明するぐらいなんだから
コンフリクト解消時に、ついでに一緒にって追加開発するなよ
近い場所を修正したときなど、簡単な修正が必要なコンフリクトは発生することはあるが
あとからコンフリクト解消の内容を精査するなんてことがあること自体がおかしい 無能が作成したブランチ無理に取り込む必要あるのかよ 人よりできるようになってくると、自分より劣ってる人にひどい言葉を投げる現象に名前をつけたい。
ところで、自分も作業の分割に根本的な問題がある気がするね。
でもそれはこれから解決していってもいいんじゃないかな。早いほうがいいけど。
目下進んでるPJの対処法が的でしょ。どの程度火が付いてるか知らんし。 アルファシンドローム（権勢症候群）かな？
集団の中で一番知識があるとまるで有能で卓越した存在になったかのような錯覚に陥る
しかも上司や同僚に評価・尊敬されないとこういうところでくだを巻くように 100M以上のファイルを ignore って出来る？ >>657
100MB以上の大きなファイルはignoreできないとかそんなアホなことある訳ないと思うけど 今の作業コピーとは別ブランチに直接ファイルをコミットって出来ないかな
ググると「ブランチを切り替えるにはチェックアウトですよ」とか「stashで中身保存出来ますよ」とかあるけど
そうじゃなくて、今の作業コピーは1ファイルも弄くらず直接別ブランチにコミット叩き込みたいの。 別フォルダに変更入ってほしくない
とにかく、今の作業コピーにある.git フォルダの中”だけ”を修正して欲しい
究極的には .git/objectsにファイルオブジェクトとtreeオブジェクト、commitオブジェクトの合計3オブジェクトを作って(コミットするファイルが1つの場合)
ブランチの宛先を差し替えればいいんだろうけど。
git write-tree、git update-indexって面白そうなコマンドがあるから調べてみるか 一個前にコミットした内容の一部のみ取り出したいんですが、
git diff でgit add -pみたいなやり方教えてください git rm ./path/to/file
だとオートコンプリート出来ない
git rm path/to/file
は大丈夫
なんで？ git bashで試してみたけどできるな
つまりおまば環 macのzshだと駄目なようだ
macでもbashだと行ける master 撲滅運動がひと段落したら、今度は、
'doc: replace "alice" and "bob" examples'
とか
'Avoid gendered pronouns'
とか言った感じのメールが流れている。
アメリカのリベラルとか大変ですな。 FemaleやNiggerを連想させるのでダメざます アルファがベータをカッパらったらイプシロンした。なぜだろう。 cliだけで特定のコミットのタイムスタンプを（両方とも）改竄したいんだけど
git rebase -i後のエディタが開いて操作対象のコミットを選ぶ奴、コマンドラインから直に指定するにはどうしたらいい？ rebase -iでは無理なんじゃないかな
filter-branchを使えばエディタ無しでできると思うけど凄く面倒臭い
今はfilter-branchじゃなくてfilter-repoが新しいらしい 非インタラクティブに操作したいのに--interactiveオプションを指定するのは筋が悪いのでは
reset --hard で対象に移動
commit --amend で書き換え
rebase --onto で残りを接ぎ木する
てな感じでできないだろうか project/prog/app
という構造のappディレクトリのみcloneすることはできないでしょうか？
sparse-checkoutを試してみたのですが確かにappだけ落ちてくるけどその上のprogフォルダも作られてしまいます
作業ディレクトリの中にappだけ作りたいんですけど可能でしょうか？ 部分cloneは無理だから巨大なのには関わりたくないんだよね
ガチ勢としてやるならともかくね 新人が分散VCSの概念理解できてなくて
プルリクエストのブランチの履歴をめちゃくちゃにしてる件
自分が何をしてるのかよく分からずforce pushしたっぽい >>689 にも関係すると思うんだけど、
ブランチをpushできるユーザを制限できないかな
慣れてない人向けのサンドボックスなブランチにもなるし。
自分も最近ブランチの運用を教えたものの、
わざとなのか理解してないのか、別のfeatureブランチにpushする輩がいてなあ。
gitlabには有料プランでそういう機能があるみたいなんだけど、ビルトインにはないよね…？ >>692
うちの新人は操作するブランチは合ってるのだがめちゃくちゃにしてた
git慣れてないからって事で先輩が代わりにコミット結合しつつrebaseしたらワケワカメになったっぽい
その先輩、新人に他の人がブランチをrebaseしたら
reset --hard origin/hogeするように連絡してなかったのかも >>692
write権限付けなければいいだけだろ リポジトリごと別にしたら？
新人用のリポジトリ作ってそこにコミットしてもらい、問題無ければマスターへは権限者がマージする。 みなさんありがとうございます。
writeの権限ってなんでしょうか？receive.denyDeletesとかnoFFマージの制御があるのは知ってるんですが、ブランチのpush権限を制限できましたっけ？
あとすみませんMRって聞いたことなくて教えて下さい。
それとhookは担当者のPCにレポジトリごと設定が必要だと思うんです。忘れちゃうと思うんですよ。
いろいろコメントいただいてありがたいんですが、知識が追いついてないみたいです。
よかったら教えて下さい。 >>698
素のgitでサーバー運用してんの？
ちゃんとアクセス権設定できるgitサーバー使った方がいいと思う はい、質問の趣旨は素のgitで、できるかというものです。
上でコメントもらったwrite権限とかMR？とかいうものは、素のgitではできないものですか？
それともリモートにhookを仕込むなどして権限制御ができるんでしょうか？
gitlabはブランチの権限を設定できるみたいですが、freeプランには無いみたいですね。 gitlab使ってるわけじゃないんだ？
ブランチを直接いじらせたくないメンバーはforkからマージリクエスト(MR)投げてもらうようにすればいいんだが。 ああ、マージリクエストのことでしたか。
gitlabは使ってないです。
社内標準がtracについてるやつなので、レポジトリは素のgitだと思います。
なので、ビルトインでできることがないかなと探してます。
クラウドだと難色を示されますが、gitlabはオンプレミスで構築できたと思うので、情シスに打診はしてるものの、それでも乗り気じゃないみたい…
まあこれは弊社の問題なのでおいとくとして、gitの設定だけでできるなら、やり方教えれば動いてくれるかなと。 素のgitでは出来ないと思う
gitlabは環境を変えなきゃならん可能性があるから情シスは嫌がるだろうね
giteaとかのバイナリ一個で動作するのならいいかもよ GitBucketはバイナリファイル一個だけで動くね GitLab自鯖にインストールしたことあるけど重すぎワロタ
アンインストールもできなくなるほど瀕死の操作不能になった WindowsでDocker Toolbox使ってVirtulaBox上のDockerコンテナとして動かしてもそんなに重くはなかったがな。 >>707
最初は軽いんだけど、使ってくと段々と重くなるんだよな
軽くする方法がわかんなくて、結局使うのやめた アイヤー
MSのコード真似るAIに喰われるとはおもてもいなかたアルね filter-branchはじめて使ったんだけどこれって失敗することあるの？
なんかコミット全部に影響出るからこわい >>721
テスト用ブランチ作ってからやるべき。
古いブランチはそのまま残ったはず。 >>719
FSFが「GitHub Copilot」に疑問視、ホワイトペーパーを募集
https://mag.osdn.jp/21/08/04/131400
具体的な関心領域としては、
「著作権を侵害した公開リポジトリ上でトレーニングしているのか？ フェアユースか？」
「Copilotのアウトプットが、GPLでライセンスされている作品を侵害していることを主張する可能性はどのぐらいあるか？」
「Copilotが生成する侵害に対して、開発者はどのようにして自分が著作権を持つ任意のコードを保護できるのか？」
などを挙げている。 >>727
汝、gitはギットと読み
gifはジフと読むであろう
決してジットと読むなかれ 今githubめちゃくちゃリモートリポジトリ失敗する githubの使い方を勉強しています。
githubのDefault branchがmainとなっているのですが、[git branch]と打っても表示されません。
プッシュしようとしても main は存在しないと出てきてしまいます。
master が表示されているので、そこにプッシュすることはできましたが、ブラウザ上で最初に表示される
ブランチがmainなので、もやっとします。
何か対処方は有りませんでしょうか？ githubの話題はここじゃないと何度言えばわかってもらえるんだ 別の人が聞いてるんだから何度言ったところで終わりなんてないぞ
そういえば>>1やテンプレに誘導がないので、書いておけば少しは減るかもな リポジトリのすべてのコミット履歴から特定の文字列を削除したいんですが良い方法無いですか？
filter-branchするしかないでしょうか？ すみません
filter-branchでやりました 20ファイルぐらいあるんですが今、filter-branchで1つずつ削除しています
たぶん土日潰れそうです >>30
去年のレスで申し訳ないけど
VSCodeやxcodeだと、git statusで差分があるファイルの色を変えたり 表示を絞り込んだり出来るじゃん
ちまちまコミットしているとそれが出来なくなる(コミットする度に差分が無くなって特別扱いされるファイルが減る)
のが困るんだけど、どうにかなりませんか Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html
第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます BFG便利でしたよ
bfg replace-text password.txt myproject.git
でpassword.txtに指定されている文字列を置き換えできました
git grep $(git rev-list --all)
しても問題の文字列は綺麗になってました そろそろCVSからGitに移行しようとしています。
CVSからのリポジトリの移行の方法としてググってみたところ、cvs2git というのと、 git cvsimport ってのがあることが分かりました。
ところがcvs2gitはダウンロードしようとしてもサイトがもう閉鎖(?)されているようで入手できません。
cvsimportにしても、git-cvs の導入が必要で、自分の環境ではGitに合わせて2.27が必要そうなんだけど、やっぱり入手先が見つかりません。
誰かご存じの方いれば教えてください！
当方の環境とは、CentOS8にGit2.27.0を入れています。 >>748
gitには今の最新のソースからリポジトリを一から作って
過去の変更履歴を参照したければcvsから見る、って運用ではダメなの？ 特定のバージョンが必要なら一旦それ入れれば良いだけだろ
要は変換できる環境で変換してしまえばできたものを持ってくればそれで良いんだから おお、皆さんコメントありがとうございます。
>>749
CVSを無くすことが目的の一つでもあるんです。
で、変更履歴が見れることも必要です。
>>750
SVN経由ですか。
できるなら避けたいですが、ちょっと調べてみます。
>>751
その通りなんですが、CVSからの移行をサブシステムごとに行うので、それなりの期間（多分1年以上）変換できる環境を維持する必要があるんです。
いろいろありがとうございました。
全ての要件を満たしてというのは難しそうですね。
いただいた意見を参考にもうちょっと検討します。 git cloneする時にsshのurl指定でBranchまで指定する事って出来るの？
-bとか使わないで >>753
それ出来ないと思う
海外サイトで@でブランチ指定とか/でブランチ指定とかでやれるって書いてあるサイトも見つけたけど
実際やって見ても全然上手くいかねぇ ガチでない用途、雑多スクリプト集とかは平気で半年コミットしてないのとかあるんですけど
ローカルディレクトリをスキャンして最終編集日 - 最終コミット日の数字が多い順に表示して
いい加減コミットするか編集内容破棄するかしろと警告してくれるツールとかないですか リモートのHEADをリモートのdevelopを参照させるようにしたいのですがやり方がさっぱりわかりません。
とても単純なことのように思えるのですがどの方法でやってもSourceTreeなどでクローンするとmaster参照してて困ってます。
origin/HEAD -> origin/master
教えてくださいお願いいたします。 こうなってます
.git]$ ls
COMMIT_EDITMSG HEAD branches description index logs packed-refs
FETCH_HEAD ORIG_HEAD config hooks info objects refs
というか僕何か勘違いしてるかも。
要はSourceTreeでクローンしたとき最新のコミットをHEADが参照してほしいのです。
そうしないと上に登ってってチェックアウトしないとだから。 shallow clone（--depth 1）で特定コミットの指定な
git cloneにdepth指定はできるが
同時に指定できるのはタグやブランチ名だけで
SHA1で過去のコミット一つだけみたいな指定はできない
なぜかgit fetchではSHA1指定とdepthの組み合わせが出来るらしい
解せぬ >>99
番号割り振ればできるだろ、知恵を絞れよ
何のために頭付いてるんだ、大学生にもなってなんだその頭の悪さは
gitのせいか、gitのせいでそんなに頭の悪い人間になってしまったんだな
ようし、gitを禁止します ブランチ切り忘れてコミットしまくったあとに
過去にさかのぼってブランチを作成して
全部そこで作業していたことにしたいんだけど
どうしたらいいかな？ 今いる場所でブランチを作成
元のブランチはリセット 間違ってコミットしまくったブランチをまだpushしてないなら
コミットしまくった最後のコミットで新しいブランチ作って
間違ってコミットしまくったブランチの方を「git reset --hard origin/間違ったブランチ」とかすれば良いだろ？ git bashでlsの実行結果が文字化けしたらコレ
export LANG=$(locale -uU) echo "export LANG=$(locale -uU)" > %USERPROFILE%\.bashrc 知っている方いたら教えてください。
CVSからGitに移行しようとしてます。
開発にはEclipseを使っていて、今はEclipseのプラグインでCVSと連携しています。
Git用にはEGitというプラグインが必要ということはググってわかりました。
EclipseでEGitを使う場合ローカルPCにGitの導入は別途必要ですか？
ネットで見た例だと、EGitで直接GitHubのリポジトリを指定してたんだけど、EGitを使えばリモートのリポジトリに直接アクセスすることになって、ローカルにリポジトリは作らない（なので、Gitの導入は不要）という理解であってますか？
事前に試せる環境がないため、経験者のかたがいれば教えてもらいたいです。 >>771
gitはローカルリポジトリでコミットしてからリモートリポジトリにプッシュする二段階の仕組みなので、ローカルにgit「クライアント」は必要。（gitクライアントにローカルリポジトリを操作する機能が存在する） >>772
ちょっと補足。
Egitは使ったこと無いからは詳しく無いけど、解説とか見るとEgit+eclipseで一通りのgit操作はできるみたい。ただ、gitの仕組みとして（通常の利用方法だと）必ずローカルリポジトリを使うので、ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。
逆に、gitはリモートリポジトリ無しでローカルリポジトリのみの運用というのができるから、まずはそれで色々と試したら？ >>771
Eclipseを使ったことはないが、こんなのを見つけた
https://www.casleyconsulting.co.jp/blog/engineer/223/
>EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。
https://wiki.eclipse.org/EGit/FAQ
>What are the main differences between original Git and JGit(EGit)? >>771
egitは現在のeclipseに含まれています。
別途PCにgitのインストールは不要です。 >>772,773,774,775,776
ああ、こんなすぐに親切なレスがいっぱい！！
> ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。
そうですよね。だからGit本体も必要じゃないかと思ってたんです。
>EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。
Gitそのものではないけど、Gitと同じ動きをするJGitが使われているという事ですかね。
それでEclipse+Git関連の記事でもGitのインストールについて特に触れる必要がないと。
で、今時のElipseならEGitもついてくるんですね。Pleiadesのサイト見ましたが、確かにEGitもパッケージされてますね。
JGitでググってみたら紹介してくれたwikipedia以外にも日本語で紹介/解説しているサイトがいろいあるみたいなので、まずはそちらで勉強してみます。
モヤっとしてたのがスッキリしました。
またここで追加質問しちゃうかもしれませんがよろしくお願いします。 個人で開発してる場合に、subversionと比較してGitのほうが優れていることってどんなことがありますか？
Git使ってみてるんですが、ローカルリポジトリとリモートリポジトリに別れてるのが面倒くさく感じてしまうんです。 個人でやってるならリモートリポジトリを使う必要ないよ
別の場所にバックアップしたいときだけ稀にプッシュしておいてもいいかな程度
Gitはブランチ開発が圧倒的に便利
次バージョンの開発をしながら、ヤバいバグを見つけたらスイッチして現行リリースにパッチを当てるなんて作業がやりやすい
コミット等の操作を間違えたときの復元方法も充実してるからガンガンコミットするスタイルが身についてロスがない
あまりにも小規模な開発しかしてないならGitに移行したところで便利さに気付かないかもね svnはもう使わなくなってから何年も立つけど、ローカルブランチ作るのに全コピーが発生する問題は改善されたん？
gitは瞬間的にローカルブランチ作れることが、当時、最大のメリットだと個人的には感じてたけど svnも物理コピーしてるわけじゃなくポインタをコピーしてるだけだからそこは別にデメリットではないと思う ローカルで何でもできるのとrebaseできるのが大きいな。 --filter=blob:noneでcloneしたレポで久しぶりにpullすると
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 334 bytes | 334.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 413 bytes | 413.00 KiB/s, done.
が延々続く
.git/configのpromiser=trueとpartialclonefilter=blob:noneを消すと秒で終わる
これは仕様？ >>792
git使うとmsに握られるというのが意味不明なんだが gitとgithubの区別がつかない人がMSアレルギーをこじらせている姿はもう見飽きた
情報のアップデートをできずに屈折した持論を垂れ流すから老害の部類かな すぐキレるLinusも若手から老害と言われてるんだろうな。 プライベートなリポジトリをローカルにcloneしようとしたら
重いファイル（15MB程度）だけ弾かれる・・どうして・・
ちなみに学習済みの.h5ファイル
何か制限緩和するような手続きしないといけないのかな
（ただ、google経由だと全部cloneできた）
全然わからん・・ 10年程昔からの自作のフリーウェアを git で公開しようとしているんだけど
あまり昔の version はもう環境が変わっていて動かない
動くものだけを公開した方が良いのかな
それとも最新のものだけにした方がいいですか gitの変更履歴より細かい単位で変更を戻したいとき、うまい方法はありますかね。
例えば一つのファイルの中で3つの関数を変更してコミットした後、1つの関数だけ
元に戻したくなった場合などに。 >>804
git rebase
1
2
3 ← ここで止める
4
5
1
2
3.1
3.2
3.3 ← こんな感じにコミット
git rebase --continue でリベース完了
あと慣れたら 2つの関数だけコミットして、
1つは戻ればいい >>804
pushする前ならcommit amend して修正してからrebase。
push後なら新たにcommit。 >>807
わかりづらいな……試してないけど
…56 3関数commit abc……master
ここをchechout -b mod
…56 3関数commit abc……master
[mod:2関数commit]
元に戻してcommit amend
…56 3関数commit abc……
mod abc……[master]
masterをchechoutしてmodにrebase
ただし、コミットを他人と共有済みなら混乱の元なので禁止。 >>804
履歴改変をするわけじゃないんだよね？それならば、
git revert -n でindexに三つの関数の修正を打ち消す修正を持ってきて、git reset -p でindexの余分な修正を取り除いて、git commit どうも>>804です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは
可能です（よね?）
なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。
例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく?
アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回
同じ変更を入力したくはないし危険... とかなんとか。 >>812
だから何をしたいのかはっきりしろ
pushしてないのは分かった
pushしてないローカルな履歴を改変したいのか？
pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか？ >>812
変更の用意はrevert -nとreset -pでいいだろ
この2つを使えば自分でコードを入力する必要は無い >>812
だから>>806だって
rebaseで過去の歴史の途中に戻って
そこでコミットを分けるなりして
再び歴史を再生する もう面倒くさいから一か所もどしましたってコミットしたらいいやん >>818
必要なのは結果だけ
お前が試行錯誤した後なんかどうでもいい >>817
そのコミットを簡単に作る方法が知りたいのだと思う >>820
Winmergeをdiffツールに設定して
git windiff HEAD^^^
で戻してcommitだな俺なら >>812
そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第
いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ
でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す >>812
そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。
機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。 追えてないけど、どれか。
・そもそもコミットきれいにしても結局使わないから作り直さない
・頻繁にコンパイル？して頻繁にコミットしておく
・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。
・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。 コミットをセーブ機能だと思うからだめなんだよ
袋だと思え袋
コードを書くたびに適切な袋に入れろ >>825
・追加機能ごとにブランチ切る
も追加で。 最近では、機能ブランチは問題を先送りにしているだけだという批判もある
機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ
それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには
マージの失敗でトラブルが起こることは日常茶飯事だったね それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね
何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める
互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし こういうコミットをしてたとして
$ git log --oneline
commit_id_5 やっぱり××を復活させる(2021/05/01)
commit_id_4 □□を修正(2021/04/01)
commit_id_3 ××を削除(2021/03/01)
commit_id_2 △△を修正(2021/02/01)
commit_id_1 〇〇を修正(2021/01/01)
「commit_id_3 と commit_id_5 を消して、コミットログをきれいにした状態でリモートブランチにpushする」というようなことは可能ですか？
こういう場合にgit rebaseが使われるんですかね？ >>832
ありがとうございます
てか真上に同じような質問ありましたね… >>831
俺は作りながら片付ける
作ってる途中で、この修正はこのコミットに含めよう
などと考えならが小さくコミットし
適度なタイミングでrebaseする >>831
別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ
これだとrebaseは不要 gitもcvs,svnと同じ運命をたどるだろう
私の企業は次世代バージョン管理システムfossilに切り替えました 次世代って書いてるけどGitやMercurialと同期だね
統合が特徴みたいだけど、少なくとも統合指向＝先進的というのは言えない
昔のMSや古いエンタープライズシステムが通ってきた道 >>844
gitを業務で使われている方は翻訳に参加してください すみません、git pushをこっそりキャンセルしたく
$ git reset --hard HEAD^; git push -f origin HEAD をしたのですが
To prevent you from losing history, non-fast-forward updates were rejected.
と言われてpushが失敗します。
もしかしてリポジトリの設定でこういう強制pushが禁止されていたりしますかね? サーバー側の receive.denyNonFastForwards の設定で禁止されてる >>848
git push --delete ～ でリモートブランチ消してpushしなおせばまだワンチャンある ブランチにアクセス権を設定できるサーバなら、メインのブランチにはプルリクエスト処理する人だけがアクセス可能にして、強制push禁止と強制ブランチ削除禁止の設定はいらん気もするね
でも本家gitにはブランチ単位のアクセス権は無いよね確か >>848
プロジェクトメンバーに周知すればいいんでないの？ pullする前にどれが変更されているか知ることは出来ないの totoiesegit使ってんですけ、コミットしただけでチェックアイコンに変わるんで
pushし忘れることが多いんですけど、区別できないんですか？ リポジトリにあさんが変更をプッシュしたことをいさんはどうやって知れるのですか？
あさんからいさんへメールなりで連絡？
いさんがフェッチなり、プルすれば分かるんですが・・・ >>865
本来gitで想定されている正しい使い方としてはメールで連絡
今時の普通のチームならGitHubでpull requestを出す 共有するリポジトリの置き場所に素のgitを使ってない限り、何らかの通知する仕組みはあるだろ？
素のgitでもスクリプト仕込めばできるけど面倒だな「git hooks 通知」でぐぐれ totoiesSVNの時はフォルダのアイコンが！に変わるから
logを表示させればだれが、どこを変更したか分かるけど
gitの場合、アイコン変わっていないから何時フェッチ、プルすればいいかわからない
こういうもの？ >>868
Gitでは、同じブランチの上で複数人が作業することは普通しない 同じことだよ
TortoiseSVNを使っていても他人の変更が勝手に降ってくることはないぞ
これまでほぼ無意識にときどき更新コマンドを実行してたんだろ
Gitでもそれと同じように無意識にときどきフェッチすればいい
リポジトリが新しかったりローカルが汚れているときにコンソールが赤とか黄色とかになる環境を作っておけばさらに分かりやすくなる >>870
その「更新コマンド」を実行すべきタイミングが分からないんですよ
とりあえずプルすれば、変更されていれば更新されるけど
変更されていなければ更新されない
いちいちメールかなにかで連絡もらえれば、プルするから実害はないんだけど git push したらｖｐｓのソースが更新されるようにしたのに、ヒミツ鍵でログインするタイプのvpsに変えたらgit pushでエラーが出るようになったわ >>871
気になった時fetchすりゃいいんだよ。 >>873
１分おきにfetchするアルバイト雇ったほうが工数的にはいいですね git reflogを時間指定して実行すると上手くログが取得できないんだが、自分だけ？
git logは普通に動く >>876
reflogで表示される時間はその操作が行われた時間ではなくてその操作の結果のHEADのコミットの時間で、reflogの--afterとかによる表示範囲判定は操作が行われた時間に基づいて判定されるぽいから、変な風に感じる？
HEADのコミットの時間でなくて操作した時間をreflogで表示する方法はあるのかな >>871
俺は開発ブランチにcommitした後にmasterをfetchしてる
で、マージすべき内容ならmergeする >>880
こういうのが居ると無駄なマージ履歴が残る。
コミットまたはプッシュする前にプルしてマージ完了した状態でプルするルールにしてる。 >>881
これはfetchかpullのタイミングの話であって、それとこれとは別の話だよ
それはpull request用のブランチにsquashなりすれば解決することだろ squashするとまた意味が変わってくる
無駄なマージコミットを気にするならpull --rebaseするといい 内容ごとにブランチを切って、実装完了後にマージしたほうがいい。
こまめにマージする必要あるけど。 rebaseすると途中のコミットが見たことないスナップショットに化けるから諦めてmergeする派 今からGitを始めます初心者の質問です。
Gitに設定するユーザー名、メールアドレスと
GitHubのアカウント作成で指定するユーザー名、メールアドレスは
同じものでないといけないのでしょうか？ ネットでgitをググると
コミットしたらﾌﾟｯｼｭっする癖をつけようなんて見かけるけど
それなら意味なくね 分散型リポジトリの意味かな？
つーかcommit→pushの流れが癖になるとまずいぞ
develop or masterで作業してるかfeatureブランチをpushすることになる >>890
同じにしないといけない
違ってるとGitHub上でコミットとユーザーが紐付かない
なおGitHubのメールアドレスは複数設定できる いつプルすべきなのかさっぱり分からないんだけど
いちいちフェッチして更新されてたらプルなの？
svnの時はフォルダのアイコンが変わるから、すぐ分かったんだけど
ｇｉｔはめんどくさくてしかたねー >>895
フォルダーのアイコンが変わるのはsvnの機能ではないだろw >>895
そもそもsvnの挙動を勘違いしてんじゃん >>894
レスありがとうございます。
そうしますと、
複数のメンバーでGitHubの一つのアカウント(リポジトリ)を共有する時の
各メンバーを識別するIDは、どこで指定するのでしょうか？ >>896
>>898
本筋には触れずに、否定をするﾜﾗ >>899
関係ない。各自が自分のGitHub userに設定済みのメールアドレスでコミットすればいい。
GitHub上で制御できるのは「誰がリポジトリにpushできるか」までで、>>900も言ってるがどんなメールアドレスのコミットが含まれていてもpushできる。
たまたまコミットのメールアドレスがGitHub userと同じならGitHub上でそのユーザーがコミットしたように見えるというただそれだけのこと。 >>899
githubでプライベートリポジトリを複数ユーザで共有する場合は、共有するユーザみんな別々のアカウント作って、誰かが作ったレポジトリに他のユーザを招待して、pushするときにはそれぞれ各ユーザのアカウントで認証された状態ですることになるよね
だから上でもだれか言ってるように、コミットのメールアドレスは認証で使われるわけじゃないから、どんなメールアドレスでもpushできる
しかし、コミットのメールアドレスは重要でないというわけでもなくて、コミット一覧とか表示させたときにコミットのメールアドレスに基づいてユーザ名とか写真を表示したりするので、githubのアカウントに登録してあるメールアドレスをgitの方にも登録しておくほうが良い >>901
少し上のレスを見ればわかるけど、その質問は「また釣りか」と思われてまともなレスは付かない。 とある本の不要になったブランチを削除する手順で
①リモートリポジトリの消したいブランチを削除
②Sourcetreeのフェッチのリモートで消えた追跡ブランチを消去(Prune)
③Sourcetreeの消したいローカルブランチを右クリックして削除
とありますが、①がリモートリポジトリのブランチを削除、
③がローカルのそれだとすると
②の手順にはどんな意味があるのでしょうか ブランチには①リモートブランチ ②(リモート)追跡ブランチ ③ローカルブランチの3種類がある
文脈によってこれらはしばしば混同されるので気をつけていないと混乱する
①はサーバー側にあり、②③はクライアント側にある
②は常に①のコピーで、フェッチするたびに①の最新と同期される
だからネットワークに繋がっていなくてもいつでもリモートのログが見れる
「リモートブランチのログを見る」というとき、正確には①ではなく②のログを見る行為を指す
フェッチしていなければ①②③が全て別のコミットを指すこともある
②を消し忘れると、サーバー側のブランチは削除済みなのに、そのクライアントからはまだリモートブランチが消えていないように見える 「Git for Windows」のシェルが「bash 4.4」から「bash 5.1」へ ～Vista対応も終了
https://forest.watch.impress.co.jp/docs/news/1402/011/
Windowsで使ってる人（居る？）注意な >>917
Windows Mac Linux
全部使ってる GUIのGitクライアントは面倒だよ
なんて言ってる先輩いるだけど
ほとんどコードは書けなくて、コピペしてそのコピペしたコードの意味も分かってない
そんなので、いくらgitが使えても意味なくね >>920
何が言いたいのがわからんが、コマンドラインでGitが使いこなせなくて悔しいの？
コードが書けるのとGitを使いこなせるかどうかは直接は関係無いし、コピペとGitを使いこなして目的が達成できてるのならばそれは意味があることだよ CUIなら同じことを繰り返したり再現するのも容易いし、スクリプトに組み込んで自動化したり本番処理を分けたり他人に渡すのも容易。
GUIも便利だけどCUIにもたくさんメリットがあるのよ 僕も全くプログラム書けないけど
フリーランスのGit屋だぞ GUIのgit使おうとしたけどわけわからんくて投げたわ
やっぱコマンドラインよ GUIもせめて自動実行マクロがあればマシなんだけどな。
OfficeのVBAみたいなやつ。 >>925
それgitコマンド使ったバッチファイルやスクリプトでよくね？ コマンドを打ってるだけで仕事してるフリしてる奴いるわ
たかがステージングするのに何分かかってんだよ
それならGUI使ったほうがグイっと終わるだろ CUIだろうとGUIだろうと、どのファイルのどの行をコミットに含めるかは慎重に選べ
ゴミみたいなコミット作ってんじゃねぇ >>920
gitを否定しようと思ったけどできなかったんだよね？
だからgitを使ってる人を変わりに叩いて
自己満足してるでしょ？バレバレｗ >>927
CUIのほうがGUIよりも快適だからCUIを使ってるんだよ
文字使えば相手に意味を伝えられるのに
絵を書いて伝えたいなんて思わないでしょ？ GUIで確認してCUIで実行するのが一番効率良くね？
GUIは一覧性が高いが、作業効率はCUIの方が良い st=status -s とか
ll=log --date-order --oneline --graphとか
alias設定すれば一覧性で困ることはないぞ それくらいのタイプ量ならエイリアス設定する方が面倒だわ 道具の方にこだわってる奴って本業は全然できない奴多いよな
この5番、30万だぞってイキってて100程度で回ってるガキ多すぎ宿題 道具にこだわらないからCUIでgitなんだろ
GUIのはOSによっては使えない場合もあるしいちいち覚えるの面倒だし
CUIなら設定ファイルちょろっとコピーすればいつもと同じ感覚で使えるし
git使わないって選択肢はもう無しな
gitはもう道具というより共通フォーマットだ >>933
その辺は頻繁に使うんでエイリアスじゃなくて3～4文字のシェル関数だわ
とくにgit logの方は--pretty=format:～も指定したいんで手打ちはありえん 基本的にCUI派だけどログ出していくつかdiffを見るみたいな操作はGUI使うなあ
これをCUIで高効率でやる手段があるなら知りたい >>936
CUIかGUIかなんて問題なのか
どっちでも同じじゃん
やっぱりコマンドをタイプしてる方がカッコいいと思うタイプ？w >>939
コマンドをタイプするのはかっこいいと思ってしまったから
お前はそんな書き込みをしたんだよね？ あるある
コマンドを使ってるカッコイイと勘違い
Linuxを使ってるカッコイイと勘違い
ダークテーマを使ってるカッコイイと勘違い
vi emacsを使ってるカッコイイと勘違い CUIかGUIかなんてどーでも良いことには一切こだわらず
俺にとって使いやすい方法を採用してる俺様ｶｺｲｲ >>942
そのとおり、何かを使っているからカッコイイのではない
俺だからカッコいいのだ プルリクって要る？
製品名出せば誰でも知ってるソフトの開発でも
目クラマージだぞ
正直、いちいちプルリク出すくらいなら、そっちでマージしてほしい
権限考え直してほしいわ アークマージって要る？メリットは何ですか？
→ イオナズンが使えます 先輩「CUIのほうがgitの機能をすべて使えるからいいよ」
おれ「pullするときにディレクトリを指定するのは、どんなコマンドを実行すればいいですか？」
先輩「git pullしかやったことないから分からない」
おれ「・・・」 ディレクトリを指定してpullする機能なんて無いし
pullに引数指定しなければいけないような状況はfetchとmergeを使うから、おれもgit pullの引数有りの挙動は把握してない おまえらって本質がわかないのか？
pullかどうかなんてのは本質でない
git hoge
でも論理は同じ ちょっと例えがアレだったね
シニカルなことを表現するときはバシッと一発で決めてかないとこういう残念な雰囲気になる
それもまた世のことわり CUIの方がgitの機能がすべて使えるのは正しい
CUIで使う人が全てのコマンドのオプションを知ってる必要なんてない
CUIで使うのを難しく考え過ぎじゃないかな？
どのgitコマンドで何ができるかを把握できてれば十分で、細かい指定は大雑把に覚えてればいいよ
良く使う操作は短いエイリアスやシェル関数にしてしまうし、普段あまりやらない操作はコピペでもいいし、man見て調べればいいし、いまのシェルは履歴も補完も使いやすいからgitの長いオプション名なんて覚える必要も無い 別にCUI/GUIに限らないけど、どのgitコマンドで何ができるか何が起こるかを理解できているのが重要
gitのコマンドは後戻りできるものが多くて、その方法を理解できてると楽に使える
後戻りする系の手段はあれこれ用意されてるけど、CUIの方が充実してるかな git pullしか実行したことないなら、GUI使ってもボタン一発だろｗ git pull はコンフリクトで失敗することがあるからボタン一発で済むとは限らない CUIに劣等感感じる必要ないんやで
どっちも便利だから好きな方使え GUIとCUIの併用だな
なんでどっちかしか使えないと考えるんだろう ブランチが必要な理由が分からない
リモートからクローンしてきている時点で、origin/masterとは別のリポジトリが個々人に存在するんだし
コミットも個々人のリポジトリに対して行うわけでしょ
一度もブランチ生やしてなんて一度も指示されたことないわ ブランチがないとお互いのコミットを観測することができない
人の変更を見ようと互いにpush+pullすると常にmergeが伴うので、いわゆる観測者効果みたいな面倒くささが生まれる
プロジェクトの規模やリリースの複雑性が増すにつれてより困る
よくある例では、次バージョンの開発を初めている人がいるときhotfixを出せない
featureブランチのpushはオアズケを命じられて、その間ソースレビューも滞る
ブランチをforkに置き換えても同じ 各個人のGitHubアカウントにforkしてリポジトリ間のpull requestでマージしていく流派も存在する
本来のGitやGitHubの想定する使い方としては正しくてOSS文化的にも好ましいやり方ではあるんだが、企業での開発ではほとんど採用されない
単一のGitHubリポジトリで中央集権的に管理した方が楽だからね AからA'とBの2つを作りたくなったときって、
ブランチなしでどうやるんだろうな >>963
ブランチは「実装していること」を表すので、複数の機能を並行して開発するときは必須。
よくあるのは
・通常の開発版とリリース版／デバッグ版を分けて、デバッグリリースを早くする＆開発版への取り込みを管理しやすくする
・開発する機能ごとにブランチを用意して、互いの干渉を減らす＆マージをやりやすくする
あたり。 自分のアカウントにforkするスタイルの開発しか経験ない人が
単一GitHubリポジトリ運用な会社に入ってforkして怒られるのはGitHubあるある >>970
clone したら怒られるの？ マジか？ それ本当に git 使ってるの？ forkがcloneだからといってcloneがすべてforkなわけがない おまえらって、gitについて講釈ばかりたれてるけど
全く本業ができないわけじゃないよなｗ
うちの会社にもいるわ
講釈たれてる暇があるならさっさとコーディング終わらせろよｗｗｗｗｗ >>971
forkはgithubの別アカウントへリポジトリをcloneする
俺らはpushしてpull requestするとか素人さんを混乱させる戯言をよく使うが、本来のgithubのpull requestはforkした自分のアカウント下のリポジトリのブランチをpullしてmergeしてもらうことをrequestする
pushしてpull requestは正しくはpushしてmerge requestと言うべきで、Gitlabは正しくmerge requestと呼んでいたと思う
merge requestで作業してる職場で、pull requestしたら怒れるということだろう >>975
何を言ってるかわからない。
pull というのは「 fetch して merge 」という操作をまとめてやるだけのコマンドなので当然 merge の意味を内包してる。
fetch せずに merge って言いたいの？ それってどうやって対象を持ってくるの？
自分のリポジトリから持ってくるだけなら他人から request される必要ないし？ ちなみに push というのは remore への merge を指示するコマンドな。 >>976
いや同一のGitHubリポジトリ上でpull requestをマージするときにfetchは要らないでしょ
>>975の言うとおり、本来リポジトリを跨がるからfetch+mergeでpullなんだよ >>976
「本来のgithubのpull requestはforkした自分のアカウント下のリポジトリのブランチをpullしてmergeしてもらうことをrequestする 」
これはちょっと間違えた
fetchしてmergeしてもらうことをrequestするからpull requestね
それでmerge requestだけど、>>978の言うようにすでに共有ブランチへpush済みのブランチをmergeすることをrequestするから、mergeだけrequestでfetchはrequestしない
自分が仕事で使うのは主にこっち
>>977
pushは厳密に言えばFastForwardのmergeだけど、pushのことをmergeとはあまり呼ばないな >>979
push した時点で merge されてるんでは？
push はデフォルトでは fast foward のみだけど、remote の設定によって普通の merge もいける。
共有リポジトリ上の feature branch を共有リポジトリ上の master branch に merge みたいな話をしたいのかもしれないけど、通常は共有リポジトリ上で完結させたりしない。
1) 共有リポジトリ上の feature branch を手元に fetch
2) fetch した feature branch を手元の master btanch に merge
3) 手元の master branch を共有リポジトリへの push
という手順を取る。
1) + 2) が pull 動作。fetch 無しは個人の作業リポジトリへの push が必要になるので普通やらないし、できない。 あれ？もしかしてgithubだと違うのかな？自分が仕事で使うbitbucketの共有リポジトリでやる場合のデフォルトでは、プルリクエストの承認とマージは共有リポジトリ上で完結する
もちろんローカルでfeature branchをmasterへマージしてmasterをpushしてもいいんだけど、それは正式な手順では無い
githubでも同じことできるよね？
1) 共有リポジトリ上に feature branch を作成
2) 共有リポジトリ上の feature branch を手元にfetchしてcheckoutして修正をコミット
4) 手元の feature branch を共有リポジトリ上の feature branch へ push
5) プルリクエスト(マージリクエストだけど)をブラウザ上で作成
6) マージ権限者がブラウザ上でリクエストを承認してマージする
feture branchは正式にはブラウザで共有リポジトリ上に作るけど、ローカルで作ってpushしてもいい >>980
pushでFFじゃないmergeってできるの？できても今は普通しないでしょ
FFでmergeできない場合には、ローカルでmergeしてFFにしてpushするか、push -sで上書きが普通だし >>982
できるけど、おすすめではない。
ただ push は merge と同じ機構という点が理解できてれば良い。 >>981
いきなり共用リポジトリ上でマージしたりしない。そういう運用ルールの組織があるとしたらかなり頭悪い。git の使い方が半分しか理解できてない。
共用リポジトリは問題があってもロールバックできない(超めんどう)なので、共用リポジトリの master には手元でのテスト等が終わって問題ないもののみを入れるのが普通。 ローカルでマージしてmasterへpushするって言ってる人たちはmasterへのpush権限をみんなが持ってるの？ master へ push する権限を持ってる人がローカルで master に merge する作業をする。当然の話。 分野にもよるのかもしれんが、少なくともWeb系はGitHub上でマージするのが普通
直接mainにマージしたくないなら >>985
もちろんプルリクエスト出す段階でローカルにテストは済んでる前提だし、masterへマージされた後にそれがダメならrevertするよ？
プルリクエストを承認できてmasterへマージできる人は特定の人だけだし、それをマージする前にテストが済んでるかどうかとかをリクエスト者に確認する
そのためにプルリクエスト上でいろいろやりとりできるようになってるわけだし
というか>>980とかはgithubを単にgitのリポジトリとして利用するだけのやりかただよね？別にgithub使う必要無くない？なんでgithub使ってるの？ 失礼
直接mainにマージしたくないならdevelopブランチ等を間に置く
各自がいちいちローカルでマージして手元でテストなんてしてたら、みんなそれぞれ状態がバラバラで何テストしてるのか分からなくならないか？
特定の一人だけがmainにマージできるような超集権的な体制でないと成立しないと思う >>989
うちのやり方では「master へ push する権限を持ってる人がローカルで master に merge する作業をする。」か「ブラウザ上でマージしてしまうか」はその権限持ちがプルリクエストを見て判断する 統合的なテストはmasterにマージされた後に動かして、それでダメならrevert
統合的なテストが済んだところはtagが打たれてリリースはそのtagがあるとこまでしか行われない このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 598日 2時間 18分 27秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
