It is always good to establish a git foundation to work off. There are many reasons such as if you are working with multiple developers on one project, and if your client wants certain changes to be on specific sites. By following a great git foundation this will prevent you from having an extreme amount of merge conflicts to go through and this will help instil an agile methodology of work.

Why do you need to establish a git foundation?

Some people might use git with just one branch, and these are the negative effects below which can be prevented by implementing a good git flow practice.

• If there are multiple developers working on one branch this can lead to lots of merge conflicts as the developers could be working in the same files. Also, if the developers are committing small changes as they go this could also lead to new functionality being developed on top of incomplete functionality.
• If the client wants a new feature deployed on to their production site and they want the rest of the changes to stay on the staging site. This would be impossible since everything is on one branch it is impossible to only deploy one feature, everything would need to be deployed together.

What is good git flow practice?

1. First step is to have a branch per site your client has (eg. dev branch, staging branch and a production/master branch). This will help with being able to deploy specific features to specific sites. Another benefit is that if there is particular configuration per site you can have a file that is ignored by git on each branch which will have the correct configuration for that site and will never need to be changed.
2. Next would be to create a new branch whenever you are working on a new feature or a bug.
   Some things to note:
   • You should always create your branch off of master/production. This is because the master branch will contain all the changes that are on all the branches whereas the changes on the other 2 branches might not be on all the other branches. Whichever branch you create a branch off of means that everything on that branch is now on your branch.
   • If your team is using Jira, it is good to name your branch with the Jira code. This will then link that branch to the task in Jira and you will be able to see if that branch has been merged in anywhere or not.
   • Only merge master into your branch.
   • Make a PR (Pull Request) when you are fully complete with your changes to the dev branch.
3. Next when a client requests a particular feature or bug fix you make a PR for the task branch into the relevant branch (dev, staging, master) and then the branch has been merged into master you can delete the branch as it is at its final stage.

Happy git flowing!