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/08/15(火) 00:57:36.93

乙です

2017/08/15(火) 01:19:15.72

Git v2.14.1
v2.7.6, v2.8.6, v2.9.5, v2.10.4, v2.11.3, v2.12.4,
and v2.13.5.

https://public-inbox.org/git/xmqqh8xf482j.fsf@gitster.mtv.corp.google.com/T/#u

Gitの脆弱性 ( CVE-2017-1000117 )
https://oss.sios.com/security/git-security-vulnerabiltiy-20170813

2017/08/15(火) 01:21:19.55

Gitはバージョン2.13でセキュリティとUIの改善を続けている
https://www.infoq.com/jp/news/2017/06/git-2-13-released

「Git 2.14」リリース、細かな変更が多数加えられる
2017年8月7日15:15 末岡洋子
https://mag.osdn.jp/17/08/07/151500

2017/08/15(火) 07:02:36.87

>>1乙

2017/08/15(火) 17:26:52.66

>>1
乙

2017/08/17(木) 17:55:13.19

2017/08/19(土) 11:17:16.15

2017/08/19(土) 15:17:16.64

2017/08/21(月) 23:15:55.08

コンフリクトが確定しているときにこっち側のファイル全面採用！ってやるほうほうないですかね？
masterで暫定対応をちょこちょこしてリリースしたあと
ブランチで根本治療を図ったら全面書き換えになっちゃった、みたいな場合です。

2017/08/21(月) 23:30:41.31

>>10
いつものドキュメントのこのページの後半
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%9E%E3%83%BC%E3%82%B8%E6%89%8B%E6%B3%95

git merge -Xours とかの解説をよく読んでみるがいい

10 (ﾜｯﾁｮｲ 2aea-5zB4 [27.139.48.17]) · 2017/08/21(月) 23:53:04.12

>>10
ours/theirsは知りませんでした！
ありがとうございます。

2017/08/23(水) 12:06:37.12

githubであるリポジトリをフォークしてローカルにクローンしてブランチを作って作業してます。
フォークしたリポジトリのブランチを破壊してしまいリセットもうまくいかなかったので

壊れたブランチをローカル・リモートともに削除して
新しく同名のブランチを作成してリモートに反映させて
ローカルのブランチを削除して
フォーク元のリポジトリから元のブランチをチェックアウトして
そのトラック先を新規作成したフォーク先のリポジトリのブランチに変更して
強制プッシュしました。

見た目問題なさそうなんですが何かおかしいところがないでしょうか？

2017/08/23(水) 18:29:46.42

フォークした時点でローカルもリモートも自分のものになってるんだから気にすんな

2017/09/01(金) 13:33:55.02

新人プログラマです。
現在私の参加しているプロジェクトでgitを使っているのですがどうも使い方がおかしい気がしてます。(新人なので私のほうがおかしいのかもしれないが)

以下現運用状況です
リモートリポジトリをクローンしてそれをさらにコピペでIDEのワークスペースに移し、ファイルを編集・追加する。
差分をwinmergeでローカルリポジトリにコピー
そしてリモートへプッシュ

こんな感じです。

私はクローンして作ったローカルリポジトリのワークツリーをIDEのワークスペースとして使うのではないかと思い混乱しています

皆さんの意見をお聞かせください

2017/09/01(金) 13:39:42.54

>>15
> リモートリポジトリをクローンしてそれをさらにコピペでIDEのワークスペースに移し
この段階で、ローカルには二つのクローンされたファイル群になるんじゃないの？

2017/09/01(金) 13:51:35.54

君が入る会社を間違えるからそういう低レベルな職場にぶちこまれる
きっとそういう環境では何も技術的にレベルアップできないからいるだけ無駄だよ
転職を考えた方が良い

2017/09/01(金) 19:23:38.78

>>16
すみません。少し説明不足であることに気づきました。
クローンしたローカルリポジトリのワークツリーのフォルダだけをコピペしてIDEのワークスペースに入れています。.gitフォルダなどはコピペ対象外なのでクローンが2つではないのです。

どうも手順書がgitのワークツリーのことをリポジトリとは全く別の作業用のフォルダという理解で書かれているようなのです。書いたのは富士通の人ですが

