Git 16©2ch.net

2017/08/15(火) 00:54:07.61

ソースコード管理を行う分散型バージョン管理システム、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 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/

VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

2017/11/24(金) 20:00:28.03

やめろと言われてもやめられない

2017/11/25(土) 10:10:13.61

>>132
タイトルを「なぜfast forwardマージをやめるべきか」に変えてほしい

2017/11/25(土) 10:44:51.04

feature ブランチを rebase してから --no-ff merge
feature ブランチを rebase してから --ff merge
feature ブランチを rebase せずに --no-ff merge は、複数人開発だとデフォルトこっちになるけどffマージになっちゃうこともあるので一応指定
feature ブランチを rebase せずに --ff merge は、複数人開発だとffマージできなくてエラーになること多い

2017/11/25(土) 11:33:35.08

元記事のコメントも読んだほうが良いぞ

https://blogg.bekk.no/why-you-should-stop-using-git-rebase-5552bee4fed1

2017/11/25(土) 15:34:56.72

綴り間違い治すだけとか
rebaseしたくなるなー

2017/11/25(土) 16:13:13.39

後でbisectした時に困るって話？

2017/11/25(土) 17:56:16.27

綴り間違い治した程度でbisectが困ることにはならんと思ってるが違うの？

2017/11/25(土) 18:33:01.06

ログメッセージの修正だけが目的で
元と同じ場所にrebaseするだけなら大丈夫だろう

masterの新しいコミットの上に何も考えずにブランチのコミットをrebaseするのは
後々問題を引き起こす

2017/11/25(土) 18:52:04.01

後々ってのはどういうこと？
問題が発生するならrebaseしたその時じゃないのか？見落としは別として。

2017/11/25(土) 19:02:42.56

これ大前提としてコミット一つ一つを
どう運用しているかによるよな

コミットにバグが含まれていたとしても
マージする単位で整合性が取れていればOKなのかとか

人によってはコミットを作業履歴みたいに
・○○修正した
・ミスが有ったので訂正
・タイポ
・修正漏れがあったので対応
・今日はここまで
みたいにする人もいるし

2017/11/26(日) 21:22:48.07

作成したリポジトリから複数回プッシュした変更分ってmasterにも複数回マージすれば良いのんかね
それとも最後のプッシュぶんだけマージすれば変更分は全てマージされるん?
gitよくわかんねぇんご

2017/11/27(月) 15:12:43.92

commitした時点で独立した完全版だから
最後のやつだけでいいよ

2017/11/28(火) 12:41:47.97

差分や増分バックアップとは違うんだ

2017/11/28(火) 22:54:30.48

>>143
コミットIDというのは歴史全て含んでそのID
だから、遠い過去を書き換えてもコミットIDは変わる
IDが分かれば歴史もすべてわかる

2017/11/29(水) 08:47:58.58

誰かgit初心者の勉強につきあってくれる人はいないかなぁ
そんな人を探して初レス

2017/11/29(水) 08:55:48.00

勉強につきあってもいいよという人がいたら↓にきてよ

open.open2chネットの/test/read.cgi/nohara/1511913106/

2017/11/29(水) 19:29:37.54

2.15.1

2017/12/14(木) 01:55:18.80

Git で管理しているJavaのクラスを
リファクタリングで別のパッケージに移動させた場合、

物理的な移動と中身の変更(パッケージ宣言の変更) が同時に発生するので
これらを同時にコミットすると、Git上で履歴が追跡できなくなるのがつらい

いまは、ファイルだけ移動させていったんrenamedでコミットしたあとに、
別のコミットで中身(パッケージ宣言)を書き換えてしのいでいるんだけれど、
途中でコンパイルが通らないコミットができるのが、あまりうれしくない…

みんなどうやっているの？？

2017/12/14(木) 04:38:04.91

git log も git diff も、--followオプションを指定すれば、クラス名の変更ぐらいは余裕で追跡してくれる
git blame はオプション無しでも大丈夫っぽい

2017/12/20(水) 09:36:16.98

２つの質問していいですか？
一つ目の質問してもいいですか？
なぜpushには-uオプションがあるのにpullにはないのですか？
２つ目の質問してもいいですか？
GITのコマンドが完全に成功するか完全に失敗するかのどちらかというのは
複数の人が同時に同じレポジトリーに対して別のGITからコマンドを実行しても
成り立ちますか？

2017/12/21(木) 00:02:48.01

