20200806のGitに関する記事は12件です。

git commitしたらmarkdownがHTML化する

git commitしたらmarkdownがHTML化する

Blogger用にHTMLソースがほしいのだ

2つブログが持っている。qiitabloggerだ。

qiitaはmarkdownをそのまま使える。だが、bloggerでmarkdownは使えない。

bloggerで使えるのは、HTMLだ。

もちろん編集しやすいのは、当然markdownだ。なので、できれば、markdownだけ作りHTMLを生成したい。

結論:git commitしたらHTML化できるようにする

そこで「git commitしたら勝手にmdファイルがhtmlになったら楽だろう」と考えた。

いろいろな方法があるだろうが、とりあえず以下のスキームを作った。

Image from Gyazo

1.markedを導入

markdownをHTML化する方法はいくらかある。自分が使用したのは、marked.jsだ。

コマンドラインで使いやすいことで採用した。marked.jsをクライアント上で使用できるようにするには、Node.jsを導入している環境で、以下のコマンドを入れる。

npm install -g marked

あとは、以下のコマンドで使えるようになる。

$ marked -o hello.html
hello world
^D
$ cat hello.html
<p>hello world</p>

詳しくは、marked.jsを参照してほしい。

2.Gitフックを利用するためpre-commit作成

GitにはGitコマンドを実行した契機でスクリプトを起動するためのgit hookという仕組みがある。

参考:Git フックの基本的な使い方 - Qiita

ここでは、pre-commitを編集する。

まず「.git/hooks」フォルダ内の「pre-commit」ファイルを編集する。

以下のようなスクリプトを作成した。ちなみにshellで作成している。

#!/bin/sh
# pre-commit
# Convert to HTML File From MD File.
# Date: 2019-05-05
# Author: Neko619<yasagureneko.trpg@gmail.com>

# MEMO:最初は必ず.gitと同じディレクトリになる
# pwd

# チェックする
# 出力先存在チェック
if [ ! -d html ]; then
  echo "create html directory!"
  exit 1;
fi

# 一文字目がMかAならばhtml化する対象とする
# 二文字目は入れているけど意味はない…
# mdフォルダ配下のmdファイルである場合を対象に
# for文でmarkedにかけてhtml化する
for var in `git status -s | awk '
  BEGIN{chr1="";chr2="";filename=""}
  /^[AM].+md\/.+\.md$/{
    chr1 = substr($0, 1, 1);
    chr2 = substr($0, 2, 1);
    filename = substr($0, 4);
    print filename;
  }
'`
do
  # 入力ファイル名
  inputfile=$var
  # 出力ファイル名
  # html配下にし、拡張子をhtmlにする
  outputfile=`echo $var | sed -e "s/\.md$/.html/"`
  outputfile=`basename $outputfile`
  outputfile=`echo html/$outputfile`
  # markedでhtmlを出力する
  marked.cmd -i $inputfile -o $outputfile
  # htmlとして整形する
  # markedは、innerHTMLで入れることを想定しているので、
  # HTMLタグなどは生成できないことから、自前で入れる。
  sed -i '1i<!DOCTYPE html>\n<html><haed>\n<title>'$var'</title>\n</head>\n<body>' $outputfile
  echo "</body>" >> $outputfile
  echo "</html>" >> $outputfile
  # 結果を出力する
  echo "marked $inputfile to $outputfile"
done

exit 0

HTMLとしては粗末なものだが、Bloggerにはソースをコピペするだけなので、最低限で十分である。

これで準備ができた。

3.markdownで作成してgit commitしHTMLを生成する

まずはとりあえず、markdownでファイルを作成する。

このとき、フォルダ構成を以下の構成として、mdフォルダ内にmdファイルを作成する。そして、mdフォルダ内にmdファイルを作成する。

ここでは、sample.mdとする。

+ .git
+ html
+ md
  + sample.md

では、例えば以下のようなmdファイルを作成したとする。

# サンプル

## サンプルだよ

- Markdownを作るとー?
- HTMLができちゃうー?

その後、git commitする。一応以下の基本的なコマンドとなる。
が、自分はVSCodeで作成しているので、VSCode上からcommitしてしまっているし、それで問題ない。

git add .
git commit -m "サンプル"

すると、htmlフォルダ上にhtmlファイルが生成される。ファイル名は、拡張子を.mdから.htmlに変わったものになる。

