20200629のGitに関する記事は8件です。

Githubのチーム開発基本パターン

Githubのチーム開発基本パターン

Githubのチーム開発に慣れていなかった頃はやり方を基本パターンで覚えて、コンフリクトなどイレギュラーな事態が起きたら調べたりチーム同士で確認していました。
その時の自分なりの基本パターンです。
すでにリモートに共同開発用のリポジトリがあることが前提です。

1.新規ブランチをマスターの内容を継承して作成(必要に応じて)
git checkout -b

2.変更内容をステージに上げる
git add .

3.コメントつけてコミット
git commit -m '○×△◻︎(変更内容がわかりやすいものを英文で)'

4.リモートにプッシュ
git push origin HEAD

ここまでが自分、並びに紐づいた相手のリモートに上げる方法

次は相手のリモートからマスターを持ってきて自分のローカルのマスターに内容を反映させる方法。

5.自分のブランチをマスターにする
git checkout master

6.どこがリモートかチェック、(upstreamを見る。)
git remote -v

7.リモートのマスターから情報を取得してそれをローカルのマスターに反映させる
git pull upstream master

8.トピックブランチに切り替えて

9.マスターをトピックに反映
git merge master

/////
もしくは
7.の段階。マスターの状態で切り替えて適当なブランチを作ってそこにマスターの情報を逃す。
そしてそれからそのブランチをトピックに反映させる。
/////

リモートにマージ後↓

10.ローカルのマスターに切り替える
git checkout master

11.自分のローカルを最新に
git pull upstream master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2に立てたJenkinsのソースコード管理でGitHubを使う方法

概要

AWS EC2に立てたJenkinsのソースコード管理でGitHubのprivateリポジトリを使う。
なかなかうまくいかなくてハマったので備忘録を兼ねてメモ。

環境

  • AWS EC2(OS: Amazon Linux 2)
  • Jenkins 2.235.1

1. Jenkinsにgitを認識させる

これに気付かずめっちゃハマった。

  • Jenkinsの管理 > Global Tool Configuration からGitを設定する
    • install済のgitのパスを指定する
    • 自動インストールを選択する
  • どうせgitは使うと思うので、サーバーにgitをinstallして設定した
$ sudo yum install -y git
$ git --version
git version 2.23.3
$ which git
/usr/bin/git

jenkins_git.png

2. 公開鍵と秘密鍵を作成する

  • /var/lib/jenkins/.ssh/に鍵を作成する
    • 公開鍵: id_rsa_github.pub
    • 秘密鍵: id_rsa_github
  • パスフレーズはなしでOK
  • デフォルトだとjenkinsユーザーにスイッチできないのでrootで作成して所有者を変更する
    • /etc/passwd/を見るとjenkinsユーザーは/bin/false
// .sshディレクトリを作成する
$ cd /var/lib/jenkins/
$ sudo mkdir .ssh
$ sudo chmod 700 .ssh/
$ ls -la | grep ssh
drwx------  2 root    root       6 Jun 29 15:08 .ssh

// 鍵を作成する
$ sudo su -
# cd /var/lib/jenkins/.ssh/
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): id_rsa_github
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa_github.
Your public key has been saved in id_rsa_github.pub.

// 所有者を変更
# chown jenkins:jenkins id_rsa_github.pub
# chown jenkins:jenkins id_rsa_github
# cd ../
# pwd
/var/lib/jenkins
# chown jenkins:jenkins .ssh/
# ls -la | grep ssh
drwx------  2 jenkins jenkins   52 Jun 29 15:14 .ssh
# exit

3. .ssh/configを作成する

  • id_rsa以外の名前で作成した場合はconfigで設定する必要あり
    • id_rsaの場合はデフォルトで見に行くので不要(のはず)
$ sudo touch .ssh/config
$ sudo vi .ssh/config
Host github.com
  HostName github.com
  IdentityFile ~/.ssh/id_rsa_github
  User git

