Standard workflow with Git only

Tram Ho


After working for a while, wandering through several companies, I found that each place has different working procedures with Git. This article introduces the working process with Git that I think is the standard only and is also applying at the current company. So, I will not introduce all the Git commands, but just go through the commands I think are enough for your work process at the company.


First day at work

So simple, on the first day of work, there was nothing else to order than git clone . When you want to get the team’s source, just open a terminal and type:

One more small tip, if you want the folder name after cloning to another project name on the remote, put the folder name at the end of the command:

Normal days

One horse alone

Boss assigns a new feature, let’s start doing it. Wait, if you’re on another branch, don’t forget to checkout about the team’s main branch (usually the main branch will be named master):

Then pull the latest code to:

To check if the local code is updated, try checking with git log . I often use this command to view it neatly:

Then, checkout a new branch to start making your feature. This command will help you create a new branch and checkout there as well:

Code … code … code …

Done, now start adding the files you modified to the stage. Usually current IDEs support faster add and commit, but if you still want to type manually, type:

The command just now helped you to add all the files you just modified to the stage. Then commit:

Note: The way to name the branch and the commit should also be clear, showing that branch, what feature that commit does or what bug fixes. This completely depends on the rules of each team.

And finally push the code to the repository:

Now go to the repository, create merge requests for boss review. Meanwhile, we took advantage of making coffee cups to wait for the next step.

Feature many people do

If your branch has many people working together, you have not pushed the code in time, someone else has pushed first. So before push, please pull this way:

Your commit will be pushed onto a colleague’s commit in the log. In case you want to get the code but don’t want to merge, use the command:

In my opinion, pull = fetch + merge .

Merge code

After a review, the boss also agreed to let you merge the code, but the problem is that during the review process, you have a few more commits to add, edit, and delete files. You want to rebase those commits to 1, or simply want to rename or delete a commit. Let’s say you have 3 commits to merge:

The terminal shows you a lot of options such as edit, reword, squash … Replace the word pick at the beginning of the line with the corresponding option you want to use. Then press Ctrl + O to overwrite, continue Ctrl + X to exit.

Another problem was that the branch master had someone else pushed more code. You can still merge, but it will create an additional merge commit. So I usually rebase and merge fast forward. First, it’s still:

Then came the rebase command. You still have to stand at feature_branch to execute this command:

In a nutshell, the rebase command will help you get the latest code from the branch master, then “rewrite” your branch feature to push your commit to the top. Finally, push force to the feature branch. The push force will apply all of your local logs to the branch in the repo, regardless of logs in two different places:

If the branch is alone you can do push force. But consider carefully when pushing force on a branch that many people work with , as it will easily cause conflicts for others. Only do this when you are sure of completing your feature.

Then, merge the code at the merge request on the repo. So you have successfully completed the first task.

Crisis days


Actually, during the process, you may have something wrong that you need to revert code. Git reset will have 3 options for you.

Reset the commit but the code is still in stage, ready for you to re-commit:

Reset the commit and push the code out of the stage. You need to use git add before you can re-commit:

Reset the commit and delete all the code you did:


You can use this as a salvage to temporarily save the code before executing rebase commands or checking out to another branch that has a conflict. Currently I am using mainly Android Studio, and it has available Shelf with similar functionality so currently no longer use git stash.

You can see more here .


Actually, the title just headlines the view sentence only, nothing is standard at all. Since each company’s processes are different, project requirements are different. If your project has few people, it is necessary to prioritize the working speed, you can skip the process, push the code straight to the master. And if your project has many people working together, it requires a strict process, it may not allow push force to remote for example. So how’s your company process? Share with me.

Thanks for reading!

Share the news now

Source : Viblo