Main Git (Github, Gitlab) rules




I can't imagine the development process without Git. It's not only to store the source code, but to work and to live with it. If you can't use Git, you can't take part in modern development. It's not very difficult, may be it's even easy. But you should know some recommendations to avoid mistakes and to make your work more efficient.

How to name forks

You should give the names according to the task.

Use only digits and Latin letters in lowercase.

For short life branches the recommended format is “the number of the task”-the meaning of the task

For long-term you can call branches like ‘dev’.

You can also make the branch ‘production’ which is different from the main (master) branch, but is equal to production code.

What you should commit

You should commit one of these:

  • A completed task or a part of it
  • The result of the work during the sprint or after the working day

You don’t need to make commits every 5 minutes, only after completing a task or it’s part.

You also should add comments to describe what has been done.

There are some recommendation about commit comments. They are called ‘Conventional commits’ and you can read them at https://www.conventionalcommits.org/. It’s a special format for developers, QA engineers and software for analysis. There are some keywords to show the type of modification:

  • feat – new functionality, feature
  • fix – fixing a bug
  • docs – changes in documentation
  • perf – increase of performance

Of course, there are much more items.

If you follow these rules, the team work will be much more efficient.




No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment





MarkiMarta.com. Notes of web-specialist
Since 2009
18+