<!DOCTYPE html>
<html><haed>
<title>md/sample.md</title>
</head>
<body>
<h1 id="サンプル">サンプル</h1>
<h2 id="サンプルだよ">サンプルだよ</h2>
<ul>
<li>Markdownを作るとー?</li>
<li>HTMLができちゃうー?</li>
</ul>
</body>
</html>

これでbodyの内部をbloggerにコピペすれば良い。

厳密には、h1の場所はタイトル欄にもっていったり…と若干手間をかけているが、いちから作成するよりかは遥かに楽になった。

補足

ちなみに、さらにgit commitしても、ちゃんとhtmlファイルを上書きしてくれる。

なお、流石に面倒なのでHTMLフォルダ内は.gitignoreに指定してgitの管理から外している。過去のHTMLを作ろうと思えば、markdownファイルをgitで戻してそこから作れるからね。

ブログ更新もっとしよ

そういう仕組を作ったのに、ブログ更新してないのがよろしくない!

書け! 書くんだ! ねこ!

bloggerでは、適当な事も書いてます。自由に書きたいのです。

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

よいコミットメッセージの書き方(翻訳+要約)

はじめに

Chris Beamsさんの記事を読んで勉強したことをまとめたものです。
備忘録的に覚えておきたいことだけ掻い摘んでいるので、興味が湧いた方はぜひ原文をご覧ください。

Gitのコミットメッセージの書き方

以下、本文です。

よいコミットメッセージを書く理由

他人や未来の自分が、なぜこのコミットをしたのかを理解できるようにするためです。git diffでは差分を表示できますが、その理由はコミットメッセージしか教えてくれません。

それではどのようなコミットメッセージが推奨されるのか、一例を示します。

  • わるいコミットメッセージ
$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"

e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing
  • よいコミットメッセージ
$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"

5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage

前者は冗長でフォーマットが不定であり読みづらいですが、一方で後者は簡潔かつ一貫していて読みやすいです。差は明らかですが、意識せず自然に書いていると、どうしても前者のようになってしまいます。

それでは、どのようにすれば後者のようなコミットメッセージを書けるようになるのでしょうか。よいコミットメッセージには七つの法則があります。順番に説明しましょう。

よいコミットメッセージのための七つの法則

1.タイトルと本文を空行で区切ろう

まず、コミットをタイトルだけで済ませるか、本文も加えるか、という点を意識しましょう。誤字の修正などgit diffをすれば修正箇所や理由が明らかな場合は、以下のようにタイトルだけで構いません。

$ git commit -m "Fix typo in introduction to user guide"

しかし少しでも説明が必要となる場合は、コミット時に-mオプションを使わず、本文を加えましょう。本文の例を示します。

Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

さて、タイトルと本文を空行で区切る理由についてですが、単なる可読性の向上に留まりません。

Gitにはgit log --onelinegit shortlogといった、タイトルだけを表示してくれる便利な機能がありますが、これらは空行でタイトルと本文を判別します。そのため空行を入れておかないと本文もタイトルとして扱われ、せっかくの--onelineオプションの意味がなくなってしまいます。

「わるいコミットメッセージ」のe5f4b49の例(一行目)がそのケースだと思われます。コミットメッセージが複数文から構成されてやたらと長いですが、その原因はタイトルと本文の間に空行がなかったためでしょう。

2.タイトルを50文字以内にしよう

長すぎないタイトルだと、git log --onelineしたときに読みやすいですね。何文字までが長すぎないのかは人によるかもしれませんが、Githubでは以下の仕様となっています。

  • 50文字を超える場合:警告が表示される
  • 72文字を超える場合:72文字に切り捨てられる

よって、できれば50文字、少なくとも72文字に収めましょう。

3.タイトルの先頭は大文字にしよう

単純ですが、大文字・小文字の使い分けに気をつけましょう。

4.タイトルの末尾にピリオドはやめよう

ピリオドを省略することで、一文字分タイトルに余裕ができます。タイトルを50文字以内に収めるためにも、不要なピリオドは省略しましょう。

5.タイトルには命令形を使おう

命令形はコマンドや指示を表すのに優れています。強い言葉に聞こえるので、遠慮する気持ちもあるかと思いますが、Git自体が「mergeしろ」「revertしろ」など命令形で語りかけてくるので、Gitのコミットメッセージで使用する分には問題ないでしょう。

また、活用形の揺れを抑えるためにも命令形(原形)は有効です。過去形や過去分詞形を使わず、命令形から始まるように書きましょう。より正確に言うならば、よいタイトルは以下のwillに続く文であるべきです。

  • If applied, this commit will ...