>>17
やっぱこれは低レベルな現場なんですかね…
転職は入社したときから常に頭の片隅にあるのですが…

2017/09/01(金) 22:32:59.33

コミットは神聖な手続きなのでローカル履歴はzipでやりなさいという教えでは？

2017/09/02(土) 15:31:16.61

さすが不治痛

2017/09/02(土) 15:47:38.19

>>18
管理は二流
技術は三流

2017/09/02(土) 16:29:41.35

メーカーはオワコンだからやめとけ
web系一択

2017/09/04(月) 16:21:42.64

>>18
手順書書いたやつに指摘してみて、変わらない・逆切れするようなら転職go。
そのくらいとんちんかん。

2017/09/04(月) 20:59:42.34

読んだ感じ富士通に常駐してる人じゃないのか？だったら文句言っても無駄

2017/09/05(火) 01:30:41.15

AWS上のローカルリポジトリをmac等からssh接続し、source treeで管理することは可能なのでしょうか。
実際に試せばわかることなのですが、あいにく手元に実践できる環境がないので、教えていただけると幸いです。

2017/09/05(火) 12:45:59.79

どうやってるのかわからんけど
マウントしてたらローカルと同じ扱い
それ以外はリモート

2017/09/05(火) 13:17:02.98

>>24
お察しの通り弱小常駐です。ましてや１年目の新人なので富士通の人に直接言う機会すら無さそうです
転職は入社初日から考えていますが…

2017/09/06(水) 23:17:25.37

gitの開発ＭＬ見てたら、ライナス降臨でバグに文句言ったら、
速攻でPeffがパッチ投げていたのはワロタ

2017/09/07(木) 18:43:35.40

2.14が出てから、開発ＭＬにメモリーリーク関係のパッチがいろんな人から大量に投稿されている。
全部取り込まれるかどうかはわからないが、2.15 はメモリ開放漏れが大幅に減る予感。

2017/09/14(木) 00:10:36.87

tortoise git でブランチ名を変更する方法ってある？

2017/09/14(木) 00:32:07.06

>>30
それ使ったこと無いけどブランチ作って元のを必要なら消すだけじゃないの
ブランチ作る機能の無いgitクライアントなんてあるわけないよね？

2017/09/14(木) 04:36:27.84

ブランチの一覧からならできるよ

2017/09/14(木) 08:38:41.28

コメントどうもありがとう

>>31
その一手間が面倒だからあればなーと思って

ログのグラフを見ながら作業できたら便利なんよね

>>32
ちょっと探してみます

2017/09/14(木) 21:23:11.19

そんなのが必要になるほどブランチの名称変更って頻繁に使うものかな？

2017/09/14(木) 23:59:50.42

誰かに教えてもらった
「ここをコメントアウトするといいですよ」
をブランチを作ってコミットとか
とりあえず一気に最後まで実装したのをコミット、
そこで似たような名前でブランチを作っておいて
最後のコミットをやり直しながらちょっとずつコミット、
途中でこれは別のブランチにも先にマージして使いたいので
ブランチを作ってそれだけまとめるか
とか
なんぼでも思いつくけど、、

2017/09/15(金) 00:44:12.96

ブランチはいっぱい作るけど名前変更ってのはあんまりしないな

2017/09/15(金) 03:17:34.93

名前変更するよ

2017/09/15(金) 09:06:46.55

名前変更できるだろ　マニュアル読めよ

2017/09/15(金) 09:24:48.95

マニュアル？

2017/09/15(金) 10:22:25.88

git branch --help
でwebページ（マニュアル）開くから
-mオプションを見ろ

英語が読めないとかいう幼稚園児は死ね

2017/09/15(金) 10:58:21.43

>>40
馬鹿だなー
質問は「tortoise git でブランチ名を変更する方法ってある？」なのに

2017/09/15(金) 11:02:09.40

これだからGUI厨は

2017/09/15(金) 11:05:05.50

？？？？

2017/09/15(金) 11:06:03.31

>>42
恥の上塗り

2017/09/15(金) 19:17:27.76

>>33ですが、
>>32さんの方法で名前変更だけでなくいろいろできることがわかりました！
どうもありがとうございました！
m(__)m

2017/09/16(土) 12:11:45.94

