Git for your Team.

It is never too late.

Who should read this?
1. People who at least have an idea about git and its existence.
2. Someone who is trying to form a routine of versioning so that his team could follow.
3. Team who is fed up of their current ways.
4. I am an Android Developer :/

Fundamentals I understood about git.
1. There is no rule regarding how you organize your release, it is purely a team effort and understanding.
2. Release process must be transparent to everyone(transparent doesn’t mean accessible)
3. Using minimal tools one can achieve results.

Before solving file conflicts, solve team conflicts.

There might be people in your team some with ethics, some with earthy approaches and some who like to live on the edge. No matter what has been the past, its time to come to a common page.
This includes:

1. Naming Convention.
   There are standard ways to name a Class, Variable and Interface, it is better to follow those nomenclature. I will suggest some of the android names that I have been practicing these years.

Example

Feature- Showing list of friends
Activity: FriendsActivity
Fragment: FriendsFragment
Layout for Activity: activity_friends
Layout for Fragment: fragment_friends

view id: addressToLayout+_+type+purpose

Button on activity_friends: +id/actFriends_btnShowDetail
Button on fragment_friend: +id/fragFriends_btnShowDetail

2. Developer meetings:

It is important for developers to sit together and discuss their plans like “Naming Conventions” and more important is to keep a plan in front of others. Appreciate inputs from everybody and choose whatever is better. This encourages both seniors and juniors to actively participate to help build a team.

3. Using same versions of dependencies

Every machine must have same code, same jars, same gradle version and same api versions and same target and compile version. IDE specific files must be properly handled using git_ignore.

Git way- A never too late way.

This is my preference, tried and tested for small/medium projects. It is important to be easy to adapt.

Consider a new release 2.1.6 planned. So, it is mandatory to freeze features and updates. Let say F1, F2 and F3 are features that are going with this next update.
I am going to follow a pattern, let see how quickly that can be explained.

Branches that will be used:
1. develop_2.1.6(checked from master)
2. stable_2.1.6(created from develop_2.1.6 after all feature branch have been merged and tested)
3. master(branch with latest release+stable code)
4. f1_2.1.6(feature 1 branch)
5. f2_2.1.6
6.f3_2.1.6
7. [fixname]_2.1.6(any major bug fixed in separate branch eventually merged in develop/stable)

Illustration

In words.

Checkout from your current master/whatsoever is your release branch. Consider using master in future. Create a branch named develop_2.1.6.

Address features to team, assign responsibilities and bug fixes(if any). If feature is worth creating a branch, go ahead and create it. Further team members are free to create any number of local branches but make sure any pushed temporary branches on origin should be deleted to avoid any future confusion that could lead to a disaster.

Once a feature is approved and given sign off by QA, you can go ahead and merge into develop_2.1.6 and delete that feature branch too. In future, if any bug reported you still have chance to create a new branch to fix it.

Create any branch for bug fixing if it deserves. After fixing and merging, delete it. Don’t carry the baggage of branches.

Though we have version in our branch name, you will still be able to recognize recent vs old branches.

Once all decided features and bug fixes are merged, its time for your team-lead to review and create a stable_2.1.6 out of develop_2.1.6.

Stable_2.1.6 means no new features will be added further until release. However testing team will come with bugs that can be fixed and iteration for release candidate builds can be given to QA and release specific testing.

Once QA is happy with everything, last step before releasing is to merge into master. Tag this as Stable Release 2.1.6.

Go Live.

Start again:People will not stop growing their business. They will come again with some new proposed features. Lets start with creating a branch develop_2.1.7 from master.

Conclusion

I know there are projects much more complicated. People have different set of styles and rules. I suggest them to practice that locally. If this minimal practice along with healthy commit messages are used things will get better day by day.

I am incapable to judge anyone but I can appreciate if you have your way to achieve same result. I will be back with something better, this is not the end.