GitHub Actions の schedule + cron で本家に追随したい

GitHub で fork したリポジトリで、フォーク元に変更があった場合にフォーク先も自動で追随させたい。しかもローカルの cron 実行や、外部サーバーに依存させないで GitHub だけで完結させたい。

つまり、フォーク元である upstream/master の変更を、ローカルの master に rebase してから merge したものを、リモート先の origin/master に反映させてフォーク元に追随させたいのです。

この時、外部の CI サービスなどを使わずに GitHub Actions の schedule イベントで cron を使って変更をマージさせたいのです。

TL; DR

./.github/workflows/scheduled_sync.yml

# Follow Changes of Forked/Upstream Repository.
#
# This workflow rebase-marge changes from upstream's master to origin's master. 
# - Ref:
#   - https://stackoverflow.com/a/61574295/12102603 by N1ngu @ StackOverflow (EN)
#   - https://qiita.com/KEINOS/items/3bcaa6cea853f6b63475 by KEINOS @ Qiita (JA)

name: Merge upstream branches

# Triggers the action as scheduled
on:
  # Runs on 10 minutes past every hour
  schedule:
    # Ref: 
    #   - https://help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule
    #   - https://crontab.guru/examples.html
    # Cron format:
    #         ┌───────────── minute (0 - 59)
    #         │ ┌───────────── hour (0 - 23)
    #         │ │ ┌───────────── day of the month (1 - 31)
    #         │ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
    #         │ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
    #         │ │ │ │ │                                   
    #         │ │ │ │ │
    #         │ │ │ │ │
    #         * * * * *
    - cron:  '10 */1 * * *'

jobs:
  merge:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Merge upstream
        run: |
          git config --global user.name ${NAME}
          git config --global user.email ${EMAIL}

          # Pass the --rebase-merges option to git rebase by default
          git config --global pull.rebase merges

          # "git checkout master" is unnecessary, already here by default
          git pull --unshallow  # this option is very important, you would get
                                # complains about unrelated histories without it.
                                # (but actions/checkout@v2 can also be instructed
                                # to fetch all git depth right from the start)

          # Add the repo which you forked to the remote and name it as "upstream"
          git remote add upstream ${REPO_FORK}

          # Fetch the upstream branches to local
          git fetch upstream

          # Merge changes
          git checkout master
          git merge --no-edit upstream/master
          git push origin master
        # Change the below to your settings
        env:
          NAME: KEINOS
          EMAIL: github+fork-qiita-news@keinos.com
          REPO_FORK: https://github.com/yyano/Qiita-News.git

• ^{?   注意点: 自分の master（origin/master） をいじりすぎてフォーク元と異なる場合、かなり高い頻度でコンフリクトを起こします。そのため「./.github/workflows/ の YAML ファイルの有無くらいの差」といった、フォーク元と、ほぼ同じ状態で利用するリポジトリ向きです。
  また、当然ですが、自分の master（origin/master） からブランチを切ると、ワークフロー（YAML ファイル）も一緒に付いてきます。この状態でフォーク元（upstream/master）に PR をするとワークフローも一緒に PR してしまいます。相手がよくわからないでマージすると、勝手にアクションが実行されエラーになるので、相手に迷惑をかけないように注意します。}
• GitHub Actions で無料で使える実行時間は約 33 時間/月です。これを越えると、翌月まで使えなくなります。

動作サンプル・リポジトリ

• フォーク元： https://github.com/yyano/Qiita-News
  • from 「Qiitaの新着記事を見たい。なのでQiita APIを叩こう。」 @ Qiita
• フォーク先： https://github.com/KEINOS/Fork_Qiita-News
  • GitHub Action の設定例: https://github.com/KEINOS/Fork_Qiita-News/blob/master/.github/workflows/schedule_sync.yml
  • アクションの実行結果例: https://github.com/KEINOS/Fork_Qiita-News/actions

GitHub App

GitHub Actions でなく、サードパーティーが提供している GitHub Apps を使うなら wei/pull も簡単。

• Githubでフォークしたリポジトリを自動でupstreamに追従してくれる wei/pull の導入 @ Qiita

TS; DR

設定方法

