回答編集履歴
1
追記
answer
CHANGED
@@ -9,4 +9,26 @@
|
|
9
9
|
・必要なら手作業でビルドされたものをチェックする
|
10
10
|
・社内サーバーからリモートリポジトリにPushする
|
11
11
|
|
12
|
-
こんなところですかね…
|
12
|
+
こんなところですかね…
|
13
|
+
|
14
|
+
#追記
|
15
|
+
やっぱり初めてっぽいので、それよりも前の段階についても書いておきます。
|
16
|
+
ただ外注でやったことが自分の方にもないので、先方に受け入れてもらう部分は勘です。
|
17
|
+
|
18
|
+
1.社内用のGitリモートサーバーを立てる。(これにGitBucket等を使うことを推奨)
|
19
|
+
2.受注で教えてもらったリモートサーバーから社内リモートサーバーにCloneする
|
20
|
+
3.全開発者のPCにGitをインストールする
|
21
|
+
4.開発者のPCは社内用のリモートサーバーからCloneして開発作業を行う
|
22
|
+
5.開発開始時にはCloneしたmaster(又はdevelop)ブランチから新しくブランチを作り、社内サーバーにPushする際にはPull Requestを利用する
|
23
|
+
6.社内リポジトリの最新状態で受け入れテストを行う(ここをJenkins等に手伝ってもらう)
|
24
|
+
== ここから勘 ==
|
25
|
+
7.単にPushする
|
26
|
+
|
27
|
+
または、リポジトリーで作業が競合する場合(誰かが本番環境を弄る場合)
|
28
|
+
|
29
|
+
7.リモートサーバーの状態が更新されているかもしれないのでrebaseする
|
30
|
+
8.リモートサーバーにPull Requestを投げる
|
31
|
+
|
32
|
+
…が、本来小さい修正なら正攻法ですが規模が大きそうなので、競合しないようにソリューションやgitリポジトリを分けてもらう必要があると思います。
|
33
|
+
被らないとしても、大きなマージが競合するようになると地獄を見るので。
|
34
|
+
とりあえず社内サーバーの扱い方になれてから、先方とPush方法については打ち合わせてください。
|