今さら聞けないGit 2020年06月17日

今さら聞けないGit 2020年06月17日
目次

git hooksのpre-commitでmasterにそもそもコミットさせないようにする

# 課題
うっかりmasterにコミットしてしまう事故がよく発生するので、そもそもpre-commitでコミットする前の段階でエラーで弾くようにした。

# 前提
mac OS 10.15.4
windows10

# 準備
git/hooks配下に「pre-commit」ファイルを用意する

## コード
`git symbolic-ref HEAD –short`で現在のブランチ名を取得
masterと文字列比較をすることで、自分が今masterブランチ以外のブランチにいるということを確認している

“`sh

#!/bin/sh
branch=`git symbolic-ref HEAD –short`
if [ ${branch} = master ]; then
cat <<\EOF エラー:masterブランチにcommitはできません。 EOF exit 1 fi ``` # 参考 [pre-commit hookでmasterへのcommitを禁止した](https://blog.n-z.jp/blog/2014-02-07-pre-commit-

元記事を表示

【Git】リモートにプッシュしていないコミットの一覧を取得する。

メモとして残します。

#■やり方
###1.確認したいブランチに移動
“`shell
git checkout ブランチ名
“`

###2.未コミットを確認。
“`shell
git log origin/リモートブランチ名..HEAD
“`
上述のリモートブランチ名は基本的には追跡ブランチになるはず。

元記事を表示

【github】Files changedにNo changesファイルが存在する時の対処法

## はじめに
プルリクエスト中のmasterブランチとの差分ファイルはFiles changedに表示されます。
このFiles changedにNo changesファイルが存在する際の対処法を書きたいと思います。
(差分がないのに差分ファイルに含まれる→けど差分ないよ!といわれることです)

## なぜ起こったのか?
原因:ローカルとサーバー両方でpushしてしまったから

コードをphpstormで同期していた私はローカル(Mac)、サーバーどちらでpushしても同じものだと思っていました。
なのでbranch1をローカルでpush→masterにマージし、その後にbranch2をサーバーでpushしプルリクエストを出したところ
Files changedタブにNo changesファイルが9つ表示されました。。。

## 対処法
#### 対処法1
masterブランチをpullしてみる
##### 結果
変わらず。。

#### 対処法2
カレントブランチのNo changesファイルを削除しmasterブランチのファイルを落としてくる
##### 結果
File chan

元記事を表示

Githubに変更のpush方法(後編)

前回はローカルリポジトリへの、変更のpushの仕方を紹介しました。
今回はGitのローカルリポジトリから、GitHub(いわゆるリモートリポジトリ)へのpush方法を軽く説明していきます:v:
とは言っても簡単なので、気楽にいきましょう!

#GitのローカルリポジトリからGitHubへのpush
![git.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/645930/18b68ade-da7f-c35f-a995-fd7fdd9f69d7.png)
GitHubの画面の右上に十字のマークがあります。そこから**New repository**をクリックします。
Create a new repositoryという画面が出るので、プロジェクト名を記入してください。ここは特に決まりはないので自由に書いて大丈夫です。Descriptionはrepositoryの説明なので、任意になります。最後に**public**か**private**を選択しましょう。

・public
 誰でもrepositoryを

元記事を表示

競技プログラミングしかわからないけど、業務プログラミングがやりたい。 1問目 ~バージョン管理システム~