1. リポジトリをフォークして、フォーク元のリポジトリ URL（HTTPS の .git 付き URL）をコピーしておきます。
2. フォークしたリポジトリの GitHub 上にある "Actions" タブから "set up a workflow yourself" を選び、上記（TL; DR）の YAML の内容を設置（コピペ）します。ファイル名は、わかりやすければ何でも構いませんが、拡張子は .yml である必要があります。
3. cron を実行するタイミング／ユーザー／メールアドレス／フォーク元のリポジトリ URL を変更します。
4. Start commit → Commt new file でコミットします。

フォークしたリポジトリの ./.github/workflows ディレクトリにワークフローが追加され、cron で指定したタイミングで同期が始まるので、GitHub の Action タブで成功しているか確認します。

YAML ファイルの設定内容

ワークフローの名前

name: Merge upstream branches

on:
（以下略）

scheduleイベントにcronの実行タイミングを指定する

name: Merge upstream branches

on:
  schedule:
    # cron の設定: https://crontab.guru/examples.html
    # GitHub にはユーザーごとに実行可能な時間の制限があります。合計時間が制限を
    # 超えないように必要最低限のインターバルで実行するようにします。
    - cron:  '10 */1 * * *'

jobs:
（以下略）

mergeジョブをubuntu上で実行する

jobs:
  merge:
    runs-on: ubuntu-latest
    steps:
      - （以下略）

checkoutアクションを使ってリポジトリのclone/checkoutを行う

jobs:
  merge:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: （以下略）

同期処理（pull,rebase,mergeからのpush）

jobs:
  merge:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Merge upstream
        run: |
          # コミット／マージの実行ユーザー情報
          # NAME、EMAIL は下記 env 項目で設定。
          # なお、GitHub のパスワード／トークンは checkout アクションで設定済み。
          git config --global user.name ${NAME}
          git config --global user.email ${EMAIL}

          # デフォルトで git rebase の --rebase-merges を付加
          git config --global pull.rebase merges

          # "git checkout master" は checkout アクションで実行済みなので不要。

          # unshallow オプションで更新情報のみを pull してくる。これを設定しないと、
          # アップストリーム（Fork 元）から pull するときにも、すべてのブランチデータを
          # 持ってきてしまう。
          git pull --unshallow

          # フォーク元のリポジトリの URL をリモート先として登録し、"upstream" と名付ける。
          # REPO_FORK は env で設定。
          git remote add upstream ${REPO_FORK}

          # アップストリームのブランチ情報を取得
          git fetch upstream

          # upstream/master の変更をマージして origin/master にプッシュ
          git checkout master
          git merge --no-edit upstream/master
          git push origin master
        env:
          # コミット／マージを行うユーザー情報とフォーク元の git リポジトリの URL（要変更）
          NAME: KEINOS
          EMAIL: github+fork-qiita-news@keinos.com
          REPO_FORK: https://github.com/yyano/Qiita-News.git

参考文献

• Can forks be synced automatically in gitHub? @ StackOverflow
• $ git pull --unshallow | git-pull @ Git 公式マニュアル
• $ git config pull.rebase merges | git-config @ Git 公式マニュアル
• 【GitHub Actions】CIを使って毎日自動でGitHubに草を生やそうｗｗｗ @ Qiita
• GitHubでFork/cloneしたリポジトリを本家リポジトリに追従する @ Qiita

某プログラミングスクールを卒業したものでまだ、実際に働いた事がないので確証は得られませんが、先日現場で働いている方にGit Hub Desktopを使っていると言ったら笑われました、、、
なのでそれをネタに記事を書いてみる事にしました。

Git Hub Desktopを使ってる理由

単純明快でスクールで勧められたからだけです笑
カリキュラムではgitコマンドは習いましたが次のカリキュラムでは直ぐにDesktopの方を勧めてきてあれよあれよの内に今後の学習では全てDesktopを使う事になり最後の方になるとスクール生の大半はgitコマンドなんてほぼ忘れていたに違い有りません（自分も例外ではない）
プログラミング初心者からしたらGUIで操作出来るDesktopは居心地が良いですし直感的に操作も出来ますのでかなーーり楽出来ますから使わない理由がないでしょうし、スクール内ではそれで困る事は無かったです。

