22

私は、プロジェクトの小規模な開発者チームで git と github を使用してきました。私たちのやり方は正しくないと思わずにはいられません。他の人がプロジェクト内でこのワークフローをどのように使用しているかを知りたいです。

使用方法: 各変更の前に分岐し、マスターにマージし直して、ローカルでコミットし、github リポジトリにプッシュします。次に、テスト環境に SSH 接続し、github リポジトリのマスター ブランチをプルします。を完全に把握していないかrebase、まだ把握していません。fetchtagging

使用方法: さまざまなサーバーに SSH 接続し、「フェーズ 1」などの特定のタグ付きバージョンをサーバーにプルできるようにしたいと考えています。これは可能ですか、それとも 2 つの異なる github リポジトリが必要ですか?

Web サーバーへgit pullの特定のブランチを作成するか、新しいエイリアスを作成する必要がありgit pushますか?

1 つの git リポジトリ内でリリース候補または環境 (テスト、開発、本番) を制御できますか? それとも複数必要ですか？

引っ張ることが解決策である場合、特定のものを引っ張ることができますtagか?

4

3 に答える 3

16

Pro Git の本を読んでください。1 年間 git の man ページを読んでも理解できないことがあります。man ページを読んで git を学ぼうとすることは、辞書を読んで新しい言語を学ぼうとするようなものです。この本では、git で使用できるいくつかのワークフローと、使用する git コマンドとそれらを使用するコンテキストについて説明します。

于 2009-11-24T15:36:51.877 に答える
8

基本的に、1 つの「中央」GitHub リポジトリで十分に機能できます。

  • タグは不変のポインターであり、テスト環境または運用環境にチェックアウトするために、いつでも使用 (およびプッシュ) できます。これにより、ある程度の検証が行われますが、通常は開発には役立ちません。
  • ブランチをプルするということは、そのブランチ内でいくつかの進化を行うことができることを意味し (コードが実稼働環境に置かれた後にいくつかのバグ修正と調整が必要なため)、他のすべての開発者のリポジトリにプッシュバックして、彼らがプルバックして考慮できるようにすることができます。

したがって、それらのサーバーで何をしているかによって異なります。検証のみ (ステータスが承認または拒否されたもの) か、さらに開発を行うかです。
いずれの場合も、適切な命名規則を持つタグは、履歴内の特定のコミットを追跡するのに適していますが、開発作業を分離する必要があるたびにブランチが必要です。

于 2009-10-22T04:14:11.223 に答える
4

GitHub では、「祝福された」コードが存在する会社用に 1 つのアカウントを使用しています。その後、個人的なフォークを維持し、まだ安定していない作業に取り組んでいます。私のローカル マシンでは、両方を 1 つのリポジトリで処理するため、master が祝福されたコード (および会社のアカウントにプッシュ) であり、他のすべてのブランチはフォーク用です。これが私の .git/config の一部です:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:xiongchiamiov/fourU.git
[branch "hacking"]
        remote = origin
        merge = refs/heads/hacking
[branch "editor"]
        remote = origin
        merge = refs/heads/editor
[branch "problem-utils"]
        remote = origin
        merge = refs/heads/problem-utils
[branch "tests"]
        remote = origin
        merge = refs/heads/tests

[remote "trunk"]
        fetch = +refs/heads/*:refs/remotes/trunk/*
        url = git@github.com:xyztextbooks/fourU.git
[branch "master"]
        remote = trunk
        merge = refs/heads/master

私は会社のリポジトリのコミット権限を持っているので、あるブランチから別のブランチにコミットをマージ (またはチェリーピック) し、適切な場所にプッシュすることができます。個別のリポジトリは確かに必要ありませんが、これはオープンソース プロジェクトであるため、「公式」リポジトリには接線によって作成されたランダムなブランチがないようにしたいと考えています。バージョン管理されるポイントに達すると、各バージョン (0.1、0.1.1、0.2 など) のタグが付いた 0.x ブランチが作成されます。これは、github がファイルの tarball を自動的に作成するため、特に有利です。各タグで、完全な履歴を必要としない特定のバージョンをマシンにプルダウンするのに適しています。

github ブログを読む必要があります。彼らはデプロイ ワークフローを説明する素晴らしい投稿をいくつか持っていますが、これにはもちろん git が大きく関係しています。

于 2009-11-03T20:17:18.140 に答える