Introduction
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.
Procedure
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:
1 2 | git clone <url> |
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:
1 2 | git clone <url> folder_name |
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):
1 2 | git checkout master |
Then pull the latest code to:
1 2 | git pull |
To check if the local code is updated, try checking with git log . I often use this command to view it neatly:
1 2 | git log --oneline |
Then, checkout a new branch to start making your feature. This command will help you create a new branch and checkout there as well:
1 2 | git checkout -b feature_branch |
…
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:
1 2 | git add . |
The command just now helped you to add all the files you just modified to the stage. Then commit:
1 2 | git commit -m "Fix all bugs" |
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:
1 2 | git push origin feature_branch |
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:
1 2 | git pull --rebase |
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:
1 2 | git fetch |
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:
1 2 | git rebase -i HEAD~3 |
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:
1 2 | git fetch |
Then came the rebase command. You still have to stand at feature_branch to execute this command:
1 2 | git rebase origin/master |
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:
1 2 | git push -f origin feature_branch |
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
Reset
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:
1 2 | git reset --soft commit_id |
Reset the commit and push the code out of the stage. You need to use git add before you can re-commit:
1 2 | git reset --mixed commit_id |
Reset the commit and delete all the code you did:
1 2 | git reset --hard commit_id |
Stash
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 .
Conclusion
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!