You are preparing for an interview for a job where a requirement is "knowledge of branching strategies." What could you discuss to assure them that you have knowledge of branching strategies?
Code versioning systems can be referred to as SCMs (Source Control Managers) or VCSes (Version Control Systems). Some companies have big development teams whereas others have small teams. The internal dynamics may dictate whether or not you will create a branch of a source code repository or not. Professionally we advise you to be the flexible type of person who can work according to how the company tells you. If your professional position will determine the branching strategy, now in 2019, there are two basic options for the sake of simplicity. (There are more options than these. In 2015 jobs did list "knowledge of branching strategies" back then too.)
One option is "trunk-based development." This option is not having a second branch. The DevOps Handbook cites Gary Gruver (on pages 144 and 145), and his success with not having another branch. Trunk-based development is the lack of a second branch. Forking a repository is creating a second repository; it is like cloning one but "fork" connotes the publication of an independent copy of a repository. A branch is an independent copy of a repository within a repository for the purpose of possibly merging it with the trunk. To develop in a mainline way is another phrase that describes trunk-based development. It can be worthwhile to forgo a branch for a single-source of truth. It can deter developers from committing code without a significant amount of work. They may do more testing before they commit their code. This strategy may be accepted by the business if there is little to no need for an approval process; some development projects lend themselves to this. Code versioning systems by their very nature preserve archived versions, thus trunk-based development may work for numerous businesses. It is ideal for small teams.
Trunk-based development is ideal for Terraform. An O'Reilly publication on Terraform says "…for any shared environment (e.g., Stage, Prod), always deploy from a single branch." (Taken from page 304 of Terraform: Up & Running, 2nd Edition by Yevgeniy Brikman (O'Reily), Copyright 2019, 978-1-492-04690-5.) To learn more about trunk-based development, you may want to read these links:
A second option (of branching strategies) is to have branches. A branch to a repository can be ideal in a large team with a new developer. A new developer can aggressively refactor code to correct a bug or add a new feature. Before all the parameter files and source code are merged (and thus overwrite) the existing files, he/she can create a pull request. This is a request which will enable another person (e.g., a more tenured employee who knows the businesses coding conventions and idiosyncrasies) to approve the merge of code manually. A branch dedicated to the development of a specific feature can prevail in a merge to the main if the pull request is approved (e.g., by at least one other person besides the developer). Pull request approval requirements vary from group-to-group. Companies with high turnover and large numbers of developers may prefer to have branches [of individual repositories]. Code repositories have archived versions of the code. Thus some companies find a formal code branch merging approval process tedious. The DevOps Handbook extolls the benefits of having a single code repository as opposed to two or more.
One common way to have branches is to use Git Flow. Git Flow is more commonly used than trunk-based development. Git Flow is a strategy where you have five different branches (according to this external site): main, develop, feature, release and hotfix. Some of the non-main branches will receive merges from the main branch with the main branch's changes prevailing. That is, the Git administrator will merge changes from the main branch to a given feature branch. This way your organization can keep working on a feature, and this non-main feature branch can receive updates such as critical hotfixes. Git Flow is considered a set of guidelines (rather than firm rules), according to this video. You can read more about the details here.
The benefits of having a shared single source of truth are many (and described in detail in The DevOps Handbook on pages 290 through 292). To generalize the benefits of an accessible repository that numerous professionals can work on, we can see how "trunk-based development" has its place (without extra branches which can be confusing for parallel development of code). A code commit to a repository could be the impetus for the CI/CD process. With automated testing, the promotion of the code to higher environments will happen safely. You can have more testing, in theory, with trunk-based development.
Having branches can be an alternative that can be an efficient way for programmers to collaborate. A developer can merge code changes to a number of different files with an approved pull request. The submission of a pull request will send a notification that a request for approval of the code changes has been made. The approver will see the changes via the diffs. This can be an efficient way to collaborate with clear ownership of code before it is integrated.
The DevOps Handbook (page 186) cites Paul Hammant who gives mixed treatment toward trunk-based development. Paul Hammant, depending on the circumstances, can recommend "branching by abstraction" (a term he coined) which can facilitate a hybrid approach to development (a mix of trunk-based development with branches to source code repositories) (page 186 of The DevOps Handbook). Different branching strategies have their place depending on the environment, the team size, the goals, and how formal the approval process is.
To learn more about Git branching strategies, read these articles:
This git command "git bisect" is relevant to reconciling different branches:
To view a list of Git books, see this page.