Hi everyone!

I wanted to share some best practices when it comes to GIT version control, how you can organize your branches in a way that merges and rollbacks are more granular, making it easier as well to see what code changes were done where

Typically, what I tell clients when they are using GIT integrated with Ataccama, is that they would essentially need to have a standard flow control process for their branches. What I mean by that, is that they should set up 1 main production branch, 1 development branch, and many feature branches. You can think about it like this, your Master branch can be thought of as your “Production” branch, your Development branch can be thought of as your “Test” server, and each of those feature branches you can see it as your “Dev” server where you develop new code. How this works is simple yet effective:

• You start off with a main branch in your repo, we can call it “master”
• Master can have either prior code or be empty, let's say it has some code in it already
• We now have 1 branch with all our code in it, this means that to test it on a server, we would have to save that code, and commit / push it so that GIT saves our code.
• The issue with having only 1 branch and doing this is, if you have added 5 or 6 new additions to your code, and 1 of them in your latest push has any issues, when you roll back, you will lose all 5 or 6 of those changes, not just the faulty code one
• There is a way around this:
  • I would like to create a development branch out of that master branch, so that I may do unit-feature testing, following these steps:
    • Go to your current repository in the “git repository” tab view
    • Click the arrow next to your repo to reveal the “branches” tab
    • Click the arrow next to the “branches” tab
    • Click on the arrow next to “local” (assuming you already have a local instance of your branch on Ataccama)
    • Right click on the branch you want to base your new branch off (In this case, it would be “Master”)
    • Click “Create Branch...”
    • Give the new branch a name, we will call this one “Development” 
    • Make sure the bottom checkmark is still enabled for “check out new branch”
    • Now that your new “Development” branch is created, go to the “Git staging” tab view and push head, this is so that the code and the branch will also be tracked on GIT’s cloud servers and not just locally on your device
    • You should now have checked out the “Development” branch and are able to do testing there instead of on your Master branch to better handle version control
  • Now that we have a development branch where we can do unit testing, we want to create what is known as a “feature” branch, these feature branches are needed to further the granularity of your pushes, meaning each commit and push of a feature branch, should be exactly one feature that is being added or changed, i.e. added a new file, made a code change in 1 file, added a component, etc…
  • Typically, we want the feature branches to be named like “feature_xxxxxx”, where the x’s can be either what the feature is called, like “new_partition_MDM” or the story number for the feature like “feature_US1001” if you are using Agile methodologies
  • Let's say we have “Master” and “Development” branches that are stable, and both have the same code (since we would promote Development code to Master branch once all testing is done). We are tasked now with adding a new feature to the code, we want to add a scoring step into one of the files to better understand what records are having high amounts of issues
  • This would be the steps for the new “feature” branch:
    • Go to your current repository in the “git repository” tab view
    • Click the arrow next to your repo to reveal the “branches” tab
    • Click the arrow next to the “branches” tab
    • Click on the arrow next to “local” (assuming you already have your Development branch in Ataccama already)
    • Right click on the branch you want to base your new branch off (In this case, it would be “Development”, so that we can create a new feature branch)
    • Click “Create Branch...”
    • Give the new branch a name, we will call this one “Feature_US001” 
    • Make sure the bottom checkmark is still enabled for “check out new branch”
    • Go ahead and finish and create your new feature branch
  • Now that we have created “Feature_US001”, you are able to make as many trial and errors on that scoring step you are adding as you want, that you can have confidence that it wont break your working “Master” branch
  • You will do your trials and errors on this branch, once you can certify that the code is working on this branch, the next step would be to promote the code from that “Feature_US001” branch, to your “Development branch”, following these steps:
    • Make sure that all the code in your “Feature_US001” branch is saved, committed, and pushed to the remote
    • Go to your current repository in the “git repository” tab view
    • Click the arrow next to your repo to reveal the “branches” tab
    • Click the arrow next to the “branches” tab
    • Click on the arrow next to “local”
    • Right click on the branch where we want the code to be promoted to (this is the “Development” branch in our case, since we want to promote code to there)
    • It will then prompt you to select what branch you want to merge INTO “Development”, you will select “Feature_US001” and make sure that “Commit (commit the result)” in merge options is checked, which should be the default setting anyways
    • You can then click merge, promoting the code from that feature branch to your “Development” branch
  • Now that the code is in your development branch, you can do a full unit test on that branch, to make sure that there are no conflicts between the newly added code and the previous existing code
  • Once your “development” has been fully tested and works correctly, you can now promote that code to your “Master” branch by following similar steps as above:
    • Make sure that all the code in your “Development” branch is saved, committed, and pushed to the remote
    • Go to your current repository in the “git repository” tab view
    • Click the arrow next to your repo to reveal the “branches” tab
    • Click the arrow next to the “branches” tab
    • Click on the arrow next to “local”
    • Right click on the branch where we want the code to be promoted to (this is the “Master” branch in our case, since we want to promote code to there)
    • It will then prompt you to select what branch you want to merge INTO “Master”, you will select “Development” and make sure that “Commit (commit the result)” in merge options is checked, which should be the default setting anyways
  • You now have promoted your new feature from the feature branch all the way to the master branch, the master branch is typically associated with your Production server, so this code now should be live, and all others can see it online

Below I added an image to show how the flow control would look like in general: