Git 17
レス数が950を超えています。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 >>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あるある レス数が950を超えています。1000を超えると書き込みができなくなります。
