CODEWITHSUNDEEP
gitversion-controlworkflow
sulman
sulman

Reputation: 2461

GIT workflow - help/advice needed to get it right

We are struggling to get the correct workflow in place for our git projects (all websites).

We have 5 devs (frontend & backend) working on 30+ projects at any one time (live sites & beta sites) with multiple tasks being done on each project and each task being worked on by multiple devs (generally there is a back and forth between frontend & backend)

Our current workflow is this:

pull dev branch
work on task
commit to dev branch
push dev 
deploy dev branch to staging site
repeat ad infinitum

When functionality on beta site finally approved by client:

cherry pick commit/commits in to master (We can not merge development branch in to master as there will be mulitple pieces of code in the development branch that are not ready for live.)
push master
deploy master to live
Pray.

Some of these commits can be sat in the development branch for weeks (even months) before approval from the client. By this time the master branch has changed massively and when the "go live" approval is given the devs can't remember what commits relate to the specified task! Also by then the amount of conflicts etc they receive is overwhelming them.

Also, generally the "go live" task is given to 1 dev but they don't know what commits are for the specifics task.

We use branches for large pieces of functionality and that seems to work well, but quite often a small change can develop over time in to a large piece of functionality so no branch was created.

We are ending up with errors on live sites which tend to get fixed directly on FTP as no one trusts the repositories. Also work getting lost/overwritten.

Questions

Is GIT right for us?

Should we be using something else?

Or do we simply need to get our processes correct?

Upvotes: 0

Views: 70

Answers (2)

Disfigure
Disfigure

Reputation: 740

Git is right for you, but your workflow could be optimised.

Use GitLab CI which is simple to use and configure.

You should have your branch dev where you'll merge changes from the child branch.

So the schema is like :

  • Master/Prod
  • Staging
  • Dev
    • Your child branch for the feature

Your developer have to develop a feature which is called User-Product-Wishlist then, he will create the branch user_product_wishlist derived from the up to date Dev branch. Once he did, he will also create a pull/merge request from his branch to the Dev branch, we'll see this a little bit later.

Until your developer ends his task, He surely pushed several commits on its branch.
Before the final push to the server he must rebase its branch on itself to have only one and clean commit.
He checks the amount of commit he did and run the git command (x is the amount of commit ): 

git rebase -i HEAD~X

That will make only one commit for all the change he did, nice isn't it ?

Now the commit history of our feature is clean he can push the work on the remote branch : 

git push origin user-product-wishlist -f

The --force (-f) option is used always use after a rebase because it changes the commit timestamp history so we need to override the previous version on the server.

Now its time to accept the pull/merge request after your team did the code review or any other checks you may process. If you see the pull/merge request having conflict because other dev merged theirs features into dev, you have to rebase your current branch with the remote Dev branch, so :

git rebase origin/dev

Resolve conflict if you have, if not you can push your branch to update it on the server : 

git push origin user-product-wishlist -f

Now you can accept the pull/merge request and merge on the DEV branch.

You will keep a clean commit history on Dev branch, even after merged branch etc ...

If you need to rollback to a specific version looking into your commit history will be easier !

Now its up to you to choose when to deploy to staging or production

If you have multiple features to test, you can create different pull/merge request checkout this branch on your server and once it is tested and confirmed then you can merge.

Upvotes: 0

Bittu Choudhary
Bittu Choudhary

Reputation: 151

You should maintain a staging branch. You should create a branch from master if it is a quick fix on master. Merge this code in staging and deploy staging for client testing. merge staging in master after go live approval.

If it is not a quick fix then you should create task-branch from dev and merge it in staging after finishing it. Deploy it for client testing and merge it into master after go live approval.

Upvotes: 1

Related Questions