たとえばRefactor subsystem X for readabilityというタイトルは、If applied, this commit will refactor subsystem X for readability.という文から導けます。このように命令形で始めることは、willのあとに続く原形から始めるという側面も持っています。

もちろん、本文においては命令形に固執することはありません。

6.本文では1行72文字以内に収めよう

git logをしたとき、長過ぎる文字を適度な場所で折り返してくれるかどうかは、環境に依存します。そのため、インデントの余裕を残して本文を72文字に収めましょう。

7.本文には方法よりも目的を書こう

まずはコミットの目的を明らかにしましょう。そして以下の3点を意識することが大切です。

  • 変更前の動作
  • 変更後の動作
  • なぜその方法で解決しようとしたのか

方法はコードを見れば自明ですし、必要があればソースにコメントを書くことで補足しましょう。コミットメッセージにおいては、HowよりもWhatやWhyが大切です。

おわりに

本文は以上で終わりです。ここからは私的なことです。

自分ができていなかったことを振り返ってみます。

まず、コミットで本文を省略することが多かったですね。PRで説明すればいいかと思っていましたが、後からいちいちGithub開いて閉じたPRを探すのは大変な気もします。もちろんPRの方が情報量は多いですが、git logだけで解決できる選択肢を残しておくほうが親切ですね。反省です。

それから、willに続くようなタイトルを書けていませんでした。命令形を使ってた理由というのがなんとな〜くで、たまに過去分詞とか使っていました。fixedとか。あとは大文字にするのも割と忘れていた気がします。

なぜそういう「わるいコミットメッセージ」を書いていたのかというと、体系的に覚える機会がなく、そもそも意識できていなかったからだと思います。なので、今回一通り勉強した内容を忘れなければ、コミットの品質が上がるのではないかと期待しています。

有意義な取り組みでした。

参考文献

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

オンライン学習6日目

windows10でgitを学ぶ。昨日はmacで。混乱しわからないことだらけ。

明日で1週間、独学しているのと変わらない気がする。

毎日積み重ねて、変化し続けたい。

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

【git rebase】過去のコミットから特定のファイルを除外したいとき

「コードレビューをしてもらう際に修正ファイルと同じコミットにビルドファイルが含まれていて、ビルドファイルはビルドファイル単体のコミットで管理したい。」という場合の解決方法です。

やりたいこと

1stコミットに含まれる、bulid.txtを1stコミットから外したい。

3rd コミット:
 toto.txt

2nd コミット:
 piyopiyo.txt

1st コミット:
 hogehoge.txt
 fugafuga.txt
 build.txt ← このファイルをコミットから外したい

現状を確認する

$ git log --graph --pretty="%h %s" --stat

* 0c2ad68 3rd コミット
|
|  toto.txt | 0
|  1 file changed, 0 insertions(+), 0 deletions(-)
* df807a1 2nd コミット
|
|  piyopiyo.txt | 0
|  1 file changed, 0 insertions(+), 0 deletions(-)
* 6d7e47e 1st コミット
|
|  build.txt    | 0
|  fugafuga.txt | 0
|  hogehoge.txt | 0
|  3 files changed, 0 insertions(+), 0 deletions(-)
* 912382d git diffを追記
|
|  index.html | 1 +
|  1 file changed, 1 insertion(+)

git rebaseを行う

除外したいファイル(build.txt)が含まれているコミットの一つ前のコミットIDを指定してgit rebaseを行います。

$ git rebase -i 912382d

エディタが起動するので、除外したいファイル(build.txt)が含まれているコミットを edit に変更して保存・終了します。

edit 6d7e47e 1st コミット
pick df807a1 2nd コミット
pick 0c2ad68 3rd コミット

# Rebase 912382d..0c2ad68 onto 912382d (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

git rm でファイルの削除

エディタで保存・終了したら、下記のようになり指定したコミットまで戻っていることが確認できます。

Stopped at 6d7e47e...  1st コミット
$ git rebase -i 912382d
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

$ git log 
commit 6d7e47e100e483887cc498086b86ebc2d52fedc0 (HEAD)
Author: PHPer-sugiyama
Date:   Thu Aug 6 19:55:03 2020 +0900

    1st コミット

commit 912382d749bd3e17a993b1939c8b7690ee4b6d4c (origin/master, origin/HEAD, master)
Author: PHPer-sugiyama
Date:   Sat Aug 10 18:48:14 2019 +0900

    git diffを追記