gitコマンドの方が良い理由

私が話したエンジニアの方曰く操作出来る範囲がDesktopでは出来ない事もコマンドでは出来るとの事、具体的に何が出来ないのかはその時聞いていないので分かりませんので気になる方はご自身で調べてください。

スクール生はDesktopを使い続けるべきか？

今スクールに通っている最中は別に使い続けてもいいのかなとは思います。同期の方はDesktopを使っているでしょうし今すぐに変えるべきとは思いません。卒業してからポートフォリオ制作の時からでも遅くはないでしょう。
私は指摘されてからは直ぐにDesktopを使う事は辞めてコマンドでする事にしました。一応習ったとは言え殆ど使ってこなかったのでgithubフローですら最初はコマンドを確認しながらゆっくりやりました。早く慣れたい笑

最後に

もし最後まで読んで下さった現場で働いてるエンジニアの方がいれば実際に使ってるかやDesktopは使わない方がいいかなど教えて下さると幸いです。

過去のこの状態のソースに戻したい！っていうことが時々あります。(特定のコミットまで戻したい)
そんな時には下記コマンドで対応します。自分用メモ。

$ git reset --hard 戻したいコミットのID(SHA-1)

こんにちは。AWS歴３年生の人です。最近、インフラもコードで管理するInfrastructure as Code(IaC)に関連して、Gitを使い始めたのですが、2020年春にAWSからgit-remote-codecommitという新しいGit認証ツールがリリースされたので勉強がてら試してみました。

AWS CodeCommit が新しい Git 認証情報ヘルパーの git-remote-codecommit を導入

注意

• 本記事は2020年7月17日時点でのバージョンで確認しました。

• 記載のコードにつきましては参考となりますので、利用時の不具合について一切の責任を負いません。

結論。こんな方におすすめです。

• AWSがきっかけでGitを使い始める人。
  • AWSが提供しているGitリポジトリへ接続するための認証補助ツールなので。
• Gitの認証設定がうまくいかない人や、.gitconfigファイルの設定が不慣れな人。
  • AWSCLIのCredential設定ができれば、簡単にCodeCommitに接続できるので。

普段からCodeCommit以外のリポジトリや、複数のGit認証情報を使いこなしている方にはこのツールは不要かもしれません。

準備

前提条件である、PythonやAWSCLI、Gitクライアントのインストール、CodeCommitやAWSCLIのCredentialとprofile設定は済んでいるものとします。

参考

ステップ 0: git-remote-codecommit の前提条件をインストールする
ステップ 1: CodeCommit の初期設定

インストール

一行 pip install git-remote-codecommitを実行するだけです

$ pip install git-remote-codecommit
Collecting git-remote-codecommit
  Downloading https://files.pythonhosted.org/packages/bb/f7/1180a1f2319a9120c94f33bba61e1738db8dea31b622f8aaf382f219aaeb/git-remote-codecommit-1.13.tar.gz
Collecting botocore>=1.10.4 (from git-remote-codecommit)
(snip)
Successfully built git-remote-codecommit

依存関係のあるパッケージもあわせて一緒に更新されますが、最後に Successfully built git-remote-codecommit が表示されれば成功です。

参考

ステップ 2: git-remote-codecommit をインストールする

使い方

例えば、AWSのprofile名を project-aとして、リージョン ap-northeast-1 にあるAWS CodeCommitリポジトリ demoappをローカルにクローンしたい場合は以下のようにします。

$ git clone codecommit::ap-northeast-1://project-a@demoapp
Cloning into 'demoapp'...
remote: Counting objects: 40, done.
Unpacking objects: 100% (40/40), done.

以降は、いつものように使うだけでOKです。

毎回profile名を指定する必要はありません。また、インストールさえできれば、GUIでもクローン時に上記のように指定することで同じく使うことができました。

例：pushの例

$ git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0)
To codecommit::ap-northeast-1://project-a@demoapp
   9d88cfd..2247110  master -> master

参考

ステップ 3: CodeCommit コンソールに接続し、リポジトリのクローンを作成する

深掘りしてみる

クローン時に指定した情報がどこに設定されているか探してみたところローカルリポジトリ/.git/configというファイルに記載されていました。

