2

We have a team of 3 programmers, and a dedicated server that we upload and download files through a FTP client. We are having edit colisions and I immediately thought about GIT. But how would it work in my current setup? See below:

Right now we have 2 remote directories on that server. One is the production environment for our application, and the other is the development. We edit and add news files, test it online and when the update is due, we move the selected files to production. That's simple to understand.

With GIT, how can I branch the repository, make the changes I need and still be able to test it on the same server environment? I assume GIT would branch to my local machine. I need to make sure I'm testing on the same infrastructure before merging.

Thanks for any help in advance, and sorry for the long post.

Lightspeed
  • 33
  • 5

2 Answers2

1

The usual best practice for the remote repo on the server is for it to be:

  • a bare repo (meaning you don't FTP files, you are pushing commits to them)
  • unique (no need for two repos)
  • with a post-receive hook able to detect the branch being pushed (as I did here)
  • with a git checkout --force of the bare repo content to a dedicated working tree (as in here)

That way, you have two branches, each one pushed to the bare repo on the remote server, which triggers the update of the dedicated working tree (one per branch) on that same server.
Once the dev branch is validated, it can be merged to the master branch which is pushed to the same bare repo, and triggers the update of the target working tree.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

Sounds like a great use case for Git. One thing to keep in mind is that Git is a distributed version control system. Each developer will have their own repository, and you'll want to setup a centralized "origin" repository where you share work before publishing it into production.

Linked below is an introduction to a popular workflow: Gitflow. The main take-home to keep in mind is that you'll want to tag specific points in your source code history for testing, and then merge those changes into master only after testing is successful.

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Suggested branch setup

Simplifying Gitflow for a team of 3, you might want to start with two branches: one for each environment you want to produce builds for.

  • master => builds are deployed to production
  • dev => builds are deployed to testing

Sample Update Procedure

The steps below outline one way you might approach publishing to your testing and production environments.

  • Commit changes to dev and push them to origin
  • After development is done, tag the dev branch with a version (e.g. dev/1.0.0)
  • Push that commit to your test environment and verify it
  • If testing passes, merge dev/1.0.0 to master, build, and deploy to production
  • If testing fails, work on another fix using the steps above
  • You might end up merging dev/1.0.2 into master before the next official deployment, for example
  • When you push to production, tag master/1.0.2 so you know it went live

Usually your production environment should be updated via a deployment process that doesn't directly involve git. You'll want to setup a build that deploys code from a specific tagged version in your repository. You could use your existing FTP update process for that part.

Reading Material

Here are some more links to get started. Hope this helps!

Will Bickford
  • 5,381
  • 2
  • 30
  • 45
  • Thanks for the very explained answer. I like this solution.You said I should have 2 branches. Would I be able to branch from a branch in this scenario? – Lightspeed Aug 31 '18 at 03:11
  • Branches in git don't really exist. They're just pointers into your commit graph. You can always create a branch from any commit in the database. – Will Bickford Aug 31 '18 at 03:48