When comes to git there are some good common sense don’ts:

Do not push unfinished work Do not push –force Do not skip code violations standards

When developing in subsites of the platform we have two main workflows we use on a daily base:

Developing a new feature

When you are developing a new feature, you will always start from the master.

git pull origin master
git checkout master

This will make sure that you are on the latest approved development code, and you fetch all the changes from the remote.

After this we prepare our working environment to start actual development

git checkout -b feature/PROJECT-<TICKETID> (Example: feature/MYTICKET-1234)
git push --set-upstream origin feature/PROJECT-<TICKETID>

These 2 commands will create a local branch from master or next release, and will already initialize this on the remote as well. The second command makes sure that your local machine knows where to PUSH the commits to.

Now is the time that you actually do the development, make the required changes to solve the ticket.

Once development is complete, or it is the end of the day we will take our changes to the remote (in most cases Github or stash).

git add <path to files or directory>
git commit -m "PROJECT-<TICKETID>: What is in the commit?"
git push

You use the git add to add files into your branch, only add those that you actually need to be there.

The commit will then take the files you marked using git add and create a unique hash for those, the hash will be identified by the message you put after.

Only the git push command will put the changed files on the remote (Github or stash), once you have executed this command, the system will perform some basic code analysis.

If the analysis found issues:

You solve the issues first then:

git add <path to files or directory>
git commit --amend
git push

The commit command is slightly different, this is because we do not want to create a new message for every time you fix the code that blocks you from pushing. The git commit –amend should only be used when you were unable to push! Once you have successfully pushed, this command should not be used.

Assuming that the feature is now complete, use the Github interface to create your pull request and follow the template.

A team member will perform testing. If he or she finds issues you will have to pick up the branch again and resolve those. We do the following:

git checkout feature/PROJECT-<TICKETID>
git pull

This is our start, we first make sure that we switch back to the feature branch on your local machine.

Then we pull the latest changes from the remote. This is important because a team member might have changed something.

Once these commands have run we can do again the actual development.

Once development is complete, or it is the end of the day we will take our changes to the remote (in most cases Github or stash).

git add <path to files or directory>
git commit -m "PROJECT-<TICKETID>: What is in the commit?"
git push

The tester can now perform a second round of testing.

Hotfixing an issue on production

This is the same, except:

You start from MASTER branch.

Your branch is names hotfix/PROJECT-<TICKETID>

Hotfixes

Hotfixes they are branched out of master branch always. They are quick and urgent fixes for the flow.

A normal workflow for creating hotfixes:

  • create hotfix branch from master
  • fix task on hotfix branch
  • merge hotfix on master (pull request)
  • create tag
  • merge master on develop
  • delete hotfix branch

In order to merge a hotfix manually (without git flow), please follow these steps. This is assuming you have a hotfix branch called hotfix/TICKET-3901 which was branched off the master branch. First let’s make sure we downloaded the latest changes.

$ git fetch

Merge the hotfix branch into the master branch, making sure we’re up to date with the remote.

$ git checkout master
$ git reset --hard origin/master
$ git merge hotfix/TICKET-3901

Tag the release on the master branch and push the tag.

$ git tag -am "Release 2.0.6." 2.0.6
$ git push --tags

Check out the develop branch and make sure we’re up to date with the remote.

$ git checkout develop
$ git reset --hard origin/develop

Merge the master branch into the develop branch. You might need to solve a merge conflict.

$ git merge master
$ git push

We’re almost done, just remove the hotfix branch, it’s not needed any more.

$ git branch --delete hotfix/TICKET-3901
$ git push origin --delete hotfix/TICKET-3901

Create a hotfix branch remotely

Sometimes in rare situation you may want to create the hotfix directly on the remote repository. Push your work to a correspondend remotly branch.

git config --global push.default simple

Do your work under a hotfix branch

git branch origin/hotfix/TICKET-12345

Create and push your branch

git branch --set-upstream-to=origin/hotfix/<TICKETID> <TICKETID>
git push -u origin origin/hotfix/<TICKETID>