Introduction

For periodically syncing changes of your Github repository you can automate the process using a script and crontab on Mac OS. It's really quick and simple if you don't have more complex requirements. Note taking is one of the use cases where you want periodic sync to take place automatically to ensure notes are pushed to the cloud without any manual steps.

Setup

1. Open terminal and type crontab -e this will open an editor where you can specify which script to execute, here we want to push our changes so we will point it to that script. Here we have used cron expression "* */2 * * *" which will execute the script every two hours. You can use crontab.guru to generate the expression as per your requirement.

* */2 * * * /path/to/sync.sh >> /path/to/logs/run.logs 2>&1

Save the changes. (Type :wq! to save) 

File sync.sh should be accessible and hold required permissions. Use chmod command to update the permission to necessary state.

2. Define sync.sh in following way to push your changes. Prerequisite is that you have cloned and setup required github repository in respective folder.

#!/bin/bash

set -e

cd /path/to/repo

BRANCH="main"
COMMIT_MSG=${1:-"Update"}

 if [[ -n $(git status --porcelain) ]]; then
    echo "Changes detected."
    git add -A
    git commit -m "$COMMIT_MSG"
    git push origin "$BRANCH"
    echo "Changes pushed successfully!"
else
    echo "No changes to commit."
fi

Trunk based branching model seems very inefficient in the first place. Initially, I was feeling that it is not utilizing the branching superpower of a version control system like GIT. You see there are a lot of advantages to using branches, including

• …you can develop and test multiple things in parallel in separate branches
• …you can work on multiple releases at the same time by creating a different branch
• …different developers can work on separate branches and once done with the implementation can raise pull requests for review

All these benefits sound true when you choose branching over the trunk-based approach and coming from the same experience I was skeptical about how this model will help in development. However, I reasonably underestimated it as it offers a lot of positive results in the longer run and I’ll try to list down a few of them below.

What is Trunk Based approach?

Trunk based approach is a practice where all developers push their changes to one “trunk”, the main branch rather than creating a separate branch. Having said that this practice doesn’t stop developers from creating branches, in certain scenarios you can still create branches, but these branches must be short-lived which means the branches must be deleted within a few hours or at max within a day.

Why Trunk Based approach?

Continuous integration and early feedback

All the changes must be production deployable. As soon as the developer pushes the changes to the repository the CI/CD pipelines take care of all the things including static code analysis, scan, security issues, etc., and give immediate feedback to the team. The team won’t need to wait for the final merge and integration before release to make this happen.

Fewer conflicts and Fewer merge

Smaller non-breaking changes are pushed frequently throughout the day such that there are fewer conflicts between the developer changes. A developer ensures to sync at least once a day with the central repository to avoid conflicts as much as possible.

Easy to manage and review

Developers push smaller working changes, frequently, and reviewing smaller changes rather than one pull request with several files is still a better and more efficient option.

Encourages responsible push

Due to continuous integration with all environments including production (with toggle feature), it becomes necessary for developers to be conscious about the code they are pushing to the central repository.

Yet it’s not the best choice in all scenarios, in the following situation this approach may not help that much,

• Open Source Projects: You won’t expect anyone to just push changes to your trunk directly, going through the pull request way is the best choice.
• Less experienced developers: When you have more junior members who are still learning, you will need a stringent code review before they sync their changes to the main branch to avoid failures due to minor mistakes.

Conclusion

It is important to choose this based on the nature of your work. For small teams and new projects, this approach can surely help a lot while on the other hand, it can not be as efficient as it seems for legacy systems or teams with less experienced developers.