Git Workflow [Develop-Feature-Release Strategy]

Province of Agusan del Norte

Management Information Systems Division (MISD)

Standard Git Workflow

[Develop-Feature-Release Strategy]

A. Creating a new feature branch

feature branch is a development branch which we create every time we write a new feature. When first creating a new feature branch, we must branch out from the develop branch.

Reason for branching out from develop is we want to make sure that we get the latest additions and updates from all developers who have merged their approved features in develop. This way, we know that we are carrying their changes in our own feature branch and prevent very complicated merge conflicts in the future.

When creating a new feature, the following steps must be performed:

Checkout to develop branch

git checkout develop

Fetch for latest updates in develop branch

git fetch

When you think the updates fetched won’t break anything in your local copy of the repo, pull these updates to override your repo copy with these updates

git pull

Branch out from develop branch

git branch name_of_branch

If above command does not work, then:

git checkout –b name_of_branch

B. Committing in Feature Branch

Committing alone to feature branch only takes effect in your local machine. If another developer performs a fetch or pull in this feature branch, they won’t be able to see these changes.

Additionally, if this feature branch has NEVER been pushed to remote (origin by default), other developers won’t be able to see this branch from the remote and thus cannot checkout from this branch.

If you want other developers to see this branch and the changes, you must push your changes to the remote.

Follow these steps when performing a commit to a feature branch:

Double check your unstaged and staged files to make sure you are committing the correct files

git status

Add unstaged files to staged files

To add specific file:

git add sample.txt

To add all from unstaged to staged (you usually do this if you are 100% sure that everything in unstaged should be part of your commit):

git add .

Note: Only staged files will be committed. So, always double check your staged section if it contains all the needed files/changes that you want to be part of what you are going to commit.

C. Pushing from Feature Branch

Again, we perform a push to make sure our changes arrive to remote and that other people will be able to get a copy of what we made changes on.

To push to feature branch, do:

Perform a fetch first to check if there are changes made other than yours (in case someone else were making changes to this branch and performed a push)

git fetch

If there was a fetch, approach the developers to talk about consolidating their updates with yours before pushing (i.e. a pull and/or a merge may be required)

If nothing was fetched or everything is fine, perform a push

git push

D. Merging Feature Branch to Develop Branch

Again, we merge our feature branch to develop branch so that our approved changes will be carried out to future branch-outs of the develop branch.

For example:

You had a branch where you add a login form UI (without functionality, only UI). You merged this approved branch to develop, so these changes is now part of the develop branch.

Another developer is tasked to add functionality to the login form UI. Since you merged your feature branch to develop, this other developer can now pull from develop, and branch out a new feature branch.

In his own feature branch, he will now be able to see the login form UI you created, and can further improve it i.e. add some functionality.

Note:

Before pushing, always make sure to verify the changes first with senior developer or project manager. If the feature branch is approved, ONLY then we proceed to pushing the changes

2 developers cannot work on the same feature branch. The task in feature branch must be isolated and specific as much as possible.