たぶん -u オプションの意味を勘違いしてる
pushでも特に必須なオプションじゃない

同時にリモートリポジトリ操作は大丈夫なようになってる

2017/12/21(木) 13:22:44.51

>>152
cloneなｒ常に成功するかもな

2017/12/22(金) 00:22:27.25

mao.5ch.net/test/read.cgi/linux/1468149353/501

501 login:Penguin sage 2017/12/22(金) 00:20:40.83 ID:0/XqAwW+

誰もやらんかもしれないけど
① WSL の Ubuntu の bash から使う git
② Git for Windows の Git Bash から使う git
これらを混ぜると危険

②でサブモジュールを含むローカルコピーを取ってきた後
サブモジュールを取り直す時に
間違って①で取ると
以降 git status --porcelain が失敗する

TortoiseGit が Git for Windows に依存するので
TortoiseGit でのいろんな操作も失敗するようになる

ようやく気づいたよ、、

修復方法はサブモジュールを
Git for Windows のGit Bash から取り直すこと

2017/12/29(金) 19:36:56.00

Git v2.16.0-rc0

2017/12/31(日) 18:18:45.28

よくわからないので教えてください。
リポジトリとなるフォルダとして、　git-sampleフォルダを作成し登録しました。
この中で20181231.txtというファイルを作ってコミットし、成功しました。
ここで、別のファイルも管理したいと思い、git-sampleフォルダの中で、
テスト用.txtを作成し、コミットさせると、20181231.txtと同じブランチに
紐づいてしまいます。
それぞれを別のファイルとして管理させたい場合は、ファイル登録時に
どうすればよいのでしょうか？

2017/12/31(日) 19:27:03.03

>>157
同じmasterブランチでは
別のファイルとして見えてるんでしょ？
今ので合ってるよ

2017/12/31(日) 22:22:50.30

git add する前に git branch しろってこと？

2017/12/31(日) 23:02:24.79

>>158
素人で申し訳ないのですが、樹形図列に表示されている線が1本のみで、
その1本に20181231.txtとテスト用.txtが紐づいている感じですが、
それぞれのファイルごとに樹形図があると思っていたのですが、そうでは
ないのでしょうか？
それであれば、ファイルごとの状態を把握するのが難しいような・・

2017/12/31(日) 23:19:02.84

>>160
masterブランチにマージする前提で使うのが基本だよ
途中は樹形図のように広がってもなるべく最後は一つにマージする
樹形図のように広がっている時は多くの人が編集途中だったり、
個人であってもあれこれ途中のものを入れてる段階で、
最終的には確定した一つのものにする

2017/12/31(日) 23:21:27.73

>>160
ファイルごとの状態、
というのがよく分からんけど
あるファイルの編集履歴を見たいなら
git log とか git blameとかで見れるよ

2017/12/31(日) 23:33:57.55

>>160
もしかして、 fast forward merge ばかりしてるとか？
merge時にmasterブランチに履歴が混ざるのが嫌だと言う話なら以下を参考に

https://qiita.com/nog/items/c79469afbf3e632f10a1

git config --global --add merge.ff false
git config --global --add pull.ff only

というか
それ以前にブランチすら作ってないのかも？

2017/12/31(日) 23:58:34.50

>>161-163
いろいろ親切に回答をしていただいて申し訳ございません。
SourceTeeeを使っていることを書いていませんでした。
なので、CLIのほうはまだちんぷんかんぷんです。ごめんなさい。
でも、でてきた各用語についてはこれから勉強させて
いただきます。
ちなみに実際にやっていきたいのは、
[構成図]フォルダ内にある、物理ネットワーク.xlsxや論理ネットワーク.xlsx
などの各ファイルのバージョン履歴がファイルごとに見れるようにしたい。
それがSoueTreeでどのようにできる（表現される）のか試しに始めた次第です・・

2018/01/01(月) 02:27:07.10

>>164
遥か昔、バージョン管理ツールは、ファイル単位で履歴を管理する方式から始まったんだけど、
不便だったので、特定のディレクトリ以下の複数のファイルの状態をまとめて履歴管理する方式に取って代わられた

ファイル単位で履歴を見る方法は用意されてると思うけど、SourceTreeはよくわからん

この辺が参考になるかな？
https://teratail.com/questions/12039

2018/01/02(火) 07:35:38.59

「未コミットの変更状態」が作業ディレクトリに残った状態で
他人がコミットを進めたブランチをpullしてくると
作業ディレクトリはどうなるの？

