The concept of a changelog is simple enough: It’s a file that has a list of changes made to a project, usually in date order. The typical breakdown is to separate a list of versions, and then within each version, show:
Some teams will post changelogs as blog posts; others will create a CHANGELOG.md file in a GitHub repository.
tool called gitchangelog can do it automatically
another standard tool is github-changelog-generator
Trunk-based development is a logical extension of Centralized Workflow.
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the main branch.
This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase.
It also means the main branch should never contain broken code, which is a huge advantage for continuous integration environments.
The Forking Workflow is fundamentally different than the other workflows discussed in this tutorial.
Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository.
It means that each contributor has two Git repositories:
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the main branch.
The encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase.
It also means the main branch will never contain broken code, which is a huge advantage for continuous integration environments.
Encapsulating feature development also makes it possible to use pull requests, which are a way to start discussions around a branch.
They allow other developers to sign out on a feature before it gets integrated into the official project.
Or, if you get stuck in the middle of a feature, you can open a pull request asking for suggestions from your colleagues.
The point is, pull requests make it incredibly easy for your team to comment on each other’s work.
Also, feature branches can (and should) be pushed to the central repository.
It makes it possible to share a feature with other developers without touching any official code.
Since the main is the only “special” branch, storing several feature branches on the central repository doesn’t pose any problems.
It’s also a convenient way to back up everybody’s local commits.
Branching is a core concept in Git, and the entire branch flow is based upon it. There’s only one rule: anything in the main branch is always deployable.
Because of this, your new branch must be created off main when working on a feature or a fix.
Your branch name should be descriptive (for example, refactor-authentication, user-content-cache-key, make-retina-avatars) so that others can see what is being worked on.
Once your branch has been created, it’s time to start making changes. Whenever you add, edit, or delete a file, you’re making a commit and adding them to your branch.
This process of adding commits keeps track of your progress as you work on a feature branch.
Commits also create a transparent history of your work that others can follow to understand what you’ve done and why.
Each commit has an associated commit message, which explains why a particular change was made.
Furthermore, each commit is considered a separate unit of change. It lets you roll back changes if a bug is found or you decide to head in a different direction.