Git Workflow

We're using a lightly modified version of the github workflow.

Basic Workflow

• Create a new branch for each feature. (e.g. java-api)
• When the feature is finished, create a pull request.
• The pull request is reviewed and then merged into the master branch.
• The Master Branch then gets compiled and released to the test deployment server.
• We'll tag releases as they're pushed out to the main server. (v0.01, etc)

Create a new Branch

The branch name needs to be lowercase, descriptive and each word should be separated by dashes.

git checkout -b add-vendors-to-dataflex

Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.

Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.

Open a pull request.

Atlassian on Pull Requests

A pull request has source code that comes from one repository (fork or branch) into another. When a pull request originates in a branch of your repository, it is commonly called "a pull across branches." You can incorporate a pull request into your repository using Bitbucket. You can also incorporate a request by pulling the code manually into your local repository and pushing the resulting repository back to Bitbucket.

If a pull request conflicts with your repository, you must manually pull the code to your local repository and resolve the request there. You resolve the conflicts locally by merging or whatever other means works best. Then, push the changes back to Bitbucket. After the push, Bitbucket shows the request as accepted. Pulling a request locally is also a means for evaluating a code change before accepting the change.

A pull request has a source and a destination repository. The source is the repository where the changes reside. The destination repository is the repository into which you want to pull (merge) your changes. Both the source and destination also have a branch () designation:

To create a pull request, do the following:

• Navigate to the repository with the changes.
• Press the Pull Request button.
  The system displays the request form.
• Complete the form as appropriate for your request.
• Press Create pull request.
  The system opens your latest request on the Pull Request page of the original repository.
• To see the list of all the pull requests against this repository, click Pull Requests in the navigation bar.
  The system also sent a notification email to your account Inbox.
• Go ahead and open your account inbox avatar > Inbox.
• Locate and review the pull request email (it should be near the top).
• Adjust the Source branch if necessary.
• Adjust the Destination repository or branch if necessary.
• Enter a Title and Description for your pull request.
• Press Create pull request.

Review branch and merge into master.

If the pull request is a small change with little impact, then it's OK for the person who created the pull request to merge it into the master branch. If the change is a larger change, then the merge should be done with another member of the team.

To accept a pull request

• Go to your repository.
• Click Pull Requests in the navigation bar.
  A list of incoming pull requests under the Open context.
• Click a pull request on the list.
  The pull request details appear and the view defaults to the Diff context. You can also view the Commits or the comment Activity on the request.
• Examine the request using the various contexts..
  If you decide that you want to merge the fork into your own repository, click Merge.
• Confirm the action if prompted.
• Bitbucket merges the changes into your repository, all on the Bitbucket server.

Resolving conflicts.

It's possible that a pull request may have conflict (e.g. two people have changed the same source code file.) When this happens, Bitbucket should give instructions on how to resolve the conflict.

{todo: fill in more detail on conflicts}

Master Branch compiled and released to main server.

After the master branch has been updated, it should be compiled and released.

It's all too easy to just compile the current branch locally, and push it out to the test server. This isn't as scalable as it could be, and there's a tendency for code to be included that isn't in source control. Because of this, I would like quite a strict release process. It should be :

• Create a new folder.
• checkout the master branch
• compile all programs
• ensure test suite works locally.
• create a release folder.
• backup the test folder.
• install the release folder on the test server.
• ensure test suite works on test server.
• let everyone know the test server has been updated.

If you need to push changes to a test server before those changes have been merged into "master", then create a new application on the test server.