0

Wondering if some light could be shed on how git workflows should work? I'm 100% sure our current method is completely wrong as its not really working out. If I can explain how we are currently operating and if someone can tell me where we're going wrong, that would be awesome.

We have 2 developers working to a Dev branch, and testing on a Dev server (which requires us to ftp the files we're working on up to the server). Once changes are tested and completed, we then replicate the change on a production branch, which is the ftp'd upto the live server. This means we have to keep track of every single change we make. Thankfully Git is awesome at giving us that information but we don't really know what files we have already put on the servers etc. Dev is currently used to fix bugs etc for production/live, but it will soon be used for new features. Both branches are different as the specific to their own servers.

We were relatively new to git at the beginning of our development, but feel like we've taken a massive step back when going into production.

Summarise:

  • 2 developers
  • 2 branches (Dev / Prod)
  • both Dev using sourcetree as a client and GitHub as a remote repo
  • both branches need to run in tandem and be easily pushed / updated to respective servers

Can anyone help me out?

Linkid
  • 517
  • 5
  • 17
grhmstwrt
  • 341
  • 1
  • 6
  • 20

3 Answers3

0

let's put it in a simple way:

Initial development has started on Branch dev: Once the development for one functionality/feaure is finished, you checkout a branch say sprint1.

Have a independent server say server1, clone the project and checkout to sprint1 branch and restart the server.

Now server1 can be used by QA's for testing with no new changes coming in.

Developers keep working on dev branch.

Once QA's have verified the changes, checkout a new branch Production from sprint1 and deploy on new server say server2.

No manual copying or moving of files involved.

Now when new changes have been pushed to Dev branch. Go to sprint1 branch and merge dev branch. So now sprint1 has latest code to be tested by QA's.

Once changes verified, checkout to production branch and merge the sprint1 branch. This level of code push should not create issues and make things simple. Let me know if explanation has enough clarity.

Refer Git branching and merging for how it works.

Bijendra
  • 9,467
  • 8
  • 39
  • 66
0

If you make changes in you're dev branch on your dev server, you need to commit them in this branch. Then, you will be able to merge this branch into you're production branch and put this one in you're production server.

For new features, I think it's a good idea to use branches. They are meant to be for this task. Then you merge them into you're dev branch.

I suggest you to read this post, which details a great workflow: http://nvie.com/posts/a-successful-git-branching-model/.

Linkid
  • 517
  • 5
  • 17
0

You don't need to invent the wheel. Use git flow.
Here you can view an excellent presentation described in details.

enter image description here

CodeWizard
  • 128,036
  • 21
  • 144
  • 167