# はじめに
私は某IT企業で働く3年目の社員で、エンジニアの端くれをやっている者です。
趣味で競技プログラミングを2年ほどやっており、[AtCoder](https://atcoder.jp/)での記事投稿時点(2020年6月16日)でのレートは1422です。早く青色になりたい。

競技プログラミングをする中で、業務プログラミング(仕事で使うプログラミングぐらいの意味)とは違うということをよくTwitterで耳にするようになりました。
私も仕事でプログラミングをちょこっとしますが、確かに求められるスキルには差があるように感じます。設計,CI/CD,コーディングのお作法等々・・・

本記事シリーズはほとんど競技プログラミングしか知らない私が、業務で必要そうなスキルを身につけていく過程を記録したものです。

なぜそれが業務では便利なのかと言う点についてはよく考えたいと思います。

ただし、**私自身がソフトウェアエンジニアではない**点はご了承ください。(仕事内容はベンダーが構築したシステムの維持管理です。社内SEですね。)

この記事では、「バージョン管理システム」について取り上げ、そ

元記事を表示

Gitのコンフリクト(conflict)の解消方法について

# コンフリクトの基本

コンフリクト時のファイルの見方

“`shell
<<<<<<< HEAD This is an apple. # mergeする側の変更(masterブランチの編集) ======= This is an orange. # mergeされる側の変更(testブランチの編集) >>>>>>> test
“`

# Rebase時のConflictの解消方法

操作コマンド

“`shell
$ git checkout master

$ git rebase -i 2a87bbe

$ vim {file_name}

<<<<<<< HEAD This is an apple. # masterブランチの編集 ======= This is an orange. # testブランチの編集 >>>>>>> test

$ git add {file_name} # conflictを解消したファイルの名前をgitに教えてあげる

$ git rebase –continue # これ以上conf

元記事を表示

Gitのリベース操作について

# リベースの基本操作について

### リベース(rebase)でできること

操作イメージ

“`
(Before)
A—B—C test
/
D—E—F—G master

(After)
A’–B’–C’ test
/
D—E—F—G master
“`

操作コマンド

“`shell
# 現在のブランチの確認
git branch –contains

# ブランチの切替
git checkout test

# リベースの実行
git rebase master
“`

▼実行前

“`shell
* bbac238 – add sample4.txt (HEAD -> test) (6 minutes ago:2020-06-16 14:17:47 +0900)
* 770ae3b – add sample3.txt (7 minutes ago:2020-06-16 14:16:39

元記事を表示

Gitのマージ・マージオプションについて

# Gitのマージ

基本的なマージの操作方法

“`shell
# 対象ブランチに切り替える
git checkout {branch_name}

# マージする
git merge {new_branch}
“`

▼マージ前

“`shell
* bbac238 – add sample4.txt (HEAD -> test) (3 seconds ago:2020-06-16 14:17:47 +0900)
* 770ae3b – add sample3.txt (71 seconds ago:2020-06-16 14:16:39 +0900)
| * f3bf129 – add sample2.txt (master) (34 seconds ago:2020-06-16 14:17:16 +0900)
| * 1241db9 – add sample1.txt (2 minutes ago:2020-06-16 14:15:51 +0900)
|/
* 5f09f67 – initial comm

元記事を表示

Gitのブランチの操作について

# ブランチの基本操作について

“`shell
# ブランチの一覧を見る
git branch -a

# 新規ブランチを作成&切替
git checkout -b {new_branch}

# 新規ブランチを作成&切替(origin/masterを元に)
git checkout -b {new_branch} {origin/master}

# ただの新規ブランチ作成
git branch {new_branch}

# ブランチの切換え
git checkout {new_branch}

# 現在のブランチ確認
git branch –contains

# 特定地点のコミットのブランチを作成する
git checkout {HEAD}
“`

# ブランチの削除について

“`shell
### ローカルブランチの削除
# HEADにマージしたブランチを削除する
git branch –delete {branch_name}

# マージしたかどうかに関わらず削除する
git branch -D {branch_name}

### リモートブランチの削除

元記事を表示

チーム開発で使ったgitコマンドまとめ

# チーム開発する上で使ったコマンドたち
## github上の本家リポジトリたちと連携するときの設定
作業前のセットアップについて
1. 本家リポジトリに共同編集者を登録してもらう
2. ~~本家リポジトリをフォークする~~
3. remoteで本家リポジトリと~~フォークリポジトリ~~をローカルと連携する
4. リポジトリが連携できているかチェックしてみる
## ローカルで作業するときの色々
作業するときに使ったコマンドたち
慣れるまでが大変なのでそこを頑張ってやる

## github上のリポジトリと共有する
リーダが作っているプロジェクトをローカルに持ってくる。
ターミナル上で自分のワークスペースに移動したら、

“`
git clone https://github.com/ユーザー名/リボジトリ名
“`
cloneコマンドを使うことでリポジトリを丸々ダウンロードすることができる。
そして、後でpushを利用してアップデートなどもできるようにこのURLをアップロード先に指定できるように
remoteコマンドを使う。

“`
git rem

元記事を表示

Ubuntu20.04導入から環境構築まで

# はじめに
今回研究室でのwindowsマシンが処理が重たく使い勝手が悪いと感じたため、Ubuntuマシンへと変えてしまっても良いのではないか?ということでこれからUbuntuマシンへクリーンインストールする方に参考になればと思う.
**Qiitaに初めての投稿となるので温かい目でみていただければと思う.**
**デュアルブートする人は対象ではないのでご注意を!!**

## Ubuntuのインストール
– [Ubuntu Desktop 20.04 LTS](https://jp.ubuntu.com/download)からイメージファイルをダウンロード
インストールメディアを作成する際,**8GB以上のUSBメモリ**を使用する.

– 作成したメディアを改造したいPCに差し込みBIOSを起動.
BOOTメニューから先ほどのインストールメディアから起動する.

– Ubuntuが起動しセットアップを行う.
言語は**English**で進める,
*CUIで動かすときにエラーメッセージが文字化けして読めないため英語版で進めることを推奨する.

## プロキシの設定が必要な方(ネッ

元記事を表示

現場でよく使う Git コマンド集

#現場でコピペシリーズ Git版リリースです。

###リモート設定
“`
git remote -v        # リモート確認
git remote add origin    # リモート名追加
git remote rm <リモート名>  # リモートの削除
git remote set-url # リモート設定
git fetch origin ブランチ名 # リモート最新情報でローカルorigin/master更新
“`
###Clone & Pull
“`
git clone <リモートリポジトリURL> <クローン先のディレクトリ>
git pull <<リモート名>> <リモートブランチ>
“`
###ブランチ
“`
got branch -a # 全てのブランチ閲覧
git checkout <切替えるブランチ>   # ブランチ切替
git checkout -b <作成ブランチ名> # ブランチ作成
git checkout -b <作成ブランチ名> <リモートブランチ> # リモートブラン

元記事を表示

Gitの基本操作(リポジトリの作成方法、コミット&プッシュ、フェッチ&マージ)

# Gitのリモートリポジトリの作り方

### ローカルリポジトリ→リモートリポジトリ

“`shell
# フォルダ作成&初期化
mkdir {project_name}
git init

# GitHUB上でリモートリポジトリを作成する

# GitHUB上のリモートリポジトリを追加
git remote add origin {URL}

# URLを確認
git remote -v

# push
git push -u origin/master
“`

### リモートリポジトリ→ローカルリポジトリ

“`shell

# フォルダを作成してリモートのブランチを複製する方法
git clone {URL}

# リモートリポジトリの追加
git remote add origin {URL}

# URLを確認
git remote -v
“`

### ローカルリポジトリの削除

“`shell
# 削除実行
# 強制削除のため実行する際は十分注意する
rm -rf {git_folder_name}
“`

# コミット&プッシュ

“`shell
#

元記事を表示

Gitの初期設定・ちょっと便利な設定

# 環境変数の設定

環境変数の設定場所は3箇所存在する
以下コマンドで確認できる

“`shell
# Gitの全ての設定を確認する
git config –list

# システム全体
git config –system –list

# HOMEディレクトリ配下の.gitconfig cd ~/.gitconfig
git config –global –list

# ローカルリポジトリ内の.git/config
git config –local –list

“`

最低限必要な初期設定は以下の通り。

“`shell
git config –global user.name {username}
git config –global user.email {emailaddress}
git config –global –list
“`

# ちょっと便利な設定(Tab補完機能など)

Linuxシェル上での設定。

“`shell
sudo mkdir -v /usr/local/etc/bash_completion.d

su

元記事を表示

自分がよく使うGitHub, GitLabを使うときの開発の流れ(フロー)

# ⚠️このドキュメントっぽいものについて

+ もともとは弊社の社員向けにGitを用いた開発フローを説明するためのドキュメントの目的で作られています
+ このドキュメントで解説するフローはGitHubFlowなどから一部変更をしています
+ これが必ずしも正解であるとは限りません
+ GitHub(GitLab)が有効活用できればそれでOK このドキュメントはその一例として見てください
+ Qiitaかどこかでこのフローの元の記事を見た覚えがありますが見つかりませんでした。もしご存じの方がいらしたらリンク付をしようと考えているのでコメントで教えて頂けると幸いです
+ 既に固定のフローをお持ちの方々はそのフローで大丈夫だと思います

# ?tl;dr

1. 消化しないといけないタスク(バグ、新規実装項目)をIssueに網羅する。実装における質問や議論などもIssueに立てて書くと良き
2. 実際にコードを書く際は専用のbranchを切る。branch名は必ず`Add_DogeIcon#12`のような形にする。(Issueのだいたいの英訳+Issue番号)
3. 実装が終了したらpus

元記事を表示

空白と権限だけが変更されているファイル、新規追加されたファイルだけaddしたい

Gitを使ってくれない / 使えない環境と協業する際に、修正した差分だけじゃなくドカッとファイルを渡されたは良いけど、OSも違って全部diffに上がってくるコトがあったので、何度もファイル参照するのが大変なのでメモ。

## 空白と権限だけが変更されているファイルだけをaddする

結論からすると、下記コマンドで対応しました。

“`bash
$ git diff -w –ignore-blank-lines -G”.” –name-only | xargs git add
“`

### 空白だけが変更されているファイルを除く

まずは空白が変更されているファイルを除くコマンドは、通常のオプションで用意されています。

“`bash
$ git diff -w
“`

何故かこれでもほぼ全てのファイルがdiffに上がってくるので何故だろうと思っていたら、権限も変わっていたのが原因でした。

### 権限だけが変わっているファイルを除く

よくある情報はconfigを変更する下記のコマンドを実行すると権限のチェックはされないようになります。

“`
$ git confi

元記事を表示

初めてのGit〜SourceTreeでリモートからデータを持ってきてコミットする

##はじめに
現場がSVNからGitに移行して自分が初めてGitに触る際、概念やCUIでのgitについての記事が多く、ひとまず今すぐGUIでデータを持ってきてコミットする手順が知りたいなと思ったので、自分が困ったことも含めてメモしておきたいと思います。
すでにソースがGit上にある前提で進みます。

##1.インストール
####Gitのインストール
インストールされていない場合インストールする
[windowsはこちら](https://gitforwindows.org/)
[macはこちら](https://gitforwindows.org/)
####SourceTreeのインストール
SourceTreeはGitをGUIで管理できるソフトです。
以下のサイトからSourcetreeをダウンロード
https://www.atlassian.com/ja/software/sourcetree
アカウントを登録する必要があります

##2.リモートからローカルにデータをコピーする=クローン
SVNでいうチェックアウト
(1)プロジェクトのgitのURLを貰い、新規よりURLか

元記事を表示

Git でリモートブランチへの切り替えはもっと簡単にできる

まず結論から。次のようにして変更できます。(foo はリモートブランチ名です)

“`bash
git fetch
git checkout foo
“`

fetch できていたら 2行目だけでOK

“`
Branch ‘foo’ set up to track remote branch ‘foo’ from ‘origin’.
Switched to a new branch ‘foo’
“`

と、親切に動作してくれます。

こちらのツイートで知りました。ありがとうございます。

元記事を表示

なぜ僕らはGitでバージョン管理をするのか

プログラミングを初めて3ヶ月くらいしたとき、**Git**ってものがあると知りました。
**バージョン管理**をしてくれるシステムなんだってさ。
ファイル名に「test_20200615.php」なーんて書かなくて済むらしい。

便利らしいね、これ。

でも別にGit使わなくても個人開発出来てるし?
コード書いたらファイルを上書きしても困ってないし?

**バージョン管理できるのはわかった**よ。それで**どんないいことがあるの?**

…という、過去の自分の疑問がありました。
今ではITエンジニアとなりGitなしでは生きていけなくなった自分自身が全力で答えていきます。

## バージョン管理のメリット

なぜ僕らはGitを使うのか?
なぜバージョン管理をするのか?
ものすごくざっくりですが、以下2つの大きなところを抑えておけばOKです。

– **以前の状態に戻れる**
– **他人がコードの意図を理解しやすくなる**

例とともに説明していきます。

## 以前の状態に戻れる
あなたはあるシステムを開発して世に出しています。
そして新機能をリリースするためにコードを編集しています。

元記事を表示

git addすらせずにファイルを消してしまったときにPhpStormで復元する方法

## ファイルを消してしまったときの絶望感

READMEファイルをせっせと書きつつ開発していたときのこと、READMEファイルは `git add` せずに他のファイルのコミットを積み上げていました。

あるファイルの変更がいらないなっと思ったので `git reset –hard` で最新のコミットに戻しました。

するとどうでしょう。READMEファイルもどこかへ消えてしまいました。

## Gitはファイルを復元できる

こういった間違えのときのためにGitは存在をしていますが、Gitが復元できるのはGit管理下にあるもののみです。

`add` や `commit` を一度でもしておけば完全でなくても元に戻すことは可能です。

しかし、それらを一度もしていないファイルはGitでもどうしようもない(はず)のです。

## PhpStorm is GOD

そのときに使用していたエディタはPhpStormで、このPhpStormにはLocal HistoryというGitとは別に管理してくれているものがあります。

`VCS > Local History > Show Hist

元記事を表示

OTHERカテゴリの最新記事