git rm コマンドで除外したいファイルを指定したあとに git commit --amend でコミットの修正をします。

$ git rm build.txt
$ git commit --amend

エディタが立ち上がるので、コメントを修正する場合は修正して保存・終了します。

1st コミット(build.txtファイルを除外)

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Thu Aug 6 19:55:03 2020 +0900
#
# interactive rebase in progress; onto 912382d
# Last command done (1 command done):
#    edit 6d7e47e 1st コミット
# Next commands to do (2 remaining commands):
#    pick df807a1 2nd コミット
#    pick 0c2ad68 3rd コミット
# You are currently splitting a commit while rebasing branch 'article' on '912382d'.
#
# Changes to be committed:
#       new file:   build.txt
#       new file:   fugafuga.txt
#       new file:   hogehoge.txt
#
# Changes not staged for commit:
#       deleted:    build.txt

git rebaseの継続

ファイルを除外することができたので、git rebase --continue でリベースを続行します。

$ git rebase --continue
uccessfully rebased and updated

$ git log --graph --pretty="%h %s" --stat

* 0c2ad68 3rd コミット
|
|  toto.txt | 0
|  1 file changed, 0 insertions(+), 0 deletions(-)
* df807a1 2nd コミット
|
|  piyopiyo.txt | 0
|  1 file changed, 0 insertions(+), 0 deletions(-)
* 6d7e47e 1st コミット(build.txtを除外)
|
|  fugafuga.txt | 0
|  hogehoge.txt | 0
|  3 files changed, 0 insertions(+), 0 deletions(-)
* 912382d git diffを追記
|
|  index.html | 1 +
|  1 file changed, 1 insertion(+)

これで無事に1stコミットからbuild.txtファイルを除外できたかと思います。

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

[Git] fatal: refusing to merge unrelated histiesを解決する話

TL;DR

git merge --allow-unrelated-histories origin/masterをする!

なにが起きたの?

  1. GitHub上でリポジトリを作り, READMEを作成した.
  2. ローカルでgit initしてリポジトリを作り, git remote add origin <GitHubのリポジトリ>でリモートリポジトリを指定.
  3. ローカルで作業を行い,コミットしプッシュを行おうとした.

プッシュを行おうとしたら, 下のようになった.

To https://github.com/<user>/<repo_name>.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/<user>/<repo_name>.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

プッシュできなかったので,言われた通りにプルgit pull origin masterを行なった.
すると, 下のようになった.

From https://github.com/<user>/<repo_name>
 * branch            master     -> FETCH_HEAD
fatal: refusing to merge unrelated histories

fatal: refusing to merge unrelated historiesと表示されプルできなかった.

解決策

git mergeコマンドに--allow-unrelated-historiesのオプションを使いして実行する.

git merge --allow-unrelated-histories origin/master

するとimage.png

のようにマージが行われ,無事にプッシュ作業が行うことができる!

どうしてこうなった?

通常のマージでは,共通の祖先から分岐したブランチ同士が結合される.しかし,今回の例では,Githubでのコミット,ローカルでのコミットはそれぞれ共通の祖先がない状態から行われてしまっている.このため,マージを行うことができなかった.

しかし--allow-unrelated-historiesオプションをつけると,共通の祖先を持っていないブランチ同士でもマージ作業を行うことができる.

所感

今回起きた問題は, リポジトリ作りたての一番はじめだけしか起こることがない珍しいケースだと思う.

(--orphan オプションをつけてブランチを作成すると,既存ブランチと完全に独立したブランチを作れるため,一応おこりえる?)

参考にしたサイト

https://blog.clock-up.jp/entry/2018/12/01/git-merge-allow-unrelated-histories

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

【Git】過去のコミットを起点にしてそこからブランチを作成する。

自分用のメモとして残します。

■やり方

1.ローカルにブランチ作成

git checkout コミットRev -b ブランチ名

2.リモートに作成したブランチを反映

git push -u origin 作成したブランチ名
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Git】特定のコミットに対してタグを設定する。

自分用のメモとして残します。

■やり方

1.タグを設定

git tag -a タグ名称 -m'コメント' コミットRev

2.リモートに反映する

git push origin タグ名称

■余談