開発ＭＬでGit for Windows のコミッタと浜野氏がもめているね。

Git for Windows のコミッタ　＝> REBASEのパッチを出す。やり直しやり直しで6回出しても通らない。

浜野氏＝＞　9月2回目の　Cooking in git.git で　Expecting a reroll.　と書く。

Git for Windows のコミッタ　＝＞　No you don't　と嫌味。

浜野氏＝＞　9月3回目の　Cooking in git.git で　相変わらず、Expecting a reroll.　と書く。

Git for Windows のコミッタ　＝＞　うざいから俺のパッチを削除しろよ

浜野氏＝＞　お前の意見のせいで頭おかしくなりそうだ。もう少しなんだから最後までパッチ書けよ。

2017/09/16(土) 12:17:55.33

Git for Windows のコミッタと浜野氏は8月5回目の　Cooking in git.git でも揉めている。

この殺伐感こそが開発という気がする。

2017/09/16(土) 13:29:53.43

何が起きてるの？
原因は何なの？

2017/09/16(土) 17:16:40.26

sourcetree以外を使わないといけない理由は何なの

2017/09/16(土) 19:02:45.82

IDEから操作したいとかCUIで操作したいときとか

2017/09/17(日) 15:29:48.97

Gitをコマンド以外で操作することって現場ではある？
全てコマンド上で出来る気がするんだけど、ディレクトリ右クリックからの～って操作を推奨してるのかな

ちな最近転職して内定、現在勉強中の身です

2017/09/17(日) 15:31:17.90

普通にsourcetreeの方がブランチが一覧できて楽

2017/09/17(日) 15:58:25.17

俺は gitk --all 見ながら操作はコマンドだな。

2017/09/17(日) 17:24:04.71

>>51
大体のことはVisual Studioから操作するけど

2017/09/17(日) 17:32:01.85

TortoiseGitかVisualStudioかな

2017/09/17(日) 17:39:53.92

ブランチ操作とかはSourceTreeは遅いからコマンドで打つことがかなり多いけど、addに関してはGUIで差分を確認しながらすることが多いかも

2017/09/17(日) 19:29:40.86

Windowsで個人情報登録したくないなら亀git一択

2017/09/17(日) 22:54:57.12

>>57
これ

つーかgitだけじゃなくて
tortoise gitもGPLのオープンソースプロジェクトなのね

2017/09/17(日) 22:58:32.49

誰かtortoise gitのログウインドウのコンテキストメニューから
ブランチ名を変更する機能の追加を
tortoise gitのgitリポジトリから
フォークしてマージまでやってくれないかな、、

2017/09/18(月) 08:54:24.87

>>59
自分でやりなよ

2017/09/18(月) 12:38:51.42

>>59
すげぇ眼鏡クイってしながらドヤ顔で言ってそう

2017/09/21(木) 22:47:34.41

>>51
うちの現場ではtortoiseGit使ってます
無能が運用ルール作ったせいでsvnのほうが100倍ましだった…みたいな状態ですが…

2017/09/21(木) 22:52:41.41

>>62
お前がルール変えろよ

2017/09/21(木) 22:57:54.62

どんなルールなのか興味深い。

2017/09/21(木) 23:18:17.35

コミット担当者にパッチ渡してマスターリポジトリにコミットしてもらう運用とか普通にありそうで怖い

2017/09/21(木) 23:52:33.47

tortoise git よいよね

2017/09/22(金) 02:37:32.52

>>65
その前に5人くらいのハンコを貰わないと・・・

2017/09/22(金) 07:53:10.93

>>67
ワロタｗ

2017/09/23(土) 16:52:07.47

個人の生産性を測ると、バグと手戻りと思い違いが増える。
一方、協調しようとかスキルを伸ばそうとか知見を共有しようとかいった態度は薄れていく。
各人がなんとしてでも自分自身の生産性を確保しようと躍起になるからだ。
心しておきたいのは、個人の生産性を計測すると、
プロジェクトで大切に育んでいきたい心構えと振る舞いを台無しにしてしまうということだ。
チームメンバー同士で考え方を共有すること。助け合うこと。
落とし穴にはまらないように気を配ること。
こうしたすべてが失われてしまう。

2017/09/28(木) 23:34:56.07