// 所有者を変更
$ sudo chown jenkins:jenkins .ssh/config

4. GitHubに公開鍵を登録する

  • pullできれば良いので、リポジトリのDeploy Keysに登録する
  • Settings > Deploy keys > Add deploy key github_keys.png

5. ssh接続の確認

  • サーバーからsshが通るか確認しておく
$ sudo -u jenkins ssh -T github.com
Hi tamorieeeen/repositpry_name! You've successfully authenticated, but GitHub does not provide shell access.

6. JenkinsのJobで設定する

  • ソースコード管理でGitを選択
  • リポジトリ
    • リポジトリURL: GitHubのClone with SSHのURL
    • 認証情報: なし
  • 今回はサーバー上でid_rsaを管理しているので認証情報はなしでOK

jenkins_job_git.png

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PowerShellでヘッダーにGitの情報から自動的に作成日時と変更日時を挿入してみた

動機

大量の .h ファイルと .cpp ファイルに以下のようなヘッダーを挿入しなければいけない
image.png
140ファイル近くあるソースコードのヘッダーに手作業で日付を入れるのは無理だと考えた。

ヘッダーを入れるためには?

今回ヘッダーを全ソースファイルに挿入するために Visual Studio の拡張機能の License Header Manager を使用した。

以下のテンプレートファイルを作成した。あとで置き換えるためにプレイスホルダー ${created_date}${modified_date} を作成した。
(なお、${ydeagames} は後で名前に置き換える予定だ。)

3DShootingGame.licenseheader
extensions: designer.cs generated.cs
extensions: .cs .cpp .h
// Copyright (c) 2019-2020 ydeagames
// Released under the MIT license
// https://github.com/ydeagames/3DShootingGame/blob/master/LICENSE
//
// Author: ${ydeagames}
// Created: ${created_date}
// Modified: ${modified_date}

プロジェクトを右クリックして License Headers > Add License Headers to All Files を選ぶことですべてのファイルにヘッダーを挿入できる。
image.png

プレイスホルダーを日付に置き換えよう

今回置き換えるために比較的簡単な、PowerShell を採用した。

Gitでのファイルの作成日は

git log --diff-filter=A --follow --pretty="format:%ci" -1 -- $file.Path

最終変更日は

git log -1 --pretty="format:%ci" $file.Path

で取得できる。

ソリューションがあるフォルダに PowerShellのバッチファイルである .ps1 ファイルを作成した。

作成日時置き換え

ReplaceCreationDate.ps1
$sel = '\${' + 'created_date' + '}' # 置き換える対象

# 対象を含むファイルをループ
foreach ($file in Get-ChildItem . * -Recurse -Force | Select-String $sel -casesensitive)
{
    Write-Host "Processing " -ForegroundColor Red -NoNewline
    Write-Host $file.Path
    # Gitの作成日時を取得
    $gitCreated = git log --diff-filter=A --follow --pretty="format:%ci" -1 -- $file.Path
    Write-Host 'Created: ' + $gitCreated
    ((Get-Content -path $file.Path -Raw) -replace $sel,$gitCreated) | Set-Content -Path $file.Path
}

変更日時置き換え

ReplaceModifiedDate.ps1
$sel = '\${' + 'modified_date' + '}' # 置き換える対象

# 対象を含むファイルをループ
foreach ($file in Get-ChildItem . * -Recurse -Force | Select-String $sel -casesensitive)
{
    Write-Host "Processing " -ForegroundColor Red -NoNewline
    Write-Host $file.Path
    # Gitの変更日時を取得
    $gitModified = git log -1 --pretty="format:%ci" $file.Path
    Write-Host 'Modified: ' + $gitModified
    ((Get-Content -path $file.Path -Raw) -replace $sel,$gitModified) | Set-Content -Path $file.Path
}

プレイスホルダーを日付に置き換えることができた。めでたしめでたし。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Git】ブランチがどのコミットを指しているか確認するコマンド

--decorateオプションをつける。

