What is GIT?
GIT is an distributed version control system, a open-source project. We can use GIT for small project or big project.
How many type of version control system?
At this time, we have 2 major type of version control system. They are:
- Distributed Version Control System (DVCS), such as: Git, Mercurial, ..
- Centralized Version Control System (CVCS), such as: SVN, Perforce, ...
How does CVCS work?
- we have the central server. All the source-code of the team will be stored there.
- Each member of team will checkout the code directly from server.
- After modifying code on their local, developers need to push their changes directly into server code. Thus other member can see that changes.
How does DVCS work?
- All the source-code of team will be stored on central server (remote) as in CVCS.
- Developers need to checkout the code from this server if they wish working on.
- There is another version of GIT on their local. So developers will temporarily push their changes to this local git server.
- Developer can push all their local changes to remote in once if they want.
Which type of version control system (DVCS or CVCS) is becoming popular nowadays?
DVCS( GIT) was used by the most users around the world as many benefits was utilized by its user.
Could you tell me what are those benefits?
OK, DVCS or Git users can gain the following benefits:
- Each developer PC has its own local GIT server, SO they can share code together without commit that code to central server.
- The source code was pulled to their local PC. So they can modify the code and temporarily commit to local GIT without internet connection.
- After modify the code, they can commit to local GIT and push to remote once when the Tasks was completed. This makes sure that developer only pushes completed code to remote server (central server).
- Un-completed code will be temporarily committed to local git. Only completed code will be pushed to remote server, so developer rarely breaks others by committing mistake code (such as: un-buildable code, ...)
- Pulling/ pushing changes to local GIT, So it will be done faster
- We spent less time to solve conflict when merge local changes to remote server as we temporarily commit on local and only push to remote once the task was finished.
OK, I understand an overview about CVCS and DVCS, What can I learn more in this article?
In this article, We will learn how to use GIT with branching model and use it with source-tree.
So, What is branching model?
Branching model is a process define what we should do:
- when implementing new task?
- How did we fix a bug?
- How did we prepare for new release version?
- How did we do a hot-fix (bug on production)?
We use GIT as source code repository for our team, is there any workflow for using GIT that maximize the co-operate between member?
For using GIT, we have Git-flow process, it is useful for team co-operation.
This can help us avoiding a lot of mistakes related to development process
Where can I use GIT flow for my team?
In GIT flow, it specifies:
- How did we implement task?
- How did we fix a bug?
- How did we prepare for new release version?
- How did we do a hot fix (bug on production)?
What should I do before starting?
In branching model, we have "master" and "developer" branch. "master" branch is where we contain production code, "develop" branch contains code for development new features.
We also need to config this also.
In source-tree, click on "Git Flow" icon at the top-right and leave the setting as default. Click on "OK" button:
What should I do when implementing my new task?
When implement new task, we need to create new branch (called feature branch). You task will be implemented and committed into this branch.
When the tasks was finished and carefully checked, we will merge this feature branch into develop branch.
OK, How can I do it in source-tree?
I assume that your tasks is "Implement user login" and taskId is #01.
Click on "Git flow" toolbar item again and select "Start new Feature":
Input name of branch into "Feature Name" textbox in format:<task id> <task name>:
Note: Please do not change option in "Start At" as default.
In Preview region, We can understand that:
- The system will checkout the lasted code from development branch (develop branch).
- Then it will create new "feature/01_Implement_user_login" from development branch.
Click on OK, new feature branch will be created under "branches\feature".
When config the git-flow in source-tree, we leave it as default value for now. Can I change it to other-values if need?
Yes, you can change ti to what ever you want. As photo below, I change name of "feature branch prefix" to "custom-feature":
Can I change name of development branch and production branch?
Yes we can. But aware that production branch should be existing branch.
Can you tell me more on how to merge branch in GIT?
Merging from branch A into branch B. GIT will apply all changed of branch A into B. It is required that A is ancestor of B or they have the same ancestor.
For merging from branch A to branch B, Please following steps in order:
- Pull the lasted code in branch A from remote server to local.
- Pull the lasted code in branch B from remote server to local.
- Merge from B to A and resolve conflict if any. Then commit into local.
- Merge A to B and commit to remote.
When finishing my task, I should merge it into development branch (named develop) as mentioned in branching model. There is so many conflicts. Can we avoid this?
There are so many conflicts, it means there are so many differences between your branch and develop branch. There are some reasons as below:
- Your branch was created a long time ago.
- It is a long time, we did not merge new changes from develop branch into your feature branch.
- Your team can make a huge number of changes in short time.
Ok, What should I do if "My branch was created a long time ago"?
It is a long time you can not finish your task/ feature (so we can not delete your branch).
- It can be your task is too big. So it was required long time for implement that task. For this case, we need to consider break the tasks into smaller isolated tasks. So each task will be implemented in shorter of time and your feature branch will exist in shorter of time.
- It can be a big task and I can not break it into smaller task. For this case, We should merge from develop branch into your feature branch more frequently.
- It can be a considering feature waiting for client acceptance. It is ok for this case as it rarely occurs.
What should I do if "It is a long time, we did not merge new changes from develop branch into your feature branch"?
Normally, we should merge development branch (named develop) into your feature branch frequently. This will help your branch update new change made by other members in the team.
Merging from develop branch into your branch also help us using some other function/ feature implemented by others.
how many times should we merge or how long should we merge once. It is belong to the number of changes make by your team.
If you team can make many changes (those changes were pushed to develop branch) per days. I suggest that we should merge once on beginning of your working day, So your code is up-to-date everyday.
If you team makes a little changes or new code pushed to develop branch around 3 days in average. I suggest that we can merge from develop branch into your branch once for every 3 days.
You should know how to balance between the number of changes we apply to our feature branch on every merging from develop branch into your branch and how long it should be.
What should I do if "My team can make a huge number of changes in short time"?
As mentioned in previous question, We should know how to balance between the number of changes we apply to our feature branch on every merging from develop branch into your branch and how long it should be.
We can merge from develop branch in every 4 hours or in every 3 days.
If we merge in every short of time. Just a little change applied into your branch and it takes you a lot of time for merging between branch.
If we rarely merge from develop branch into our feature branch. it will be pain at the time we finish our tasks, as we need to merge our code into develop branch and there are so many conflicts need to be solved. Another problem, there may be some duplicated feature as we did not know that feature was already implemented by other member in team. This wastes time of our team.
Ok, it is a useful knowledge for me, Can you go ahead. What should I do for preparing the next release?
There are some problems the team facing as below:
- After period of development time, the team need to make new release to our customer.
- Normally, preparing new release to customer just needs some developer, not the whole team.
- For best utilize the resources of team, Other members will continue implementing new features/ tasks. This should not impact to members who preparing new release.
For solving those issue, In branching model has the Release branch concept. We can use in this case.
Can you tell me more detail on using "Release branch" to solve issue of my team?
Ok, from development branch (named develop), we create "release branch" (for example release 2.0, release 3.0, ...)
For members who working on preparing the new release will work on this new release branch.
Other members will continue their tasks as normally. Those members should not touch on development branch (named develop).
Ok, it is clear to me. Can you show me "how to do in source-tree"?
Select "Start new release" from the list of options:
In this window:
- We should leave default option in "Start at"
- Input the name for "Release Name". for example "2.0" in this case.
Look at "Preview" section. We understand that GIT will get the latest code and create new branch named "release/2.0".
So Developers who work on preparing new release will work on this branch.
Ok, We have new branch for preparing new release. What should I do when the release is ready?
When release is ready for real release. We will:
- Merge release branch into master.
- Create new tag for this release. Usually we should named the tag the same name as release branch. Such as: "2.0" in this case.
- Merge release branch into develop branch.
Why do I need to create new tag for new release?
Remember, Master is production branch. It contains production code.
When we have more than 1 release (such as release 1.0 and 2.0). We want to checkout the code in release 1.0. We will check out that code from tag named "1.0" as our convention.
Another, source of tag can not be changed. Checking out the code in tag 1.0. Surely, this is the code at the time that we release version 1.0 and can not be modified anyone.
With out tagging on new release, we can not get back that code in future.
Ok, I understand. Bu Why do we need to merge my release branch back to development branch (named develop)?
Release branch was created from develop branch and can be modified during preparing new release. Those changes need to merge back to develop branch.
So in future release, It includes improvements/ changes in previous release.
Ok, Please show me how to do it on source-tree?
In source-tree, click on "Git flow" and select "Finish release" option:
- We should currently on release branch that we want to finish or you can check again in "Current state" region.
- Just for sure you did not finish the wrong release.
Click on "Finish Release", We see the window as below:
In this window:
- Make sure "Release Name" is name of release you want to finish.
- We can check or uncheck Delete branch in "After finishing"
- Please do not check on "Force deletion".
- "Preview" explains that will be done if we click on "Ok"
Click on "Ok", We can see that there is new tag(named 2.0) was created and code in your release branch will be merged into master/ develop branch:
Ok, Now I have new release and deploy to my client production. Unlucky, they notify us a serious issue need to be fixed as soon as possible, What should I do in this case?
In branching model, we need to create a hotfix branch from master branch. The issue will be fixed there and merge back to develop and master branch.
The bug is on master branch and on production server, Why do I need to merge back to develop branch?
Currently, the production has that issue. It means that code in your develop code also has that issue.
Future release will also have this issue if the hotfix was not merged back to develop branch.
For more information, Please have a look my slide at http://www.slideshare.net/TuTran10/fullstack-requiste-git-sourcetree
CodeProjectThank for reading.
Note: Please like and share to your friends if you think this is use full article, I really appreciate