Let's look at examples
A little theory for understanding
Git is a distributed version control system that consists of many commands that allow you to effectively work with the history of changes in a project. However, among other things, Git helps track the history of file and directory creation, which makes the development process more transparent and convenient.
The story of Git's creation began in 2005, when developer Linus Torvalds encountered problems using other version control systems to manage the Linux kernel source code. He decided to create his own system that would be fast, easy to use, and able to handle very large projects efficiently.
Thus, in 2005, Git was released and became a widely used version control system, allowing developers to work efficiently on projects of any size. Over time, Git has become the standard source code management tool for many projects and companies around the world.
Some benefits of using Git
Change Management: Git allows you to create a change history that helps you track changes in your code.
Distributed system: Git can be used on multiple servers, ensuring high availability and security.
Multi-user access: Git allows multiple users to work on the same project at the same time.
But today I want to talk not so much about Git itself, but about one of its standards – Gitflow.
And if Git is a version control system that allows you to track changes in your code, create branches for development, and merge them, then Gitflow is a branching model based on Git that defines best practices for working with branches. It suggests using the main master and develop branches, as well as creating separate branches for developing new features, fixing bugs, and releasing versions.
A short summary to move on
So, we have understood that:
Git is a version control tool.
Gitflow is a branching model that helps organize the development and version control process in a project.
Git is a technology.
Gitflow is a methodology or, if you like, rules for using this technology.
Gitflow is very helpful in team development, when several people work on a project. Colleagues can work on several features at the same time, without interfering with each other. The branching structure of Gitflow helps a lot with this.
.gitignore without ignoring: creating a project and diving into the details
To make things easier to understand, let's create a project, for example, on Spring Boot, and use a Git repository for storing code and teamwork on https://gitverse.ru/.You can also use https://bitbucket.org/, https://github.com/ etc., the differences in operation are minimal.
So, let's say we have some empty hypothetical project that we plan to develop as a team. To do this, we need to place it in a common repository in one of the Git services presented above.
To do this, be sure to create a project in one of the services presented above and add your colleagues to it.
To begin with, I suggest creating and configuring a .gitignore file within the project.
.gitignore is a file that tells Git which files or directories to ignore when committing changes to the repository.
The .gitignore file contains a list of patterns of files and directories that should not be included in the repository. This allows you to track only changes to files that are truly important to your project.
Example of .gitignore file:
# игнорировать все файлы с расширением .log
*.log
# игнорировать директорию node_modules
node_modules/
# игнорировать файл config.json
config.json
# игнорировать все файлы в директории tmp
tmp/In this example, Git will ignore all files with the .log extension, the node_modules directory, the config.json file, and all files in the tmp directory.
You can add patterns to the .gitignore file for each repository to specify which files or directories should not be included in the repository.
An example of a .gitignore file used in a project:
HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/
### VS Code ###
.vscode/Now we need to initialize the project. This can be done with the git init command. This command is one of the main Git commands that creates a new Git repository.
When you run the git init command, Git creates a new .git folder in the current directory that contains information about the repository. It stores the revision history, branch information, and other data needed to manage the repository.
The git init command also creates several additional files and directories:
.gitignore is the file we created above. It contains a list of file and directory patterns that should not be included in the repository.
.git/objects is a directory that stores Git objects such as commits, trees, and other data.
.git/ref is a directory that stores references to commits and branches.
When you run the git init command, Git creates a new repository in the current directory. This means that all files and changes in that directory will be tracked by Git.
So, we have created a new repository in this directory.
We record the changes
To do this, we need to run the git add and git commit commands.
The git add command is used to add changes to the index (or staging area) before they are committed using the git commit command, which we'll cover next. This allows you to select specific changes that you want to include in your next commit, as well as preview your changes before committing. This helps you prepare your commit more thoroughly and avoid including unnecessary changes.
Let's run the bash command
$ git add
With this command, ms added all the changes that were in our folder to the staging area. The “.” symbol tells Git that it needs to add all the changes. The same effect can be achieved with the command git add -A.
If you need to add some specific files, you can do this by adding the file name or path to the file instead of the dot. For example:
$ git add FileName.class
$ git add /service/ServiceName.class
The git commit command is used to commit changes to a Git repository. Once you have made changes to your working directory and added them to the index using the git add command, you can use the git commit command to save those changes to your local repository.
To run the git commit command, you must specify a commit message, which must be detailed and describe the essence of the changes made. Let's call our first commit first commit. To do this, run the command:
git commit -m "first commit"
After running the git commit command, your changes will be saved to your local repository and will receive a unique commit ID. It is important to remember that commits in Git are immutable, so it is important to make all necessary changes before committing.
Now, to make our code available to the entire team, we need to upload it to a remote Git repository. To do this, simply run the following commands:
$ git remote add origin [НАЗВАНИЕ РЕПОЗИТОРИЯ, например ssh://git@gitverse.ru:2222/[NAMESPACE]/[PROJECT_NAME].git]
$ git branch -M master
$ git push -u origin master
These commands are described in all the services presented above when creating a new project in them.
As you can see, the main branch is called master, but you can give it any other name.
Master branch: what is it and why
The master branch is the main branch in Git that contains the latest stable version of the project. It is the starting point for most developers and typically contains code that is ready to be released.
The master branch plays an important role in Gitflow because it ensures the stability and reliability of the project. It should not contain changes that may affect the functionality and security of the project.
What is the purpose of using the master branch?
Storing the latest stable version of the project.
Branch for the release of finished products.
The starting point for most developers.
The master branch can also be used to store historical versions of a project that are no longer maintained. This allows access to older versions of the code and helps track changes made to the project over time.
After uploading the code to the repository, we will get the following image in the IDEA IDE:
And this is how it looks in a web browser when using one of the repositories presented above (the screenshot shows https://gitverse.ru/):
So, we have a repository and the first master branch, where we have uploaded the code. Be sure to add your colleagues to one of the services you have chosen so that they also have access to the code and the ability to make changes to it. As a result, we have a remote repository and the ability to make changes to it not only ourselves, but also your entire team.
In the next article, we'll look at the branching model and see how you can work on the same code without interfering with each other.