git log --decorate

これでOK。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindoesのGit diff等で日本語を表示する方法

はじめに

WindowsのGitで日本語が含まれるファイルをdiff等で表示しようとした際に、\nnn等の文字列にエスケープされてしまい、正しく表示されなかった。

設定方法

下記のコマンドでGitで表示される、日本語が表示される。

Gitの日本語化設定
git config --global core.quotepath false
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitを触り始めてからGithubにpushするまでの流れを誰よりも丁寧に説明する

前回は、そもそもGitでバージョン管理するメリットはなんなのかを説明しました。

おさらいはこちらから。
なぜ僕らはGitでバージョン管理をするのか

メリットはこうでしたね?

  • セーブ機能「コミット」により過去の状態に戻れる
  • 他人にコードの意図を伝えやすくする

なんとなーく理解できたのではないでしょうか。

じゃあ早速Gitを触ってみよう!
…と思ったはいいが、どうすればいいかわからない!!!

そもそもターミナルの使い方よくわからないし?
コマンドって何?

なんかGithubってのも使うみたいじゃん!

初学者というのは、熟練者が当たり前と思っているところに疑問を持つものです。
この記事ではそれらを丁寧に潰していきます。

チュートリアルっぽくなってるので、是非手を動かしながら理解していってください。

忙しい人は、こちらに要点をまとめておきましたのでどうぞ。

前提

  • Macユーザーが対象です(Windowの人は多少読み替えてください)
  • Gitがインストールされているものとします(Macなら既にインストールされています)
  • Githubアカウントを持っているものとします(ググって説明記事をなぞれば大丈夫です)
  • GitとGithubを連携して使います(Githubの説明はあとで)

この記事のゴール

  • GitGithubを扱うためのターミナル操作ができるようになる
  • コミットできるようになる
  • Githubと自分のコードとを同期することができる
  • 上記までのコマンドの意味を理解できる

たったここまでに達するにも、様々な記事では省略されている分かりにくい箇所がいくつもあります
それらを丁寧に説明していきますので、ゆっくりと進んでいきましょう!!!!

超ざっくりターミナルの使い方

Qiitaやブログなどでこんな表記を見たことがあると思います。

Qiitaでよくある表記
$ git commit -m 'first commit' 
先頭の$ってなに!?

いきなり出てくる$って何者!?

先頭の$は、ターミナルでこのコマンドを打つよ!という意味です。
$は実際にターミナルに打ちません!ややこしいですね。

実際にターミナルに打つべきコマンド
git commit -m 'first commit'
$ はつけないよ!!

$がついていたら、ターミナルで打つコマンドなんだなーと覚えておいてください。

さて、ターミナルでpwdと打って実行してみてください。
現在ターミナルが指しているフォルダ(カレントフォルダ)が表示されます。

現在のフォルダを出力する
$ pwd

どこのフォルダでコマンドを実行するか、がとても重要です。
後述しますが、gitコマンドを実行するには.gitがあるフォルダにいる必要があります。

カレントフォルダを変えるには、cd フォルダの場所を実行します。

カレントフォルダを変更する
$ cd フォルダの場所

フォルダの場所(パス)の指定方法はググってください!!!
このへんがとても参考になります。

コマンドとは

先ほどからコマンドという言葉が出てきています。
コマンドとはその名の通り、命令を出して何らかの処理をするものです。

コマンドの指定方法

1単語

lspwdのように1単語で指定できるものがあります。
OSの基本的な操作が多いですね。

複数の単語

git commitのように、複数の単語を繋いで使うこともあります。
この場合、ツール名 コマンド名という関係になっています。
つまり、gitというツールのcommitというコマンドを実行する、ということですね。

オプション

-a のように -(英字) を付与することで、コマンドにオプションを指定することができます。
具体例で言うと…

オプションなし
$ ls
カレントフォルダにあるファイルとフォルダを一覧表示する
オプションあり
ls -a
カレントフォルダにあるファイルとフォルダを一覧表示する(隠しファイルも表示する)