[remote "origin"]
        url = codecommit::ap-northeast-1://project-a@demoapp
        fetch = +refs/heads/*:refs/remotes/origin/*

いままでの認証情報ヘルパーと比べて

いままでは下記のAWSユーザサイトを参考にGitコマンドでGit認証情報ヘルパーを設定していました。

ステップ 3: 認証情報ヘルパーを設定する

個人的には、Git初心者にとってはなかなか難しく

• GitのCredential設定もしないとならない（AWSCLIのCredential設定だけで完結しない）
• Gitクライアントによってはインストール時、もしくは.gitconfigファイルでCredential Manager設定を無効化しないと接続できない場合がある
• 異なるCodeCommitリポジトリの認証を追加したいときに、globalの.gitconfigファイルを変更していた
  • 最近、git configコマンドに--localオプションがあることを知りました

という感じだったので、今回のツールはGit初心者でもGit接続環境を導入しやすくなりました。

まとめ

git-remote-codecommitを使って今までより比較的簡単にAWS CodeCommitに接続することができました。また、新しいツールの調査の過程でGitについても少し理解を深めることができました。

これまでGitやGitHubに関する知識を曖昧な状態にしていましたが、共同の案件で必要だということもあり、独学で学習してみました。

そこで学んだGitのプルリクエストを出してマージするまでの簡単な流れをここに共有します！

目次

• ベースのブランチを最新の状態にする
• リモートリポジトリにプッシュする
• GitHub上でプルリクエストをする
• Reviewerからの変更
• マージする

ベースのブランチを最新の状態にする

最初に、ベースのブランチを最新の状態にします。

実際に共同で開発するときには、リポジトリが常に更新されていくので、作業の始めや終わりにベースのブランチを更新する癖をつけるのが望ましいです。

まずは、カレントブランチがベースブランチになっているかを確認します。

$ git branch
* master

ここで「master」などのベースのブランチになっていることを確認してください。

ベースのブランチになっていなかったら、

$ git checkout master

を実行してください。

次に、ベースのブランチがクリーンな状態になっているかを確認します。

$ git status

問題がなければ、プッシュして最新の状態にします。

$ git pull origin master

これで、ベースのブランチを最新の状態にすることができます。

リモートリポジトリにプッシュする

まずは新たにブランチを作成し、そのブランチに切り替えます。

$ git checkout -b 新しいブランチ名

このコマンドで一気にできます。

次に、変更したファイルの確認を行います。

$ git status

ここで変更したファイルのみが表示されていることを確認してください。

確認ができたら、git addコマンドを実行します。

$ git add -A

個別のファイルごとにコミットするやり方は複雑そうだったので、作業ツリー内の全てのファイルをインデックスに追加するAオプションを実行します。

この後にgit commitコマンドを実行して変更をコミットさせます。

$ git commit -m "ここにメッセージが入ります。"

最後に、変更内容をリモートリポジトリにプッシュします。

$ git push origin master

これで、リモートリポジトリにプッシュできました。

GitHub上でプルリクエストをする

リモートリポジトリにプッシュできて、GitHubのリポジトリのトップページにいくとpushの通知がきていると思います。

通知が来ていたら、「Compare & pull request」ボタンをクリックしてプルリクエストの作成画面にいきます。

プルリクエスト画面でタイトルや説明文を書いて「Create pull request」ボタンを押せばプルリクエストが完了します。

Reviewerからの変更

Reviewerからの変更点を確認して再度プルリクエストを行います。

$ git add -A
$ git commit -m “ここにメッセージをいれる”
$ git push origin HEAD

git push origin HEADでカレントブランチの状態でプッシュできます。

ちなみに、GitHubにある「Reviewer」の項目でReviewerを指定することができるので、評価してもらう人がいる場合には活用できようです。

マージする

Reviewerが変更点を確認して許可すると、マージすることができます。

プルリクエストを実行した人がマージする場合には、「Squash and merge」ボタンをクリックして完了です。

Squash and mergeはプッシュしたコミットのメッセージをすべて表示した状態でマージしてくれます。

まとめ

まだまだおさえないといけない知識はありますが、ひとまずここまで理解しました。

これからも勉強したことをアウトプットしていきます。

svn を使っていたが、git を使い始めると混乱するところ

リポジトリの作成

リポジトリを作成するだけ(Bara)と、すでにあるものをリポジトリ管理する用の二つ作成方法がある。

svn だと、基本的には、初めに空のリポジトリを作成する。すでにソースがある状態からは作れなかったはず

ソースの取得

clone する。

svn だとチェックアウト。これはほぼ同じ。

svn の更新と、git の pull の fetch と merge

git はローカルリポジトリに mastar と origin/mastar の二つが実は存在する。
という前提がわかれば、pull と fetch の違いがすぐわかる。

これは svn にはない発想

• 参考 https://qiita.com/wann/items/688bc17460a457104d7d

commit と push

commit はローカル、push はリモートへソースを反映する。

svn はコミットのみ。ローカルとリモートの発想がない。

プルリクエスト

ブランチで作業している場合に行うことができる

小規模だと全員 mastar で作業しているとできない

svn だと基本全員 trunk しか使わない・・・

プログラミング初学者の発信です。
間違いがあれば、指摘いただけると助かります。

commitの変更履歴をみる

$ git log

ローカルの変更を確認する

$ git status

addの取り消し

間違って違うファイルをaddしてしまった時によく使う。

$ git reset HEAD <ファイル名>

commitの取り消し

HEAD^：直前のコミット
HEAD~{n} ：n個前のコミット

$ git reset --hard HEAD^

commitメッセージの修正

$ git commit --amend "新しいコミットメッセージ"

ブランチの作成

$ git branch <ブランチ名>

ブランチの切り替え

$ git checkout <ブランチ名>

ブランチの削除

$ git branch -d <ブランチ名>

ローカルのブランチをリモートに反映

$ git push -u origin <ローカルのブランチ名>

3ヶ月間でよく使ったのはこれくらいかな。

初めに

この記事は前回の続きで、GCP上に構築したCentOSのVMインスタンスに開発ツールやプログラミング言語をインストールして実際に開発が行える状態を作る記事です。
暇潰しに読んでいただければ幸いです。

CentOSに各種ツールをインストール

今回はPython,Gitをインストールし、Pythonで作ったHello worldをGithub上のリポジトリにコミットするところまでを実施します。

Pythonのインストール

今回はコマンドを利用してインストールしていきます。CentOSにはyumというパッケージマネージャが存在し、pip installやnpm installに似たような形でプログラムをインストールすることができます。
試しにPythonをインストールしてみましょう。

sudo yum -y install python38 #Python3.8をインストール

解説していないsudoというコマンドは、「異なるユーザ権限で続くコマンドを実行する」コマンドです。
sudo -u ユーザ名のように入力することで、そのユーザとしてコマンドを実行することができます。何も指定しない場合はrootユーザ(管理者権限)として実行します。

yum installコマンドはroot権限を要求するので、rootユーザでない場合はsudoコマンドが必要になります。
-yはyum installのオプションで、全てyesと答えたことにするものです。

Installed:
  python38-3.8.0-6.module_el8.2.0+317+61fa6e7d.x86_64                                                                
  python38-libs-3.8.0-6.module_el8.2.0+317+61fa6e7d.x86_64                                                           
  python38-pip-19.2.3-5.module_el8.2.0+317+61fa6e7d.noarch                                                           
  python38-pip-wheel-19.2.3-5.module_el8.2.0+317+61fa6e7d.noarch                                                     
  python38-setuptools-41.6.0-4.module_el8.2.0+317+61fa6e7d.noarch                                                    
  python38-setuptools-wheel-41.6.0-4.module_el8.2.0+317+61fa6e7d.noarch   

こんな感じのログが表示されていれば、Pythonとその周辺ツールのインストールは完了です。MacOSやWindowsと同じように、pythonコマンドで実行できるようにしましょう。

alias python="python3.8"
alias pip="pip3.8"

aliasコマンドは、新しいコマンドを登録するコマンドです。このコマンドを実行することで、pythonコマンドで、python3.8のbinを、pipコマンドでpip3.8のbinを実行できるようになります。

python --version
Python 3.8.0

pip --version
pip 19.2.3 from /usr/lib/python3.8/site-packages/pip (python 3.8)

ここまででPythonのインストールは完了です。お疲れさまでした。

Gitのインストール

yum installでインストールされるGitは2.1.9と少し古いので、パッケージをダウンロードしてインストールする方法を取ります。
今回はまっさらなCentOSなので、依存ライブラリを含めてダウンロードしましょう。

sudo yum -y install gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker autoconf wget

gitのダウンロードサイトからインストールしたいバージョンのリンクをコピーします。今回は最新がいいのでgit-2.9.5.tar.gzのリンクをコピーしました。
wgetを使ってtar.gzファイルをダウンロードしましょう。（この時、任意のディレクトリを作成しておくと便利です。）

sudo wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.9.5.tar.gz

以下のようなログが表示されていればダウンロード完了です。

‘git-2.9.5.tar.gz’ saved [5928730/5928730]

ダウンロードしたファイルを解凍して、インストールします。

sudo tar xzvf git-2.9.5.tar.gz

sudo rm -rf git-2.9.5.tar.gz

yum -y install make 

sudo make prefix=/usr/local all
sudo make prefix=/usr/local install

tarコマンドは、tar.gzファイルの解凍を行うコマンドです。tar.gzは圧縮形式の一つで、zipやjarに近いイメージです。

rmコマンドは削除をします。オプションの-rが再帰的に削除、-fが確認メッセージを表示しないという意味を持ちます。rm -rf /と入力すると一発でクビが飛びますよ！　

makeコマンドは、ソースコードからインストールを行うコマンドです。 make ~ allが、コンパイルを、make ~ installがインストールを担当します。

いつもので動作確認をしてみましょう。

git --version
git version 2.9.5

GitHubリポジトリをクローン

適当にリポジトリを作成して、クローンしてみましょう。
(適当に筆者のQitta夏祭り用リポジトリをクローンしてきました)

git config --global user.name "ユーザ名"
git config --global user.email 任意のメールアドレス

git clone https://github.com/mamoru12150927/festivalFrontend.git

VSCode上で「フォルダを開く」ボタンをクリックすると、cloneしたディレクトリにリポジトリ名と同名のディレクトリが存在するはずです。

次はcommitしてみましょう。試しにただのHello worldですが…

test.py

def hello() :
    print("hello world")

hello()

ctrl + shift + gでソース管理タブを開き、変更をステージ（＋ボタン）を行い、コミットします。（✓マーク）

コミットしたあとに、メニュー（…）から同期(Sync)を選択すると、Github上のリモートリポジトリに変更が反映されているはずです。

終わりに

ここまでで、最低限の開発が行える様になりました。取り上げませんでしたが、pipによるパッケージのインストールも可能ですので、面倒な作業は必要ですが学習目的であれば困らないはずです。筆者もDockerやります

はじめに

自分が日常的に使っているgitコマンドとそれを使う理由（？）のようなものを備忘録がてらまとめる

なお、チーム開発かつGitHubやBitbucketなどを利用することを想定している

変更をステージング

$ git add [ファイル名]

全ての変更を一括でステージング（あまり使わない）

これはあまり使うべきでないかと（個人的な意見）
そのコミットに含めるべきでない変更点までコミットしてしまう危険性があるため

$ git add .

コミット

コミットメッセージは英語でも日本語でも良いので基本的につける

$ git commit -m "コミットメッセージ"

リモートのhogeブランチにプッシュ

たまにプッシュに失敗することがあるが、リモートリポジトリの権限が原因であることが多い気がする
リポジトリをいじれる権限が与えられているか、sshkeyが追加されているか、など確認すれば解決は難しくないはず

$ git push origin hoge

rebaseした後はローカルとリモートのブランチで整合性がとれないため、強制プッシュする必要あり
（rebaseについては後述）

$ git push -f origin hoge

リモートのhogeブランチをプル

プッシュと同じく、失敗することがたまにあるが、原因はプッシュできない場合とおそらく同じ

$ git pull origin hoge

ローカルにあるブランチ一覧の確認と現在いるブランチの確認

$ git branch

ローカルブランチの削除

例えば、feature/hogeブランチをリモートにプッシュし、そのブランチがリモートでdevにマージされた場合、ローカルのfeature/hogeブランチは不要になる
不要なブランチは削除する必要あり

$ git branch -D feature/hoge

最新のコミット確認

$ git show

ログ確認

基本的に見やすくなるためのオプションをつけて使う

# オプションなし
$ git log

# 見やすくするためのオプション
$ git log --graph --oneline

ブランチの分岐点を修正する

rebaseを使う
rebaseは共同開発でめちゃくちゃ使う
developブランチに対してrebaseすることが多いかと

※厳密には、rebase＝ブランチの分岐点を修正、ではないので注意

# 現在のブランチをdevelopブランチにrebaseする
$ git rebase develop

rebaseを使う場面

基本的な開発は以下の流れで進むと思う

• developブランチからfeature/hogehogeなどといったブランチを切って作業する
• 作業終了後、developブランチにマージするようなプルリクエストをGitHubやBitbucket上で作成する
• プルリクが承諾されたらいよいよマージ

このマージされる段階で、feature/hogehogeブランチはdevelopブランチの先端から生えている必要がある
もし先端から生えていない（つまりfeature/hogehogeブランチを作成したときよりもdevelopブランチが進んでいる）場合、rebaseが必要になる

コミットをまとめる

こちらでもrebaseを使う

# 最新のコミットとその1つ前のコミットをまとめる
$ git rebase HEAD~~

上記のコマンドを叩くと、vimエディタが開き、下記のようなものが表示されるかと

pick コミットID コミットメッセージ
pick コミットID コミットメッセージ

上記を下記のように修正

pick コミットID コミットメッセージ
s コミットID コミットメッセージ

コミットメッセージを編集する画面に移るので、編集すればOK

参考
rebase -i でコミットをまとめる - Qiita

一時退避、stash

別のブランチに移動して作業したい
でも、現在のブランチでの変更はコミットしたくないし、変更点を他のブランチに持っていくこともしたくない（addする前の変更点はブランチ移動すると一緒に持っていくことができてしまう）

そんな時にstashを使う
名前やメッセージをつけてstashすると管理しやすいかと

# 現在stashされているものの一覧確認
$ git stash list

# 名前というかメッセージをつけてstashする
$ git stash save [メッセージ]

# stashしたものを戻し、stash一覧から削除
# nはstashした際に自動的に振り分けられる番号、stash listで確認できる
$ git pop stash{n}

後からgitignoreを適用させる

.gitignoreファイルに無視したいファイルを記述しても、すでにgit管理下にある（追跡されている）ものは無視してくれない
このような場合、対処法は2パターン

その1

# キャッシュを全て削除（git管理下から全て削除）する方法
$ git rm -r --cached .

その2

# .gitignoreファイルの内容を反映させる方法
$ git rm --cached `git ls-files --full-name -i --exclude-from=.gitignore`

上記のいずれかをやった後、addしてコミットすればOK

参考
あとからまとめて.gitignoreする方法 - Qiita

さいごに

rebaseコマンドを使う部分に関しては、誤解を生むような表現を用いている可能性が高く、また、本記事通りのコマンドを使っても上手くいかない場面も多いかと思うので、別途調べていただければ

修正点や追加点などあれば随時更新する

概要

プログラミングの勉強を始めて1ヶ月目でよく使ったgitコマンドです。
まだ勉強を初めて3ヶ月とかですが、参考にしてください。
間違いがあれば、指摘をいただけますと助かります。

初期設定

この設定を行うことでgit hubに草を生やすことができる。
pushをしても草が生えないときはこの設定を忘れていることが多い。（多分）

$ git config --global user.name "XXXX"
$ git config --global user.email "XXXX@hogehoge.com"

ローカルにリポジトリを作成しリモートにpush

新規でリポジトリを作成して、pushするときはこの流れ！
git add * の「*」は「全てのファイル」を意味する。

$ git init
$ git add *
$ git commit -m "Initial commit"
$ git remote add origin https://github.com/XXXX/XXXXXX.git
$ git push -u origin master

現在のリポジトリを確認

$ git remote -v

リモートの変更をローカルに反映

$ git pull