回答編集履歴
3
1\. のやり方に関する訂正等
answer
CHANGED
@@ -7,7 +7,7 @@
|
|
7
7
|
今回僕が思いついた3つの方法を紹介したいとおもいます。
|
8
8
|
|
9
9
|
## 1. 一つブランチを作ってそこに投げる方法
|
10
|
-
これをやるためにはコミットしないといけませんし(作業単位のコミットにならない場合がある)、特定のブランチモデル等を使っているのであればネットワークも荒れるのであんまり理想的ではありませんが、一番手っ取り早い方法です。
|
10
|
+
これをやるためにはコミットしないといけませんし(作業単位のコミットにならない場合がある)、特定のブランチモデル等を使っているのであればネットワークも荒れるのであんまり理想的ではありませんが、 一番手っ取り早い方法です。
|
11
11
|
|
12
12
|
### 送信する側
|
13
13
|
```shell
|
@@ -23,9 +23,7 @@
|
|
23
23
|
git checkout workspace
|
24
24
|
```
|
25
25
|
|
26
|
-
## 2.
|
26
|
+
## 2. patchを作り、その結果をメール等で送る方法(diff/apply)
|
27
|
-
このやり方が僕の一番のおすすめです。
|
28
|
-
|
29
27
|
### 送信する側
|
30
28
|
1.以下のコマンドを使って、patchファイルを作成
|
31
29
|
```shell
|
@@ -54,4 +52,9 @@
|
|
54
52
|
|
55
53
|
* [どこでも使える git diff と git apply](http://qiita.com/uasi/items/905376f02ff029fb23f8)
|
56
54
|
|
57
|
-
* [別のgitリポジトリから取ってきたパッチをgit apply/amしたいとき](http://qiita.com/endrugus/items/ec1a1f49d9945f290360)
|
55
|
+
* [別のgitリポジトリから取ってきたパッチをgit apply/amしたいとき](http://qiita.com/endrugus/items/ec1a1f49d9945f290360)
|
56
|
+
|
57
|
+
### 訂正
|
58
|
+
1.の方法の持つ問題点ですが、これらを解決方法が存在するそうです。
|
59
|
+
(詳しくはここの回答の質問フォーム部にmattn様に書いて頂いています。)
|
60
|
+
となると、やはり一番有効な手段は1.の方法かと思います。
|
2
参考の追加
answer
CHANGED
@@ -47,4 +47,11 @@
|
|
47
47
|
|
48
48
|
# 最後に
|
49
49
|
以上のような説明でよろしかったでしょうか?
|
50
|
-
何
|
50
|
+
何か質問があれば是非お願いします。答えられる限り答えたいと思います。
|
51
|
+
|
52
|
+
# 参考
|
53
|
+
* [git-scm](https://git-scm.com/book/ja/v1/Git-%E3%81%A7%E3%81%AE%E5%88%86%E6%95%A3%E4%BD%9C%E6%A5%AD-%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E9%81%8B%E5%96%B6)
|
54
|
+
|
55
|
+
* [どこでも使える git diff と git apply](http://qiita.com/uasi/items/905376f02ff029fb23f8)
|
56
|
+
|
57
|
+
* [別のgitリポジトリから取ってきたパッチをgit apply/amしたいとき](http://qiita.com/endrugus/items/ec1a1f49d9945f290360)
|
1
git applyの説明の追加、方法1のデメリットに関して追加
answer
CHANGED
@@ -6,10 +6,10 @@
|
|
6
6
|
# 解決法
|
7
7
|
今回僕が思いついた3つの方法を紹介したいとおもいます。
|
8
8
|
|
9
|
-
## 1. 一つ
|
9
|
+
## 1. 一つブランチを作ってそこに投げる方法
|
10
|
-
これをやるためにはコミットしないといけませんし、ネットワークも荒れるのであんまり理想的ではありませんが、一番手っ取り早い方法です。
|
10
|
+
これをやるためにはコミットしないといけませんし(作業単位のコミットにならない場合がある)、特定のブランチモデル等を使っているのであればネットワークも荒れるのであんまり理想的ではありませんが、一番手っ取り早い方法です。
|
11
11
|
|
12
|
-
送信する側
|
12
|
+
### 送信する側
|
13
13
|
```shell
|
14
14
|
git checkout -b workspace
|
15
15
|
git add -A
|
@@ -17,21 +17,31 @@
|
|
17
17
|
git push --set-upstream origin workspace
|
18
18
|
```
|
19
19
|
|
20
|
-
受取側
|
20
|
+
### 受取側
|
21
21
|
```shell
|
22
22
|
git pull
|
23
23
|
git checkout workspace
|
24
24
|
```
|
25
25
|
|
26
26
|
## 2. git diffして、その結果をメール等で送る方法
|
27
|
+
このやり方が僕の一番のおすすめです。
|
28
|
+
|
29
|
+
### 送信する側
|
30
|
+
1.以下のコマンドを使って、patchファイルを作成
|
27
31
|
```shell
|
28
|
-
git diff
|
32
|
+
git diff > hoge.patch
|
29
33
|
```
|
34
|
+
2.patchファイルをメールで送信
|
30
35
|
|
36
|
+
### 受取側
|
37
|
+
1.patchファイルをダウンロードしてリポジトリのディレクトリ内に置く
|
31
|
-
|
38
|
+
(別に自分でディレクトリ階層を叩き込めば、リポジトリのディレクトリ内に置く必要はない)
|
32
|
-
ファイル自体は共有されませんが、これが僕の一番のおすすめです。
|
33
|
-
(差分があるので、ファイルも人力で再現可能です。)
|
34
39
|
|
40
|
+
2.patchの適用
|
41
|
+
```shell
|
42
|
+
git apply hoge.patch
|
43
|
+
```
|
44
|
+
|
35
45
|
## 3. リポジトリを圧縮してメールで送る方法
|
36
46
|
リポジトリの大きさによっては、ダウンロード・アップロードともに大変ですし、gitを使っている意味がなくなってしまうのででおすすめしませんが、リポジトリまるごと圧縮してメールで送っても実現できると思います。
|
37
47
|
|