こんな感じに使います。

引数

プログラミングの引数と同じように、コマンドにも引数があります。
先ほどの例git commit -m 'first commit'で言うと、'first commit'が引数ですね。

$ git commit -m 'first commit'
ツール名 コマンド名 オプション 引数

さて、そろそろGitの使い方に入っていきたいのですが、
その前にGitとGithubの違いについて軽く説明をしておきます。

GitとGithubとの違い

Git

前回の記事で説明した通りのバージョン管理ツールです。便利
ローカル(各自のPC)でバージョンを管理するもの。

Github

Gitをみんなで共有するためのツール。便利
各自がローカルで管理しているGitをオンラインで結びつける(hub)役割をする。
リモート(Githubのサーバー)でバージョンを管理する。

各自がローカルで行った変更をGithubに反映することで、開発チーム全員が同じコードを共有できるようになります。
その他、デプロイ(本番サーバにソースコードを反映すること)をGithubと連携して出来たりなんだり、素敵なメリットがいっぱいあります。
とりあえずGitとセットで使っておこう!!

リポジトリとは

リポジトリ

ソースコードが入っていてGitで管理しているフォルダのことです。
なぜかかっこよくこう呼びます。こわがらないで。

リモートリポジトリ

Github上のリポジトリを、リモートリポジトリと呼びます。
リモート(remote: 遠くの、遠隔の)なので、オンラインのリポジトリという意味ですね。
リモートリポジトリを複数人で共有することで、全員が同じバージョンのコードを扱えます。

ローカルリポジトリ

反対に自分のPC上のリポジトリを、ローカルリポジトリと呼びます。
ローカル(local: 地元の、現地の)なので、自分個人のリポジトリという意味ですね。
基本的にコミットなどのGitコマンドは、カレントフォルダをこのローカルリポジトリに設定しないと実行できません

Gitを始めよう!!!

よーーーーやく、Gitを触っていきます!!!!

ローカルリポジトリを作成しよう

ローカルリポジトリとは、自分のPC上の(ローカル)ソースコードが入っているフォルダ(リポジトリ)でしたね。
みなさん、ある一つのシステムごとにソースコードをフォルダ分けしているかと思います。
それらをリポジトリにしていきましょう。

え?もうフォルダでまとめているからリポジトリじゃないの?

そう思いますよね。でも違うんです。
Git管理をしてはじめてリポジトリとなります。
このフォルダをGitで管理しろ!という命令をGitに出さなければなりません。
そう、コマンドを使います。

まずはターミナルでのカレントフォルダをソースコードが入っているフォルダに移動してください。

カレントフォルダの移動
$ cd ソースコードが入っているフォルダのパス

次にカレントフォルダをGit管理する命令を出します。
初めてのGitコマンド!やったね!

ローカルリポジトリ作成
$ git init

gitツールのinit (initialize: 初期化する)コマンドを使いました!!!!
このフォルダはGit管理され、ローカルリポジトリとなることができました。

このコマンドで何が起こったのでしょうか?
lsコマンドを使ってリポジトリの中身を見てみましょう。

ls…カレントフォルダの中身をリストで表示する
$ ls

(ファイル名がずらーっと並ぶ)

何も変わったことは無いように見えます。
それではls -aと、 -a オプションをつけてもう一度。
このオプションをつけると隠しファイルも表示します。

-aオプションをつけると隠しファイルも表示する
$ ls -a

.git (ファイル名がずらーっと並ぶ)

.gitというファイルが表示されたと思います。
.gitがあるフォルダをGitは管理します。これでフォルダがリポジトリとなることができたのです。
つまり、git init とは.gitを生成するコマンドということです!!

ローカルリポジトリとなったので、他のGitコマンドを使えるようになりました!
早速バージョン管理していきましょう!

コミットしてみよう

今は、Git管理はしているけどもまだ何もコミット(セーブ)していない状態です。
いよいよコミットするときがきました!!git commit!!!!!