2018/01/02(火) 13:18:24.56

>>166
pullすることで更新されるファイルが作業ディレクトリで未コミット状態なら、
pullの途中のマージでエラーになる

2018/01/06(土) 12:42:45.96

Git v2.16.0-rc1

2018/01/13(土) 07:31:35.38

Git v2.16.0-rc2

2018/01/18(木) 20:38:13.86

Git v2.16.0

2018/01/21(日) 13:08:54.29

「Git 2.16」リリース
https://mag.osdn.jp/18/01/19/174500

2018/01/22(月) 20:06:44.46

Git v2.16.1

2018/01/27(土) 15:27:23.12

Gitは間違いなく開発を不便にしている
自分の足跡を強制的に残すことを余儀なくされているから
そうすると自分の変更の差分を勝手にチェックしてくるやつが
でてきて「この余計なファイル何?」とか「この変更何?」とか
「削除して」「コミット取り消して」言い始めて何回も
自分の作業が無駄になる。
自分の作業や時間をムダにしないためのツールなのに。
コンフリクトが発生したから取り消すんじゃない。
バグが実際に起きたか取り消すわけじゃない、
単に「監視」されて、監視したやつにとって「不可解だと思ったから」
それだけの理由で何度もコミットを取り消したりファイルをごちゃごちゃ
編成したりを余儀なくされる。
バックアップ要ファイルとかtmpとかコメントアウトとかインデントとか
コーディング規約とかちょっとでもお気に召さなかったらいくらでも
もとに戻せるんだから「戻せ」となる。
こんなことなら一度加えた変更は二度と戻せないほうがマシかもしれない。

2018/01/27(土) 15:36:45.37

ソースコードもペーパー大好き日本人の感覚で言えば
稟議書のごとく書式チェックされる。
ちょっとでも書式が崩れていたら(問題なく動いたとしても)
すぐ差し戻される。
日本人は救いがないくらい馬鹿すぎる、なんだこの情弱国家は。

2018/01/27(土) 16:01:03.48

適性ないから今すぐ仕事やめた方がいいよ

2018/01/27(土) 16:19:47.17

他人が読めない糞コード書くからやり直しさせられてるんだな
gitが品質向上に役立ってることが分かりました

2018/02/06(火) 22:53:30.41

Jenkins と GitBucket との連携に関する問題が解決できず質問しました。

具体的には、GitBucket のリポジトリに push したとき、Jenkins ジョブが自動的に起動するようにしたいのですが、
そのジョブが自動的には起動しません。

GitBucket のリポジトリの Service Hooks の設定で [Test Hook] ボタンを押すと、HTTP ステータスコード 200 が帰ってきます。
また、同設定ページの [ Which events would you like to trigger this webhook?] で [Push] にチェックを入れています。
この状態でも、GitBucket のリポジトリに push しても Jenkins のビルドが起動しません。

しかし一方で、Jenkins のジョブは Multibranch Pipeline ですが、
GitBucket のリポジトリに push した後、Jenkins のジョブの [Scan Repository Now] を実行すればジョブは起動します。
つまり手動では問題なく起動するということです。

原因として何が考えられるでしょうか?

（Git とJenkins のどちらのスレに質問するのが適切かわからず、
とりあえず賑わいがあるこちらに質問しました）

2018/02/06(火) 23:14:29.04

>>177
スレチ
jenkins側のプラグインの問題っぽいね
何使ってるか知らんけど
悪いことは言わんからGitter行け

2018/02/08(木) 13:39:20.66

>>178
Jenkins のプラグインを調べてみます。
ありがとうございました。

2018/02/08(木) 14:47:59.34

>>179
pushならGitBucketプラグインでも連動できることは確認してるよ

2018/02/14(水) 23:03:48.87

>>177
http://int128.hatenablog.com/entry/2016/10/04/230243
http://int128.hatenablog.com/entry/2016/10/06/224444
この辺の話じゃなかろうか

最近のGitBucketでは問題無いと言う話も聞くけど、うちじゃどこかのバージョンからか
上手く動かなくなって、原因探るのもめんどうだからポーリングに変更しちゃったわ

Jenkins側のPluginがAPIアクセス時のアドレスにポート番号まで含めて自由に設定出来れば解決出来そうだが……

2018/02/16(金) 01:21:38.40

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

2018/02/16(金) 13:33:28.32

git config --global user.name "xxxx"
git config --global user.email "yyyy"

