For the love of everything holy and dear please write code and store it in git. Git is our default revision control system. github can be considered a default git service provider.

You may have a pre-installed version of git. You can install git with:

brew install git 

We use GitHub as a central git repository to store code. This is free public git service.

NOTE: GitHub repositories can be public or private but do NOT trust in the privacy of a repo to provide security - keep all sensitive data in a secure location outside of git and your local compute environment, eg secrets manager.

Each user must create a personal GitHub account. Your personal GitHub account will be granted access to repositories for the projects/teams you are working on.

make sure git is configured with your identity:

git config --global user.email "[email protected]"
git config --global user.name "Your Name"

Also make sure your identity in github is the same as above so that if you use github via browser your commits will have the same identity.

Create a key-pair:

ssh-keygen  

Go to your personal GitHub site:

• click on your GitHub user icon in the top right corner
• select settings and look to the left for SSH and GPG keys
• add your PUBLIC SSH key (hint look for a file in ~/.ssh/yourpublickey that was created with ssh-keygen

It's helpful to define a place on your filesystem to store all your GitHub repositories, eg ~/github/$yourgithubusername/. This is a personnal preference and you should organize where you store local versions of repositories that best suit the way you work. You should clone repositories you work on under the directory structure you choose.

Gitflow Workflow is a continuous software development framework for managing projects by defining a strict branching model designed around project releases. Different branches have specific roles to define who, how and when project artifacts should be deployed. In addition to feature branches, it uses individual "topic" branches for preparing, maintaining, and recording releases. Topic branches are worked on until there is content to be merged into one of the static defined branches via a pull request, aka PR. Benefits of this "Feature Branch Workflow include: isolated experiments and more efficient collaboration.

A pull request is created by a developer from a feature or bugfix branch to merge code to a release branch. Usually, the pull request is created during release time when a bug needs to be fixed in the release branch. The pull request is merged by a technical lead.

A pull request is created by a technical lead or developer from the release branch to merge code to the master branch. Usually, the pull request is created during release time when the code is ready for deployment. The pull request is merged by the next-level person or the technical lead who created it.

A pull request is created by developers from their respective bugfix branches to merge code to both the master and release branches. Usually, a pull request is created to provide a critical fix in deployed code. The pull request is merged by a reviewer. In most cases, a reviewer is a technical lead. This merge request should be reviewed with more care as it will directly merge code to the master branch.

You should create a fork of any organization repository you're working on. There's a fork button on git repositories. You should work on your forked version of an organization repository and make pull requests against the organization repository.

git clone [email protected]:yourgithubuser/somerepo.git  ~/github/$yourgithubusername/
cd  ~/github/$yourgithubusername/

When working on forked versions of an organization repository you may want to have the original repository set as a remote

git remote add mainRepo [email protected]:yourorganization/somerepo.git

This way you can fetch and merge the official organization repository into your local forked version. You can fetch the official organization repo with:

git fetch mainRepo

You can merge the master branch of official organization repository into the current branch of your local forked version.

git merge mainRepo/master 

create topic branches for the work you are doing

git checkout master
git checkout -b mytask
# write code, test, fail, fix, rinse and repeat until done
git status -u all .
git commit -m "fixes whirled peas" world-peace.sh
git push

You can do this in the console but it's so much easier to do via cli...

Note: Although it is possible to skip pull requests and push code directly to branches, pull requests shouldn’t be avoided as they provide better quality and stability for code. Benefits of pull requests include:

• Collaborative platform to discuss potential modifications to the code.
• Improve code quality.
• Simplify the process of receiving feedback from the reviewer.
• Address feedback easily in-line near the relevant code.
• Provide better stability for the code.

gh CLI utility integrates with the GitHub website programatically instead of using a browser.

brew install gh

PRO TIP: create aliases for these commands in your ~/.bashrc or ~/.zshrc like the following:

You now just type pr and it reminds you of the syntax needed to do the job.

 alias  pr="echo gh pr create --title '   '   --body '    '"

Common GH commands to use:

  - Check on a pull request status
      a) gh pr status
  - Create a pull request
      a) gh  pr create --title  ‘updating my cool terraform code’ --body ‘ please review’ 
  - Setup a CLI login to your personal GitHub account
      a) gh auth login
  -  To view all current Pull Requests in the GitHub organization
      a) gh pr list.   (Note: use -L flag to if create than 10 pull request  exist.  EG: gh pr list -L 50
  - To view the status of your relevant Pull Requests.
      a) gh pr status
  - To Comment on Pull Request
      a) gh issue comment 10 —body “It is 5 oclock somewhere”