$ git commit

(色々表示される)
nothing added to commit but untracked files present

なんか表示されましたね。これ、コミットできていません
nothing added to commit but untracked files present
何もコミットするために追加されてないよ。でも未追跡ファイルがあるよ。

なんのこっちゃ…と思いますが、実はコミットする前に「何をコミットするのか」を指定する必要があります。
そのコマンドがこちら、git add ちゃんです。

何をコミットするのか決めよう

以下のように、git addで何をコミットするのかを指定します。
その後にgit commitでコミットします。

$ git add コミットしたいファイル名

ファイル名を全て指定するのは面倒なので、全てをコミットするファイルと指定する場合はgit add .と書けます。
今回は全てをコミットしたいので、このコマンドを打ってみてください。

$ git add .

そして、git statusを実行してください。

$ git status

On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
     new file:   (ファイル名)
     new file:   (ファイル名)
     ...

色々とファイル名が表示されましたね?
これらのファイルをコミットする準備ができた、ということです。
git statusは何をgit addしたかを確認するコマンドです。必ずしも実行する必要はないです。

ちなみに、git addでコミットの準備をすることを「ステージング」と呼びます。

実際にコミットしてみよう

待ちに待ったgit commit!!!!!!

$ git commit

なんか妙な画面が出てきたと思います。こんなの。

コミットメッセージ入力画面
(ここにコミットメッセージを入力します)
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
#       new file:   ~~~~
#

これはコミットメッセージをする画面です。
ターミナル上で、viまたはvimというエディタが起動しています。
ここでコミットメッセージを入力し、エディタのコマンドで保存すると、コミットが完了します。
わかりにくいですね。

とりあえずやってみましょう。手順はこんな感じです。
(vi、vim以外のエディタの方は何とかしてください)

  1. キーボードのiを押して入力モードに変更
  2. first commit と入力(これがコミットメッセージになります)
  3. キーボードのescを押してコマンドモードに変更
  4. :wq と入力してエンターキー(保存して閉じるコマンドです)

vimの操作の詳細に関してはこのへんを参照ください。

実際の画面はこんな感じ。この画面でエンターを押すと保存され閉じられます。
スクリーンショット 2020-06-26 8.48.05.png

はいこれでようやくコミットが完了しました!!おめでとうございます!!
あとは編集したら都度git add git commitをしていきます。

ちなみに…git commit -m コミットメッセージとすれば、エディタを開くことなくコミットメッセージを書くことができます。お好きな方をどうぞ。

なぜコミットの前に git add を挟むのか?

こんな疑問を持った方もいるのではないでしょうか?
僕は持ちました。直接コミットすりゃいいじゃん

前回ちょろっと説明したとおり、コミットを細かくして他人にコードの意図を伝えるためです。
仮にgit addがなく、編集してあるものをすべてgit commitするしかない仕様を考えてみましょう。


あなたは2つの新規機能を開発しています。それぞれ新規ファイルが1つずつ必要です。
順調に実装が進み、無事2機能・2ファイルを書き終えました!
ここまでコミットをしていなかったのでコミットしとこう…


git addが無いと、2ファイルを同時にコミットすることになります。
つまり、git add .しかできないということと同じです。

$ git add .
$ git commit -m '新機能1と2を実装' 

1コミットに意味の違う2ファイルが含まれます
どちらのファイルがどちらの機能なのか、分かりにくいですよね?

git addがある場合だとこうできます。

$ git add (1ファイル目)
$ git commit -m '新機能1実装'

$ git add (2ファイル目)
$ git commit -m '新機能2実装'

編集済みのファイルが複数あっても、このようにコミットを分けることが可能です。

編集しながら適切な単位でコミットできれば理想なのですが、実際はそういきません。
ある程度編集して、後からコミットすることが日常茶飯事です。

コミットの目的の一つは「人にコードの意図を伝えること」でした。
git addでコミットの単位を適度に分割することでその目的を達成できます。

git add -pを使えばファイル単位でなく行単位でコミットする箇所を選択できます。詳しくはググってみてください。)

Githubと連携しよう!

Gitの真価を発揮するには、Githubと連携すべきです。(異論は認めます)
連携していきましょう!!

リモートリポジトリを作る

リモートリポジトリとは、Githubにあるリポジトリのことでしたね。
みなさん自分のGithubアカウントを持っていると思います。ない人は作っといてください。

自分のGithubアカウントにリモートリポジトリを作り、ローカルリポジトリと紐付けていきます。

スクリーンショット 2020-06-24 18.59.44.png

右側のNewを押してください。
そうすると、↓の画面になります。

スクリーンショット 2020-06-24 19.21.36.png

リポジトリの名前、説明を入力。
Public(誰でもアクセスできる)かPrivate(自分しかアクセスできない)かはお好みで。
今回、Initialize this repository with a READMEチェックはつけないでください。

(チェックをつけるとReadme.mdというファイルがリモートリポジトリに生成されます。この記事の一番最後に行うgit pushの時に不都合が起こるので、チェックはしないでください。)

スクリーンショット 2020-06-24 19.23.20.png

こんな画面が出てきたと思います。
これだけでリモートリポジトリが作成できました!しかし、中身はまだ何もありません。

これからすることは、上記画像の一番下...or Push an existing repository from the command lineの対応と同じです。
まずはリモートリポジトリとローカルリポジトリを紐づけていきます。

リモートリポジトリとローカルリポジトリを紐づける

ローカルリポジトリにリモートリポジトリのURLを教えてあげます。

そのためのコマンドはgit remote add リモート名 リモートURLです。
「リモートリポジトリを追加するよ! その名前はリモート名で URLは リモートURLだよ! 」ってことですね。
実際のコマンドはこうなります。

$ git remote add origin git@github.com:(githubユーザー名)/(Repository name).git
(originについては後述)

補足:(Repository name) はここ↓で指定したものです

スクリーンショット 2020-06-24 19.25.08.png


リモート名? なんでoriginにするの?と思いますよねー
リモート名とは、リモートURLのリポジトリの別名です。上記のRepository nameとは違うので注意してください。
これをoriginにするのがGithubのデフォルトなのです。そうしておくと、様々なコマンドでリモート名を省略することができます。
大人しくoriginにしておきましょう

さて、コマンドを改めて載せておきます。(さっきと同じコマンドです)

$ git remote add origin git@github.com:(githubユーザー名)/(Repository name).git

ターミナルで実行してください。
何も表示されず、何も起こっていないように見えます。

git remote -vを実行してみましょう。
これは、ローカルリポジトリに紐づいているリモートリポジトリのURLを表示するコマンドです。

$ git remote -v

origin  git@github.com:(githubユーザー名)/(Repository name).git (fetch)
origin  git@github.com:(githubユーザー名)/(Repository name).git (push)

このように表示されればリモートリポジトリが紐づいています。

リモートリポジトリにローカルリポジトリの内容を反映する

ようやくここまできました。長かった…
今の状況を整理するとこうです。

  • リモートリポジトリ
    • 作成したが、
  • ローカルリポジトリ
    • 作成済み
    • ファイルがある
    • コミットしたファイルもある
    • リモートリポジトリと紐づいている

ローカルリポジトリでコミット(セーブ)したファイルを、リモートリポジトリに反映してあげましょう。
そのコマンドは git push -u origin head !!!!!!!!!

$ git push -u origin head

To github.com:(ユーザー名)/(Repository name).git
 * [new branch]      head -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

「コミットした変更をリモートリポジトリにpush(反映)するよ!
宛先はリモート名がoriginのリモートリポジトリね!
pushするのはhead、つまり最新のコミットまでを頼むね!」

