You can not write a code without some version control system. Today we will talk about git. It is very common and well documented system. However the fact that we use the git does not mean that we use it in a proper way. Like with everything there are some good practice to be fallowed which will help us maintain better change history. When you maintain a good change history you can undo changes in very easy way.

Git good practice roles:

Only combine changes of a same topic in a single git commit

If you make multiple changes across your project you can add individual files or even the part of your files to a specific commit.

# file level
git add nameofafile1

# patch level
git add -p nameofafile2

Name git commit -m messages appropriate

Subject should represent a very short overview of what happened

Body section should be use to create more descriptive and detail list of wat was changed (what is now different then before).

The body should also contain information such about

What was the reason behind this change.

And additional information on is there anything particular to watch out for.

Git branches strategis

Use clean conventions. Git allow you to create branches but it does not tell you how to use it. A git branch documentation can help your team to avoided collisions. There are many methodologies and not all will fit your needs.

Always be Integrating

This is almost never used in large teams or on large project.

— keep few branches

— make relatively small commits

State, Release/Development and Feature branches

In the above branching methodology there are two types of branches. Long-runnign and Short-Lived branches.

Another Popular branchiest strategies are GitHub Flow and Git Flow

GitHub Flow branching strategies

A very clean, intuitive and simple branching strategy. Which is very handy when developing a code as one person.

GitFlow – branching strategy

Which branch model should I choice?

It is not clear which branching model will be better for your use case. You need to experiment and see which approach is cleaner and more intuitive for your team. If you need extra testing layer you probably should consider to add a long-running branch for testing. The strategy that you choice need fulfil your project individual requirements. If you not sure give a try to each approach. And most important don’t be afraid to modify those to your needs.

Slides comes from https://www.youtube.com/watch?v=Uszj_k0DGsg

0
Would love your thoughts, please comment.x
()
x