Gitty Workflow

There are a lot of articles on the internet about various git workflows. And sometimes people often confuse themselves as to which one is better for their project.

I’ll be discussing some of the most widely used and production-tested workflow environments that you can integrate into your project management. This specific article will explore the most basic and presumably the simplest one out there, i.e., the Pull/Push Method.

I’m assuming you already have git installed, up and running. If you don’t, you can download it from here and follow the instructions.

Before we explore what push or pull precisely is. Let’s discuss how to set up a git project first.

It’s pretty simple actually, navigate to the directory that you want to add to git and type git init.

> cd awsm
> git init

Once that’s done, you are good to “Git.”

First, let’s understand a fundamental mechanism that Git uses to make your project management efficient and highly available. It’s called Remote repository and Local repository.

A remote repository contains a copy of your project on a cloud, while a local repository is something that sits in your machine where you make changes. In an instance, there can only be one remote repo but multiple local repo’s.

You “push” your changes from your local repo to be available for other collaborators onto a remote repo. While you “pull” changes from remote repo into your local repo done by other collaborators.

Now let’s look at how you can initialize a remote repo and make it sync with your local one.

Pedagogically, I’ll be referencing Github in this article. However, there are a plethora of version control services using Git such as GitLab, BitBucket, etc. All these services follow almost the same principles as GitHub.

Refer to this article for creating a git repo. Once that’s done, simply link remote and local repo using this command.

git remote add origin <remote_repo_url>
git push -u origin --all

OR

You can clone the git repo you’ve just created on Github; this way, you don’t have to go through the above-mentioned two steps.

git clone <remote_repo_url>

Suppose you’re a size of a relatively small team working on multiple features at once. For instance, one team member is working on authentication, the other is building APIs, and the third is working on UI. These are isolated features that can be developed parallelly, not wholly dependent on another.

To be efficient and have full tracking of changes also being isolated from other feature developments, Git has a concept called “Branching.”

A Branch allows a developer to separate the development scope of a particular feature from another feature. Thus, making Feature-A unbeknownst to Feature-B unless merged (will be discussed below).

Whenever you create a new project, Git, by default, creates a branch for you called master/main. The Master branch represents the final changes/source of truth/production-ready changes of your code.

To create a new branch, go to the branch using git checkout <branch_name> you want to branch off.

Let’s say I want to create a feature-a branch from the master branch. Here’s how it’ll look.

git branch feature-a     #creates new branch from master
git checkout feature-a   #switch from master to feature-a branch
____________________________________________________________________
// OR -> shorthand for creating and checkout out new branch
git checkout -b feature-a

So far, you’ve initialized the git repo (remote and locally), created a new branch called ‘feature-a.’ And you’ve built a couple of APIs for your feature, and now you want to push these changes to the remote repo and call it a day. But how do you actually push changes ??

Pushing a change onto a repo requires a 2-step process of:

• Staging &
• Committing

Staging is a process that allows a developer to confirm (index) the changes made to files and later group those changes through committing.

Let’s try to understand using an example.

Suppose, We’ve createdapi.go & app.go containing code for our feature-a APIs, and auth.go & permission.go containing code to authenticate users if they can use Feature-A or not. Now, we may want to group app.go and api.go changes since they are related to APIs, and auth.go and permission.go be grouped since they are related to authentication.

So, we stage app.go and api.go and then commit those changes using a meaningful message.

git add app.go
git add api.go
git commit -m "GET & POST api for feature-a"

Then, we stage auth.go and persmission.go and register a commit.

git add auth.go
git add permission.go
git commit -m "authenticating user when calling for feature-a apis" 

We have created two commits inside our commit log (a ledger containing all the commits). Each has a unique commit-id, which we can revisit at any given point to review the changes made inside that specific commit.

Now that you’ve committed all your changes. Your local repo is now two commits ahead of your remote repo since you’ve only made those commits inside your local repo. To push those two new commits, type git push and it should push these two commits onto the remote repo branch as well.

Alright, now that you’ve pushed all your changes in the ‘feature-a’ branch, it’s time to bring those changes into our ‘master’ branch.

If you’re using a git service such as GitLab or GitHub, you can generate a merge request or pull request to merge ‘feature-a’ into ‘master.’

However, you can also do this through a simple command called git merge

Let’s see how to merge the ‘feature-a’ branch into ‘master.’

git checkout master
git merge feature-a

What git merge is going to do is push all the ‘feature-a’ branch commits onto the ‘master’ branch commit log.

Suppose the ‘master’ branch has commit id 1|2|3 in the commit log and ‘feature-a’ has 7|8|9 commit ids. After merge, ‘master’ will have commit log something like 1|2|3|7|8|9 along with all the ‘feature-a’ branch changes.

The only thing that’s left to do is to push the new commits made into ‘master’ using git push.

In the next article, we’ll discuss how to set up and work with production and staging development environments using Branching.