Nail the Fundamentals : Git_Good (Git flow best practices)

Have you ever you wished you had a time machine to go back in time and fix that awkward thing you said to someone? or you wanted to choose a different path of decisions for your life? ... as much as I want to write a tutorial on time machines, This blog is about a valuable tool similar to a time machine for developers ...

Git is your best friend when it comes to coding and I regret not using it enough during my undergraduate education. Today I want to discuss the git flow I use day to day in my workplace and hope it brings value to your development journey.

Any repository has two main branches: Master and Development.

Master (Production): is the production code which is being used by the customers. This branch should be ideally bug free. This is not a playground to test new lines of code.

Development (Staging): is the next version of Staging (Master) environment. This means this branch is still close to the master but has one or more new features which are being tested.

To start a new feature in the code base we should:

1) Start with the latest version of the development branch : This is important to always keep your development branch up to date. In big teams you can usually followup with the newest merge requests via the slack or email. This indicates that someone will be altering the current state of development soon and you should pull the latest version of the code: (this avoids future merge conflicts).

to perform this task you can:

git checkout development
git pull

2) Create your new branch: You should create a new branch to work on your new feature and avoid working on development branch. There is usually a convention for naming your branches among your team. My teams's convention is as such: <initials>-<ticket-number>-<featurename> for example I would make my branch using following command:

git checkout -b ek-132-slackbotapirouting

3) Work on your branch: You can make any changes you like to this branch and make sure you commit your changes often as you can revert to older version of code when needed. The commit messages should be a one liner description of what has changes in that commit. This will help you later if you wish to change or squash your commits. Couple of useful git commands when adding and committing code:

git diff                                # will show you all the changes you made. Here if you think you don’t want to add a file just add it to the .gitignore file
git add .                               # will add all the changes 
git add -p                              # here you can see the changes one by one and write (y/n) to add or not add a change 
git commit -m “what this change does”   # to commit the added changes 

4) Time to push the code up: When you have the final version of your code, documented, tested, and refactored, it is the time to add this feature or the development branch.

First we will rebase with the development branch to compare the latest changes on development with our branch and deal with any possible merge conflicts:

git checkout development
git pull
git checkout ek-132-slackbotapirouting
git rebase -i development.                   

You triggered the interactive rebasing. Here you can “reword” or “fixup” commits (basically squashing the commits ) and deal with code-conflict. After rebasing is done, it is time for pushing the code up to the development.

git push -f                       #Force pushing to the ek-132-slackbotapirouting branch

Currently you have your latest changes pushed to the remote branch and rebased with the current state of development branch. This means you will not face a merge conflict when you submit a merge request.

5) Create the Merge request: Now you can create a merge request by going on the web version of your remote repository (ex. Github or Gitlab). Assign the merge request to your software lead for review and copy the request link into the developer's chat for extra code-review. Enable the checkmark for deleting the branch after merging so your repository stays clean.

6) Delete the feature branch: It is always recommended to keep the repository clean.

Deleting the feature branch locally by:

git branch --delete ek-132-slackbotapirouting



Deleting the branch remotely by:

git push origin --delete ek-132-slackbotapirouting

Good Practices:

• Delete your local and remote branch after merging to keep the repository clean
• If you have commits like "fixed a bug" or "fixed white space" make sure to squash them before making merge request
• Always rebase before submitting merge request to avoid merge-conflicts
• Avoid committing specific files to your development machine or process(ex. Gemfile.lock, .env).