としたんだけど、何もメッセージが出ない。
念のため、xxxx の文字列をローカルディレクトリで検索してみたけど
どこにも記録されてないみたい。エラーが起きてるのにエラーメッセージが出ない？

2018/02/16(金) 13:56:12.52

git config --global --list

2018/02/16(金) 13:58:09.10

ローカルで探すつもりなら
git config --local hoge.hoge fugafuga

2018/02/17(土) 23:42:10.06

Git v2.16.2

2018/03/29(木) 14:26:26.37

GIT SVNでSVNのリポジトリのtagsにGITのtagを反映させるのはどうしたいいんでしょうか？　GITだけ（SVNは入れてない）で開発していてtagをつけた後にリモートにdo commitしてもtrunkに入ります。　

2018/04/03(火) 21:31:47.06

Git v2.17

2018/04/04(水) 20:27:01.72

「Git 2.17」が公開
https://mag.osdn.jp/18/04/04/163000

2018/04/05(木) 22:18:45.42

>>187
svnのtagは実質ブランチで、gitのtagと全然違うから無理。
git-svnでsvnからgitへの移行時もsvnのtagはbranch扱いだし、方法は無いと思う。

2018/04/11(水) 16:25:59.62

>>190
無理ですか　SVN入れてる人に頼んでみます
　

2018/04/13(金) 23:54:37.31

なんでこんな分かりにくくて複雑で使いにくいものが流行ってるの？
もっとシンプルで簡単なものでいいじゃん。
プロジェクトメンバーのほとんどのヤツが良く理解してないのに
使わされるからめちゃくちゃになる・・・

2018/04/13(金) 23:59:12.80

めっちゃ便利なんだが？？
分かってる人が分かってない人にちゃんと教えるべきでは？
御社の教育体制を見直すべきでは？

2018/04/14(土) 03:01:44.20

>>192
どんなのが判りやすいと思う？
っていうかgitの前はどうしてたん？

2018/04/14(土) 05:06:49.08

git の特徴は、直接リポジトリへ保存しないこと

一旦、自分のPC 内に保存して、そこで少し待つことができる。
その後しばらくしてから、リポジトリへ保存する

2018/04/14(土) 09:59:05.68

流行ったのはGithubの影響が大きいだろうね
実際、GoogleのPerforceとかFacebookのMercurialとかGitを否定して他のバージョン管理システム使ってるところも多いけど、一番数の多い中間層でブームになってこの状況なんだと思う

2018/04/14(土) 11:07:05.30

gitが流行ったのは大手がこぞって使ってるからだよｗ

2018/04/14(土) 11:07:36.29

大手っていうのはプロジェクトの話ね
大手プロジェクトはだいたいgit

2018/04/14(土) 13:01:14.52

大手のオープンソースプロジェクトがGithubに移行したってこと

2018/04/14(土) 16:20:21.87

Windowsの開発すらGitだもんな

2018/04/15(日) 05:59:08.09

bitbucket なら、5人以下のメンバーなら、プライベートでも無料

2018/04/16(月) 13:13:49.76

水銀はいいと思うんだけど、なかなか流行らなかったな

2018/04/16(月) 13:21:04.15

mercurialが性に合うし　hg-gitが優秀だから
裏側でmercurial使ってgithubに投げ込んでる

2018/04/26(木) 21:50:45.36

Git2.17は移動したコードに対する差分表示やオブジェクト検索機能が向上した
https://www.infoq.com/jp/news/2018/04/git-2.17-released

2018/04/26(木) 22:00:48.45

くーる、gitくるー、gitくるー

2018/04/27(金) 15:43:59.08

わっちょい

2018/04/28(土) 18:05:54.44

神様
汝へ
git rm --cached hoge.txt すると gitの管理下から外れ、ローカルのファイルは残るけど、pushするとリモートからは削除されちゃうのだけれども、削除されずにgit管理化から除外する方法
を教えてもらえますように。

2018/04/28(土) 18:09:20.59

git rm --cached hoge.txt すると gitの管理下から除外され、ローカルのファイルは削除されずに残るけど？

2018/04/28(土) 18:18:44.48

>>208
神出現ｗ
ローカルには残るけど、statusみると deleted: hoge.txt になっているので、pushするとリモート先からは削除されちゃうのです。

2018/04/28(土) 18:37:38.20

>削除されずにgit管理化から除外

どういう状態？

2018/04/28(土) 19:56:15.86

>>210
環境依存する設定ファイルをgitで管理していたのだけれど、それをgitの管理から外すために、
・git rm --cached で除外（ファイルは削除いたくない）
・.gitignore に追加
・commitしてリモートへpush
・別環境でそれをpullすると、除外したファイルが消えてしまう
これを削除されないようにするのはどうすれば良いか、、というご相談です。

2018/04/28(土) 21:42:25.92

skip-worktreeでどうかな？

2018/05/11(金) 07:19:03.16

http://livetest.net/load/20180511-071412-034.jpg

2018/05/15(火) 17:52:31.19

わかばちゃんのGITの本どうなんだろうなぁ

2018/05/15(火) 18:22:19.05

良かったよ

2018/05/15(火) 18:24:24.37

よかったか
値段がきついけど年に1冊ペースででるからなぁ

2018/05/15(火) 19:02:51.78

うわぁ、いい本と聞いて見に行ったけど、あれ買う勇気も
読む勇気もないわ。

2018/05/15(火) 19:15:37.89

「一般小説の表紙がどんどんラノベ化していってることに戸惑う人々」を解説する
http://srpglove.hatenablog.com/entry/2018/04/16/224342

2018/05/23(水) 19:20:40.74

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

QHYQI

2018/05/28(月) 16:06:40.15

来週のサイエンスZEROが仮想通貨なんだが
http://www4.nhk.or.jp/zero/x/2018-06-03/31/24902/2136678/
予告動画で流れてるコマンドが git だった件

2018/06/01(金) 14:52:31.00

「Git」に任意のコード実行の脆弱性、更新版で対処
http://www.itmedia.co.jp/news/articles/1806/01/news086.html

2018/06/01(金) 18:12:40.18

SVN大勝利！

2018/06/02(土) 00:56:17.06

Git v2.18.0-rc0

2018/06/09(土) 09:32:17.23

Gitの脆弱性により任意のコードが実行できる
投稿日 2018年6月7日
https://www.infoq.com/jp/news/2018/06/git-vulnerability-2.17

2018/06/09(土) 13:33:07.62

M$とは大違いだな

>さらに、追加のセキュリティレベルとして、これらのリリースでは、問題のある.gitmodulesファイルを含むリポジトリへの
>pushesを拒否する。これは、次のことを意味する。

>ホスティングサイトが悪意のあるコンテンツの拡散を防ぐことで、古いクライアントを使っている顧客を保護します。

2018/06/09(土) 13:39:47.50

>>225
どこが？

2018/06/09(土) 13:40:58.38

>>225
ここで述べられてるいくつかの脆弱性・修正のうち、
https://www.infoq.com/jp/news/2018/06/git-vulnerability-2.17

NTFSに関するものはこれだけでは？

> 修正された脆弱性の2つ目は、NTFSファイルシステムを使用するレポジトリに
> 特有の脆弱性であり、攻撃者がランダムなメモリ内容を読み取れるように
> NTFSパスの健全性チェックを欺くことができる。

つまり、あんたの引用したそれはNTFSとは関係ない
Linuxにも影響がある脆弱性

2018/06/09(土) 14:31:46.19

こういう記事を見てもMSを批判することは、かっこいいことみたいだね。

GitHubからGitLabへ移行しよう
ttps://qiita.com/flmil/items/89ca07fa976546365c49
> きっかけは、Microsoftは2018年6月4日（米国時間）に、
> GitHubを(約75億ドルで)買収すると発表したことだ。

2018/06/09(土) 14:37:20.77

放射脳みたいなものだね
昔ちょっと失敗したからっていつまでも原子力はダメだと言うのはばかばかしい
Microsoftも確かに悪い時期はあったけど今はユーザーや開発者にとってすごくいい会社だよ

◆QZaw55cn4c (ﾜｯﾁｮｲ 4260-EqDK [131.129.117.56]) · 2018/06/09(土) 14:43:26.60

>>229
原子力は問題ですね、特にビジネスロジックの中にリスク管理が全く含まれないところが
原子力も保険に入る必要があるのですが、その保険を定義できない常況なのです

2018/06/09(土) 14:58:56.95

マイクロソフトはありだけど原子力はないわ

2018/06/09(土) 15:10:27.79

>>229
原発でマスゴミの可笑しなところは
事故前(もんじゅとか美浜とかの時代)は少量漏れただけであれほど危ない危ないって騒いでたのに
事故が大きくなると何も言わなくなったこと
今も騒ぎ続けてないと可笑しいんだが
発狂して死んでもいいレベル