wip
This commit is contained in:
parent
314fc5bc3f
commit
431530db9e
GPG Key ID:
8CB1087135660B8D
Binary file not shown.
|
After Width: | Height: | Size: 2.0 KiB |
|
|
@ -0,0 +1,104 @@
|
|||
---
|
||||
author: usbharu
|
||||
draft: false
|
||||
categories:
|
||||
- null
|
||||
date: 2025-06-01T12:33:00+09:00
|
||||
tags:
|
||||
- null
|
||||
keywords:
|
||||
- null
|
||||
title: 知っておいて欲しい順 開発に関すること
|
||||
relpermalink: posts/2025-06-01/
|
||||
url: posts/2025-06-01/
|
||||
decription: TBD
|
||||
---
|
||||
|
||||
謎のモチベーションが湧いてきたので、なんとなく書いてみることにしました。基本的に概念の把握のため、正確さを落としています。
|
||||
|
||||
## Git・バージョン管理
|
||||
|
||||
有名なバージョン管理システム。
|
||||
まず、ここで言うバージョン管理というのは
|
||||
|
||||
```
|
||||
2024年4月用企画書1_最終版_誤字修正済み(1)のコピー.docx
|
||||
2024年4月用企画書1_最終版_本当に最終版.docx
|
||||
2024年4月用企画書2コピー（1）最新版.docx
|
||||
```
|
||||
や、
|
||||
のようにファイルのバージョンを管理することです。
|
||||
|
||||
でも上の例ではどれが最新版なのか、どれを編集すれば良いのか、どれが最終的に使われるファイルか分かりません。そもそもプログラミングではファイル名に制約があったり、同じような内容が書かれているファイルが複数あったらエラーになるかもしれません[^1]。
|
||||
|
||||
[^1]: 例えばJavaなら、同じクラスが複数あったらエラーになりますね。
|
||||
|
||||
バージョン管理システムはこれらを機械的に処理し、チームで共有できるようにしたものです。おもに以下の概念を覚えておくと良いと思います。
|
||||
|
||||
### コミット・チェックポイント
|
||||
|
||||
ユーザーが任意のタイミングでチェックポイントのようなもの[^2]を作成し、チェックポイントの履歴をプロジェクトごと[^3]に自由に巻き戻す事ができます。
|
||||
|
||||
[^2]: コミット(Commit)と呼びます。
|
||||
|
||||
[^3]: 正確にはプロジェクトごとではなく、リポジトリ(Repository)ごとです。1プロジェクトに複数リポジトリが関わることも、その逆もあります。
|
||||
|
||||
### ブランチ・分岐
|
||||
|
||||
また履歴の分岐[^4]を作成し、チームメンバーがそれぞれの分岐で作業することで、複数人が別の機能を同時に開発することができます。
|
||||
|
||||
[^4]: ブランチ(Branch)と呼びます。
|
||||
|
||||
### マージ・分岐の結合
|
||||
|
||||
分岐をいい感じに結合し、複数人が同時に開発した別の機能をまとめて最新のチェックポイントとして作成する[^5]ことができます。いい感じに結合できなかった場合、コンフリクト(Conflict/競合)が発生し、手動で治す必要があります。
|
||||
|
||||
[^5]: マージ(Merge)と呼びます。
|
||||
|
||||
### Git
|
||||
|
||||
現在デファクトスタンダードになっているバージョン管理システムです。
|
||||
|
||||
[サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】](https://backlog.com/ja/git-tutorial/) https://backlog.com/ja/git-tutorial/
|
||||
|
||||
## GitHub・Gitサーバー
|
||||
|
||||
[Git](#git)をチームで共有するには、Gitサーバーが必要です。また、[マージ](#マージ・分岐の結合)を行うため、誰かのGitに[分岐](#ブランチ・分岐)の[履歴](#コミット・チェックポイント)全部を送りつける必要があります。Gitサーバーはプロジェクトに存在する履歴と分岐を、1箇所で管理する保存場所のような場所です。
|
||||
|
||||
### プル・分岐の履歴のダウンロード
|
||||
|
||||
まずの分岐の履歴ダウンロード[^6]を行い、他のチームメンバーとスタート地点を合わせます。
|
||||
|
||||
[^6]: プル(Pull)と呼びます。
|
||||
|
||||
### プッシュ・分岐の履歴のアップロード
|
||||
|
||||
開発を進めていき、[コミット](#コミット・チェックポイント)がいくつかできたところで機能が完成したとします。完成した機能を他のチームメンバーと共有、[マージ](#マージ・分岐の結合)するため、機能を開発していた分岐の履歴をGitサーバーにアップロード[^7]します。
|
||||
|
||||
[^7]: プッシュ(Push)と呼びます。
|
||||
|
||||
### プルリクエスト・Gitサーバーでのマージ
|
||||
|
||||
プルリクやPull Request、PRと呼ばれたり、マージリクエストと呼ばれたりもしますが、要はGitサーバーにアップロードした分岐の履歴(ブランチ)をマージする準備のことです。
|
||||
|
||||
プッシュされ、Gitサーバー上に存在する[ブランチ](#ブランチ・分岐)(分岐の履歴)を本流のブランチ[^8]にマージするため、様々なチェックなどを行います。([レビュー](#レビュー))
|
||||
|
||||
[^8]: 開発時点での最新版、最終的にすべてのブランチがマージされてくる大もとのブランチで、develop、main、masterなどがよく使われます。
|
||||
|
||||
### GitHub
|
||||
|
||||
有名なGitサーバーです。[CI](#ci)/[CD](#cd)や[レビュー](#レビュー)に必要な環境が整っています。
|
||||
|
||||
[GitHub](https://github.com/) https://github.com/
|
||||
|
||||
## テスト
|
||||
|
||||
## フォーマッター・Formatter
|
||||
|
||||
## リンター・Linter
|
||||
|
||||
## CI
|
||||
|
||||
## CD
|
||||
|
||||
## レビュー
|
||||
Loading…
Reference in New Issue