タグって頻繁に設定するわけじゃないからド忘れしちゃいます(; ・`д・´)

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

googleアナリティクスを活用し、サイト分析を行う-1章

背景

現在デプロイしているサイトが自分以外のユーザに見ていただいているのか、経緯やアクセス数を調査したく、グーグルアナリティクスを導入ることにしました(ちょっと噛みそうになります…笑)
今まで、gitのトラフィックなどから、自分のポートフォリオサイトのアクセスを確認していたのですが、アナリティクスを使用していろいろと傾向を調査していきたいと考えています。

※この記事は、アナリティクスを設定してから、約1時間ほど経過しました。まだ分析結果が表示されないのですが、もう少し、待ってから状況を報告したいと思います(長ければ24時間かかるとのことです。)
表示結果や、手順の修正情報等々はおって掲載します。

環境

項目 内容
OS.Amazon Linux AMI release 2018.03
Ruby On Rails v5.2.4.3
MySQL v5.6

設定手順

作業時間:15分
(1)Googleアカウントの作成(割愛)
(2)Googleアナリティクスアカウントを作成
サイトに従って、主に以下を入力するだけです。
・アカウント名
・ウェブサイト名
・ウェブサイトのURL
・レポートのタイムゾーン

(3)トラッキングコードを設置
上記のアカウントを作成すると、トラッキングコードが配布されます。
これをサイトの各ページの<ヘッダ>タグに組み込みます。
私の場合、railsで稼働しているので、application.html.erbに設定しました。以下のようになります。

app/views/layouts/application.html.erb
<html>
  <head>
   ...

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx-1"></script>
    <script>
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());

        gtag('config', 'UA-xxxxxxxx-1');
    </script>

  </head>

  <body>
    <%= yield %>
  </body>
</html>

以上です。

参考

Googleアナリティクス導入時の設定・設置方法【初心者向け】
【今さら聞けない】Googleアナリティクスとは?導入手順から使い方まで5分で理解!

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

Googleアナリティクスを活用し、サイト分析を行う-1章

背景

現在デプロイしているサイトが自分以外のユーザに見ていただいているのか、経緯やアクセス数を調査したく、グーグルアナリティクスを導入することにしました(ちょっと噛みそうになります…笑)
今まで、gitのトラフィックなどから、自分のポートフォリオサイトのアクセスを確認していたのですが、アナリティクスを使用していろいろと傾向を調査していきたいと考えています。

※この記事は、アナリティクスを設定してから、約1時間ほど経過しました。まだ分析結果が表示されないのですが、もう少し、待ってから状況を報告したいと思います(長ければ24時間かかるとのことです。)
表示結果や、手順の修正情報等々はおって掲載します。

環境

項目 内容
OS.Amazon Linux AMI release 2018.03
Ruby On Rails v5.2.4.3
MySQL v5.6

設定手順

作業時間:15分
(1)Googleアカウントの作成(割愛)
(2)Googleアナリティクスアカウントを作成
サイトに従って、主に以下を入力するだけです。
・アカウント名
・ウェブサイト名
・ウェブサイトのURL
・レポートのタイムゾーン

(3)トラッキングコードを設置
上記のアカウントを作成すると、トラッキングコードが配布されます。
これをサイトの各ページの<ヘッダ>タグに組み込みます。
私の場合、railsで稼働しているので、application.html.erbに設定しました。以下のようになります。

app/views/layouts/application.html.erb
<html>
  <head>
   ...

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx-1"></script>
    <script>
        window.dataLayer = window.dataLayer || [];
        function gtag(){dataLayer.push(arguments);}
        gtag('js', new Date());

        gtag('config', 'UA-xxxxxxxx-1');
    </script>

  </head>

  <body>
    <%= yield %>
  </body>
</html>

以上です。

参考

Googleアナリティクス導入時の設定・設置方法【初心者向け】
【今さら聞けない】Googleアナリティクスとは?導入手順から使い方まで5分で理解!

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

共同開発でのgithub操作手順

本当にサーバで初めてgitを立てる、初期設定

git init

デベロップブランチを作って入る
git checkout -b develop origin/develop

リモートブランチにある、ブランチをローカルにも作る

※以下のコマンドだと、ブランチが既にあると文句を言われる。
git checkout develop-a origin/develop-a

git -b develop-a origin/develop-a

git checkout -b origin/develop-a

デベロップブランチに戻す。

初期化
git init

コミットしようとすると文句を言われるので以下のgitユーザ登録コマンド:
git config --global user.email "github使用のメールアドレス"
git config --global user.name "github使用のユーザ名"

再度コミット

リモートへpushする手順

//セット中のリモリポ状況を見る
git remote -v

git remote rm [削除したいリモートリポジトリ名]

// リモートにアクセス
git remote add origin https://github.com/github.com/チーム名/リポジトリ名

//リモートリポジトリのurl変更、addでエラー起こるならこれ
git remote set-url origin https://github.com/github.com/チーム名/リポジトリ名

//リモートリポジトリへpushする(developは指定ブランチ)
git push origin develop

以下のようなエラーが出たら、
「git pull origin develop」してから
「git push origin develop」しよう。

int: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

ステージングエリアが汚れてたら。
git reset


更新があった際の操作手順

前提

開発者がgithubでブランチを切ってpushしたらそのブランチを自分のローカルに作って、cloneしておく。
リモートでマージして、壊してしまっても復帰させるため。

差分適応方法

developブランチは常に、更新されるので、自分が差分を追加する際は、
最新のdevelopブランチをcloneしてからそれに、rsyncなどで差分を適応する。
ローカルブランチに落として、マージでもよい。

(※)ブランチ状態を確認する。
git branch -a

(※)Aさんの更新をローカルに持ってきているのでそれをマージ
git merge develop-a

git checkout -b develop-a origin/develop-a

作ったnew新規ブランチ切り替え
git checkout develop-b


続:

git cloneで落としたソースを、運用ソースと差し替えると、
パーミッションのズレが発生して、トラブルになることが多かった。
なので一部だけrsyncでアップデートする方法を取る。


rsyncでの更新手順:セットアップ

git cloneにてリポジトリ展開

git clone https://github.com/チーム名/リポジトリ名

初期スクリプト実施

ディレクトリ複製
cp -pr ./展開したフォルダ名 ./複製するフォルダ名

rsyncでの更新手順:更新ある度

複製ディレクトリへgit pullし差分を適応

複製ディレクトリから運用ディレクトリにrsync


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

Git リモートリポジトリを変更

リモートリポジトリの確認

Macターミナル
git remote -v

リモートリポジトリの変更

Macターミナル
git remote set-url origin {new url}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ローカルのMasterブランチを誤って消去した時の対処法

ローカルにMasterブランチをもっていて、そこからブランチを切って作業しているときに誤ってMasterブランチを消してしまった場合の対処法について書き留めます。

対処法は、"gitでリモートブランチをローカルにcheckoutする"を参考にさせていただきました。

対処法

git checkout -b ローカルブランチ名 origin/リモートブランチ名

checkoutにbオプションをつけ、第一引数にローカルで使用するMasterブランチ名、第二引数にリモートのMasterブランチ名を指定します。

これで、リモートのMasterブランチをローカルに持ってくることができます。

間違ったやり方

次に自分がやってしまった間違ったやり方を紹介します。

1.新たにブランチを作成してリモートからMasterブランチをpullする

自分がまず初めにやってしまったのが、次の二つのコマンドです。

git branch Masterブランチ名
git pull origin Masterブランチ名

完全に初心者ミスです。
gitをある程度知っている人なら、当たり前にダメなことだとわかると思います。

なぜこの方法がダメかというと、、、
現在作業しているブランチは、Masterブランチに変更を加えている状態です。
そこから新たにブランチを作成すると、現在の作業内容が反映された状態のブランチが作成されます。
その作成したブランチにリモートのMasterブランチをpullすると、現在の作業内容がMasterブランチがMergeされたブランチが出来上がってしまうからです。

git log --graphなどで確認すると、流れがわかるかと思います。

2.リモートからcloneする

これも完全に初心者ミスです。次のコマンドをやりました。

git clone https://github.com/AAA.git

「これでリモートのMasterブランチをローカルに持ってこれるやろ!」と思い込んでました。
ですが、結果は新たにリポジトリを作成されて、そのリポジトリにMasterブランチがある状態。

この時、ブランチとリポジトリの違いがよくわかっていなかったです。。。

これはなぜダメなのかというと、cloneはリポジトリをリモートからローカルへ持ってくるコマンドなので、ブランチのみをローカルへ持ってくるわけではないからです。(たぶん..)

まとめ

今回自分がやってしまったミスは、gitの仕組みをしっかり理解できていなかったからです。
仕組みさえ理解できていれば、すぐに解決できると思います。
gitって慣れるまで難しいですよね。。。
もしよくわからなかった方はgitの仕組みをもう一度勉強してみてください。

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