CODEWITHSUNDEEP
git
CIB
CIB

Reputation: 795

Two development stages with git

I want to start using git in my projects. I currently develop on a remote server the client then checks the site if everything is OK we then copy all the files and DB to the our live remote server.

My understanding of git is that we can develop locally, then submit the changes to the staging area and then commit them to the live site.

Is there away to include a development preview for the client to look at?

So we would develop locally then submit the changes to staging then commit them to a development space for the client to look at once we get approval some how send them to the live server? Is that the way to approach it?

Upvotes: 1

Views: 74

Answers (3)

user5524981
user5524981

Reputation:

I can share with you my experience: in my company we have normally two main branches (test and master), and few minor development branches.

Usually every developer work on his development branch locally, but time to time, when the developer make some progress push all the work (his development branch) into the remote repository.

As you can imagine, test branch is used mainly for test environment and master for production env. When you start to fix a production bug, usually checkout the master, fix the bug, push to remote repo and release in production. Then you have to merge back the master into test branch, and in all the open development branches.

In test branch is where we merge a development branch at time, then we start to test the code in the environment and when everything is ok (i.e. Test passed and tester thumbs are up), we merge test branch into the master and release everything in production.

As you can understand our team is small and it is quite simple. Very important rule is: you can commit (or merge) into the master only when your are absolutely sure to release in production.

Hope this helps.

Upvotes: 1

Dmitry Kalabuk
Dmitry Kalabuk

Reputation: 36

If I understood you correctly, what you actually need is one branch for development preview and another for approved version of the project. (This common approach is described here: git-scm.com/book/en/v2/Git-Branching-Branching-Workflows) If by client you mean someone who don't have local access to git repository, but has access to the remote server, then you will have to push your commited work to remote so that he can see the changes. With git branches you don't have to worry about working version of project. You have both of them "present" and you can merge development branch into stable whenever you want.

Upvotes: 0

tripleee
tripleee

Reputation: 189936

You would normally commit, then push to staging, where you test, then push to production. Adding a second public staging server is easy, if you want to keep your regular staging private.

Git doesn't enforce or require an of this; it's just version control. But what you describe is easy to do.

Upvotes: 0

Related Questions