スポンサーサイト

2023.04.20 Thursday
0

    一定期間更新がないため広告を表示しています

    category:- | by:スポンサードリンク | - | - | -

    git簡易コマンドメモ

    2022.07.17 Sunday 17:58
    0
      git作業メモ

      久しくさわらないと忘れてた。
      単純にローカルで履歴とりたい場合はこれぐらいで十分

      ★初期設定
      # git init

      ★ステージングにup
      # git add hoge1.txt

      ★commit
      # git commit -m "init commit dayo"

      ★branch 作成
      # git branch develop

      ★branch 状態表示
      # git branch
      develop
      * master

      ★branch 切り替え
      # git checkout develop

      # git branch
      * develop
      master

      ★log表示
      # git log --oneline

      ★commitしてしまったものを戻す(指定バージョンに)
      # git reset --hard {戻したいversionのコミットハッシュ値} ★上記logで確認したversionでチェックしたもの

      ★ファイル内容比較
      # git diff
      category:Git | by:ittoocomments(0) | - | -

      Gitについてまとめメモ

      2015.12.29 Tuesday 05:44
      0
        Gitを仕事で使いそうなのでちょっと勉強

        参考URL
        http://qiita.com/YusukeHosonuma/items/14c59f3878d640a401a1
        http://www.slideshare.net/kotas/git-15276118
        http://www.slideshare.net/matsukaz/git-17499005?related=1
        ------------------------------------------------
        http://www.slideshare.net/matsukaz/git-17499005?related=1

        subversionとgitでは commit のやる内容が違う

        ■subversionの場合


        subversion
        commit:リポジトリ(共有サーバー上の)
        update:ローカル更新

        ■gitの場合


        git
        commit:ローカルリポジトリ反映
        push :ローカルから、リモートリポジトリへ反映
        fetch :リモートリポジトリから、更新を取得
        merge/rebase:リモートリポジトリの更新をローカルに反映させる

        gitではほとんどの操作が、ローカルで完結する
        (push fetch以外)


        ■データ領域
        gitで大事なデータ領域は3つ
        ・ワークツリー(作業ディレクトリ)
        ・ステージングエリア(インデックス)
        ・Gitリポジトリ








        git init git管理を開始する



        git add
        リポジトリに追加したい対象を指定する

        ファイルを修正した場合も git add
        git add . 「.」はすべての未登録ファイルがステージされる



        git commit -m
        更新内容をリポジトリに登録する



        git rm
        ファイルを削除する
        git rm dir1/dir2



        rmでファイル削除後はその内容を反映(コミット)させる

        git mv :ファイルやディレクトリを移動する

        git status :ワークツリーの状態をみる

        git log :コミットログをみる

        ブランチとはメインと、別の流れで作業を続ける機能


        git merge :現在のブランチに指定ブランチをマージする

        git clone :リモートリポジトリを ローカルに複製
        git clone git@github.com:a/b.gif




        ------------------------------------------------------------
        ------------------------------------------------------------
        ------------------------------------------------------------

        http://www.slideshare.net/kotas/git-15276118

        % git checkout -b foo master(= git checkout -b foo 4714e3cf1826) ブランチ名の代わりにリビジョンを指定も可能
        % git show master (= git show 4714e3cf1826)
        % git branch topic master (master から topicをつくる) ブランチをつくることは、こみっとのさらなる別名をつくるのと同じ

        ★マージ
        gitのマージには2種類ある(Fast-Forward 早送り:元が変更されてないなら使えそう/ Non Fast-Forward 早送りではないマージ:元が変更されてた後なら、使えそう)
        ---------------------
        git merge topic  歯や送りできればする、無理なら普通のマージ
        git merge --no-ff topic 常に普通のマージ
        git merge --ff-only topix 常に早送りする(できなければエラーとする)
        ---------------------
        Fast-Forwardの弊害1 ブランチをマージしたという事実がれきし(コミットグラフ)に残らない

        git revert  
        (リビジョン)のコミットを取りけすためのコミットをつくる

        git reset --hard
        (リビジョン)時点の状態まで完全にまきもどす

        Fast-Forwardの弊害2
        ブランチのマージを取りけしづらい

        ■まとめ 2種類のマージ
        ---------------------------------
        Fast-Forward : 早送り
        ・コミットグラフとしてけっかが同じなら、同じコミットまで進めてしまうこと
        ・「マージした」という記録が残らない
        ・マージを取りけしづらい

        Non Fast-Forward 普通のマージ
        ・gitが頑張って計算するマージ
        ---------------------------------

        ★rebase
        git rebase master
        masterから取得し、その上にこれまでの変更点を反映させる
        rebaseで創られたコミットは、元のコミットとほぼ同じ内容だが別のコミットになる
        (中にある1つ前の内容が違うので、正しくは別のコミットは別物)

        ★git push origin topic
        topic を origin(サーバー)に同期
        localにあるコミットされてる内容をサーバーにアップする

        pushされているブランチを rebaseすると pushできなくなる
        よって共有のブランチでは、rebaseしてはいけない。

        絶対NGなの。push -f
        push -f で強制で上書きpush可能だが、他の人がpullする時にマージする必要があったり
        コミットログがおかしなことになるのでしてはあかん

        mergeだとコミットがいくつあろうとコンフリクト解消は一度だけ
        したがって rebaseより mergeの方が楽

        リベースの功罪
        □よい点
        ・コミットグラフがきれいになる
        →マージ後のログがきれいにあるので、masterにマージする直前にするのはOkとすることがある
        ・githubなどのオープンソースプロジェクトにプルリクエストを送る場合は
        rebaseしてから送るのがマナー
        □悪い点
        ・pushされたブランチをリベースすると push不可能になる
        ・マージしたという事実が失われる
        ・マージと比較すると、コンフリクト解消が面倒

        ------------------------------------
        category:Git | by:ittoocomments(0)trackbacks(0) | -

        ad
        Calender
             12
        3456789
        10111213141516
        17181920212223
        24252627282930
        31      
        << March 2024 >>
        Selected entry
        PR
        Category
        Archives
        Recommend
        Link
        Profile
        Search
        Others
        Mobile
        qrcode
        Powered
        無料ブログ作成サービス JUGEM