v2.14.2
https://public-inbox.org/git/xmqqwp4m9ejl.fsf@gitster.mtv.corp.google.com/T/#u

2017/09/28(木) 23:36:14.31

v2.10.5, v2.11.4, v2.12.5 and v2.13.6
https://public-inbox.org/git/xmqqy3p29ekj.fsf@gitster.mtv.corp.google.com/T/#u

2017/09/29(金) 00:30:35.07

Git for Windows 2.14.2からtig同梱されんのマジうれしい

2017/09/29(金) 07:52:10.69

会社は未だにSVNでプライベートは共同作業するようなプロジェクト持ってないんだけどgitにするメリットってあります？

2017/09/29(金) 08:01:18.62

>>73
あるよ

2017/09/29(金) 08:02:00.07

>>74
なるほど

2017/09/29(金) 09:34:10.54

>>73
ローカルコミットできるというだけでもメリット

2017/09/30(土) 14:34:09.10

>>74
例えば？

2017/09/30(土) 14:36:12.79

ディレクトリを作成する
git init

これでバージョン管理の準備が整う

svnだとリポジトリ用のサーバー用意して～から始まる

2017/09/30(土) 20:22:04.95

>>78
> svnだとリポジトリ用のサーバー用意して～から始まる
知ったか乙
お一人様ならサーバーなんて要らんよ
https://qiita.com/sksmnagisa/items/8c3905e073084b3cac16

2017/09/30(土) 20:49:27.67

>>79
いや、だからそのリンク先の内容が
面倒だって話だろｗ

2017/09/30(土) 21:32:44.16

>>80
とりあえずサーバーなんて要らんと言うことはわかったかな？ w

2017/09/30(土) 21:48:34.87

必死すぎwｗｗ

2017/09/30(土) 22:23:37.66

お前がな w

2017/09/30(土) 23:29:07.36

>>77
GitHub, Gitbucket

2017/09/30(土) 23:36:20.97

gitはSVNに比べて気軽にブランチが作れるんで、
ちょっとした実験用の実装を別ブランチで分けて作っておいて、
あとから部分的に使いたい部分のコミットのみを別のブランチにマージさせたりできる
これはSVNにはないメリットといえるのではないだろうか

2017/10/01(日) 02:04:56.52

最新のsvnはマージのアホさが改善されてるの？

2017/10/01(日) 09:51:03.59

>>85
＋１

2017/10/01(日) 14:14:46.94

SVNでコミットログをいじくり回したいんだけど、どうすればいいでしょうか

2017/10/01(日) 14:58:24.30

>>86
>>88
質問するスレが違うだろ

2017/10/01(日) 15:21:03.90

>>86はまだgit並みになったのか？
って言う意味だとも取れるけど>>88はさすがにスレチだな

と言うことで
Subversion r15
http://mevius.2ch.net/test/read.cgi/tech/1406967657/
に行けよ

2017/10/02(月) 23:41:02.48

プルリクによってＯＳＳ活動が捗るというのもgitのメリットでは
SVNではこうはいかない

2017/10/02(月) 23:51:55.96

>>91
プルリクエストはgitの機能ではないと思います

2017/10/03(火) 17:11:34.38

グレーゾーン

2017/10/03(火) 19:21:13.81

開発ＭＬ見ているけど、パッチ出してレビューしての繰り返しで、16回目のレビューのパッチとかあるね。
去年の夏ごろからレビューと再提出を繰り返しているみたいだ。

根性あるって感じ。

2017/10/03(火) 22:31:51.61

16回もレビューするようなコードは
もういい。俺が自分で書くってなりそうｗ
レビューする方は根性有るな

2017/10/03(火) 23:03:24.43

一回レビューしたあとにまた新たな実装を追加したりしてんじゃねーの
たまにいるよそういうやつ

2017/10/05(木) 00:08:21.14

レビュー修正のやり方を全くわかってないクソプロは死刑

2017/10/05(木) 03:03:21.97

>>91
それgitちゃうし

2017/10/05(木) 21:41:21.65

v2.15.0-rc0

2017/10/09(月) 14:15:58.34

git add -pで一部だけaddした場合
そのaddされた変更箇所がどこなのか確認する方法を教えてください
git diffだとaddされてない部分が表示されました