git push -u origin master でも「今は」同じ結果になります。ブランチを理解してから使い分けましょう。)
headについては別の記事で詳しく解説します。今は丸暗記でOKです。)
-uオプションをつける意味については、この記事などを参照ください。このことを今は理解できなくていいです。)

これでリモートリポジトリに反映されました!!!
確認してみましょう。

Githubの右上にある自分のアイコンをクリックし、your repositoriesを選択してください。
スクリーンショット 2020-06-24 23.41.06.png

そして、先ほど作成したリモートリポジトリを開いてみると…
スクリーンショット 2020-06-24 23.43.31.png
ファイルが追加されているはずです!
(僕は test と test2 というファイルをpushしました)

これでローカルリポジトリの変更をリモートリポジトリに反映する、つまり同期することができるようになりました!!!

これでようやくGit/Githubを使うスタートラインです。
この記事での説明はこれでおしまい。(長いし…)

次の記事では、逆にリモートブランチの内容をローカルリポジトリに反映する方法ブランチについて書こうと考えています。

まとめましょう

これまでに学んだことをざっくりと。

Gitを始めてからリモートリポジトリに同期させるまでの流れ

こんな感じ。

  1. コードが格納されているフォルダを用意する
  2. git init でローカルリポジトリを作る
  3. git add でコミットするファイルを指定する
  4. git commit でコミット(セーブ)
  5. Github上にリモートリポジトリを作る
  6. git remote add でローカルリポジトリとリモートリポジトリを紐づける
  7. git push -u origin head でローカルリポジトリでコミットしたものをリモートリポジトリに反映して同期

用語とコマンド

  • Git
    • バージョン管理をするためのツール
  • Github
    • Gitをオンラインで共有するためのツール
  • リポジトリ
    • Gitで管理されているフォルダ
  • リモートリポジトリ
    • オンライン(Githubとか)にあるリポジトリ
  • ローカルリポジトリ
    • 個人のPCにあるリポジトリ
  • git init
    • 自分のPCにある(ローカル)フォルダをGit管理するためのコマンド
    • このコマンドによりフォルダがリポジトリとなる
    • .gitが生成される
  • git add
    • コミット(git commit)するものを選択するコマンド
    • git addすることを「ステージング」と呼ぶ
    • git add .で全ての変更を選択できる
  • git status
    • 何をステージングしたかを確認できるコマンド
    • 確認なので、このコマンドを実行しなくても可
  • git commit
    • git addした変更をセーブするコマンド
    • gitの主役
    • コミット単位で過去の状態に戻ったりできる
  • git remote add
    • ローカルリポジトリとリモートリポジトリを紐づけるコマンド
    • ローカルリポジトリにリモートリポジトリのURLを登録する
    • このコマンドを実行してからGithubと連携ができるようになる
  • git push
    • ローカルリポジトリでコミットした変更をリモートリポジトリに反映するコマンド
    • このコマンドによりローカルとリモートが同期できる

さいごに

いろんな説明記事を見て、それらをなぞればpushまでたどり着くことは簡単にできます。
しかし実行している内容を細かく体系立てて説明していた記事は見当たりませんでした。
僕は実際にGit/Githubを使っているとき「いつも打っているこのコマンドは何をしているんだろう?」という疑問がよく出てきました。
この記事では自分が辿ってきた疑問を全て潰してきたつもりです。
これからGitを触る人・Gitを使ってるが実はよく分かっていない人にとって参考になれば幸いです。

例によりこの記事は初心者向けなので、厳密には違う説明の箇所もあります。
しかし初心者としてはこの理解で十分です。疑問に思う時が来たその時は、自分で調べてより正確に理解してみましょう。

あれ?ブランチの説明はないの? と思った方もいるかと思います。
ブランチを理解するには、まずこの記事の内容の理解が必要と感じているので、前段階としてこれを説明しました。
次の記事ではブランチも説明していくつもりです!!!!!

そもそもなんでGitを使うの?バージョン管理をするの?って人は、まさにこの記事を参照下さい。
なぜ僕らはGitでバージョン管理をするのか

