Organization of work through Git

I

Ivan Panteleev2012-09-25 13:59:42

git

Ivan Panteleev, 2012-09-25 13:59:42

There is a test server, which is a complete copy of the combat one. All new functionality is tested on the test server, and only then transferred to production.
As far as I understand, the test server and production should be two different repositories? What is the best way to set up Git so that you can checkout from the test server and commit changes there to check how they work. Is it necessary to create a new branch for every change? Or can I commit to the master right away? There are only two programmers so far, and the less transparent and easier the interaction scheme, the better.

I have never worked with Git before, please advise which work scheme would be the most logical in this case?

Reply

Answer the question

In order to leave comments, you need to log in

2 answer(s)

U

un1t, 2012-09-25
@Yekver

You can make two branches master and devel. In development, in the master, stable code that is taken to the test server. For already tested code, before putting it into production, make a releaseN branch, where N is the release number. A separate branch for releases is needed in case of hotfixes. For large features that last from several hours to several weeks, it is better to make separate branches (although for 2 developers this may not be so relevant). For small features, you can make local branches, or you can immediately commit to dwevel.

V

Vyacheslav Plisko, 2012-09-25
@AmdY

In no case do not do only two branches, in the same git, brunching is the most elementary and most pleasant thing.
You need to have two main branches - stable, current. In the first, a stable build, and in current, the last merged pull requests until it is decided that current is stable, then they are merged into stable, tested, and a tag is made.
You seem to be using an analogue of the github gitosis.
The main repository was described above, let's call it upstream.
Each developer has his own repository on the server (let's call it origin), he branches from the main / current branch, makes changes (we try to do this with one commit, --amend for edits), when he is ready to push the branch to origin on gitosis, makes a pull request in upstream.
Be sure the second programmer makes a review, checks that nothing is broken, and only then he presses the push button.
The build for production is going to be ant or copystrano, from the tag, maximum from stable.