2017/10/09(月) 14:24:19.72

でゅふ　きゃっしゅど

2017/10/10(火) 15:34:45.76

git diff --cached

2017/10/10(火) 16:23:39.68

test

2017/10/12(木) 00:09:49.20

v2.15.0-rc1

2017/10/14(土) 21:28:11.20

RC1 で An ancient bug　ってのが直っているな。　どのバグか知らんが、そんな古いバグもあるんだな。

2017/10/16(月) 00:13:51.06

ローカルコミットの最新だけリモートにプッシュすることってできませんか？
一旦コミットしてしょうもない書き間違いに気がつくことがあって

2017/10/16(月) 01:05:34.82

>>106
しょうもない書き間違いをしたのはリモートにプッシュしたの？
まだしてないなら何でもできるよ

2017/10/16(月) 10:05:32.21

amend

2017/10/21(土) 12:52:10.42

v2.15.0-rc2

2017/10/25(水) 20:24:09.18

gitで管理しているファイルの名前を
途中で変えたい場合はどうするのでしょうか？
別ファイルとしてコミットしなおすと履歴が切れてしまうので良くないですよね？

2017/10/26(木) 00:49:44.20

問題なく追従すると思うけど
せっかくgitで管理してるんだから取りあえずやってみたら？

2017/10/26(木) 01:56:49.40

あまりに変更箇所が追跡できなくなるけど、その場合は追跡する意味がない

2017/10/26(木) 05:32:45.60

>>110
git mv
ファイル名変えて元をrmしてaddし直すのと一緒だが

2017/10/26(木) 11:25:04.18

>>112
ほんそれ

2017/10/29(日) 01:27:26.19

なるほど、だから名前の変更だけでコミットするのが良いわけか
使い方の問題だな

2017/10/29(日) 15:12:21.69

Tech Talk: Linus Torvalds on git
https://youtu.be/4XpnKHJAok8?t=330

を見ると　2007/5 の時点でLinus はJunio Hamano って呼んでいる。
浜野氏はこのころからJunio って名乗っていたのか。

ミドルネームのCが何の略なのかはいまだに謎。

2017/10/30(月) 13:33:35.79

mv hoge/index.html index.html
rm -a hoge
git status↓
deleted: hoge/index.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html

git mvし忘れたんですけどこの場合どうやって
index.htmlの履歴が引き継げなくなるのは困ります

2017/10/30(月) 14:36:21.81

mvの履歴なんて保存されないから
普通にaddしてコミットで良い

2017/10/30(月) 22:20:34.55

v2.15

2017/11/03(金) 19:04:58.93

あの、git cloneした場合とreleaseから圧縮ファイルをダウンロードするのはどちらが通信量が少ないでしょうか？
git cloneってgzで圧縮されたパケットですかね？

2017/11/03(金) 19:12:05.26

圧縮されてると思っていいです

2017/11/03(金) 19:43:47.91

gitのv2.5.0のみcloneしたら5.72MiB(約6MB)
v2.15.0.tar.gzのサイズは6.9MB
よってcloneのほうが通信量が少なかったです
圧縮ファイルのほうがサイズ小さいと思ったら以外でした

2017/11/04(土) 02:57:19.66

バージョン違うからじゃね？

2017/11/04(土) 10:07:30.25

じゃねじゃねーんじゃね

2017/11/04(土) 10:45:43.41

あっホントだ！2.5.0と2.15.0だった
いま気付いた

2017/11/04(土) 10:50:00.94

git clone --depth 1 -b v2.15.0 だと7.21 MiB(7.56023296 MB)
tar.gzは6.85MB

tar.gzのほうが軽いですね

2017/11/04(土) 13:28:46.00

プレーンじゃないって判ったらもういいだろ

2017/11/12(日) 21:42:56.70

悪貨がはこびるのは世の常

2017/11/17(金) 00:39:17.76

gitってここ二三年、マイナーバージョンが上がりまくっているが、
お薦めの新機能ってある？

2017/11/18(土) 10:28:12.21

うんこーど対応

2017/11/18(土) 20:06:26.32

>>130
なにそれ？

2017/11/24(金) 19:57:04.44

なぜ git rebase をやめるべきか
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25

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だもんな