よかったらTwitterもフォローしてね。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindowsのGit Bashでadd/commit/pushを自動化するコマンドを作る

要約

  • ローカルでないフォルダでGit Bashを使うと死ぬほど遅い。
  • C\Program Filesの下にGit Bashで使う.bashrcがある。
  • そこにadd/commit/pushを自動化するgishコマンドを作った。

Git Bashの.bashrc上で新たに関数を作る。

.bashrcの場所

起動時に実行される.bashrcはMacやLinuxであれば大体home直下がデフォルトですが,
Windows10では C:\Program Files\Git\etc\bash.bashrcというところに存在します。

作成したgishコマンド

ここの記述を参考に作りました。

  • 引数はgish "コミットメッセージ" [何らかの文字]です。
  • 引数が1つならエラーを返し,2つならコミットメッセージでcommit,3つあればpushまで行います。
# gish "コミットメッセージ" "何某かの文を入れるとPush"
gish(){
git add -A;

#引数の数に応じて分岐
if [ $# = 0 ]; then # Error
echo "Please add comment!"
elif [ $# = 1 ]; then # Commitだけ
msg=$1
git commit -m "$msg";
elif [ $# = 2 ]; then # Pushもする
msg=$1
git commit -m "$msg";
CULLENT_BRANCH=`git rev-parse --abbrev-ref HEAD`;
git push origin ${CULLENT_BRANCH};
fi
}

なお,Programfilesの中なので管理者権限が必要です。Gitのbashrcを書き換えるのはなんとなく気持ち悪いですが,別途Homeにbashrcを作ってProgramFiles側から実行させる。という手法もあることはあります。

結局どれがいいのか?

わかりません。教えて下さい…

この手の効率化はエイリアスやシェルや関数化など皆さんいろいろやってくれていますが,Git Bashでbashrcを書き換えている人はパット見いなかった&自分で使って悪い気はしなかったので投稿しました。

他にも
- zshで実装した方

などの記事を眺めたりしました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindowsのGit Bashでadd/commit/pushを自動化するコマンドを作った

要約

  • ローカルでないフォルダでGit Bashを使うと死ぬほど遅い。
  • C\Program Filesの下にGit Bashで使う.bashrcがある。
  • そこにadd/commit/pushを自動化するgishコマンドを作った。

Git Bashの.bashrc上で新たに関数を作る。

.bashrcの場所

起動時に実行される.bashrcはMacやLinuxであれば大体home直下がデフォルトですが,
Windows10では C:\Program Files\Git\etc\bash.bashrcというところに存在します。

作成したgishコマンド

ここの記述を参考に作りました。

  • 引数はgish "コミットメッセージ" [何らかの文字]です。
  • 引数が1つならエラーを返し,2つならコミットメッセージでcommit,3つあればpushまで行います。
# gish "コミットメッセージ" "何某かの文を入れるとPush"
gish(){
git add -A;

#引数の数に応じて分岐
if [ $# = 1 ]; then # Error
echo "Please add comment!"
elif [ $# = 2 ]; then # Commitだけ
msg=$1
git commit -m "$msg";
elif [ $# = 3 ]; then # Pushもする
msg=$1
git commit -m "$msg";
CULLENT_BRANCH=`git rev-parse --abbrev-ref HEAD`;
git push origin ${CULLENT_BRANCH};
fi
}

なお,Programfilesの中なので管理者権限が必要です。Gitのbashrcを書き換えるのはなんとなく気持ち悪いですが,別途Homeにbashrcを作ってProgramFiles側から実行させる。という手法もあることはあります。

結局どれがいいのか?

わかりません。教えて下さい…

この手の効率化はエイリアスやシェルや関数化など皆さんいろいろやってくれていますが,Git Bashでbashrcを書き換えている人はパット見いなかった&自分で使って悪い気はしなかったので投稿しました。

他にも
- zshで実装した方

などの記事を眺めたりしました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む