.gitignore file tells Git which files in your project should be ignored. It is usually (most often) located in the root directory of your project. A file content example for .Net Core project can be found here. Be aware that adding a certain path to .gitignore will have no effect if the file is already being tracked by Git. In this case, you can remove the file and then update the .gitignore file.
GitFlow is a branching model for Git which we use here at Infinum. Its main advantage is that it supports projects where deployments are made often. Since we use agile workflow, this goes hand in hand with it. We will cover some of the things about the GitFlow in this handbook, but you can find a broader explanation here.
This image shows the git flow branches diagram:
Master branch should only contain a release-ready code and is one of the two branches we are releasing the code from.
Develop branch is the second branch which we release code from (for the development environment). It should only contain the code which is ready to be part of the next release. When it is decided that a new release build should be done a release branch is created from the develop branch. After a successful deployment, we merge the release branch into master and back into develop.
Each new feature needs to be implemented in a separate branch. This is always branched off from the develop branch and then merged back into it. Feature branches also have a naming convention we should follow: feature/feature-name. If the project is using a feature tracking system, then it is necessary to put the ticket identifier into the name as well: feature/T-1234-feature-name.
If we recognize a bug or important change request that needs to be resolved on production as soon as possible, we can create a hotfix branch. Hotfix is branched off the master branched and then merged back into master and develop branches. We use a standard hotfix naming convention which is similar to the feature one: hotfix/T-3456-name.