CODEWITHSUNDEEP
gitgit-flow
Christopher Regner
Christopher Regner

Reputation: 596

How should your project's very first commits/branches look like in git flow

Almost all instruction and examples I was able to search about workflow says that I should start with a feature branch. But this isn't clear to me if it is applicable in the earliest stages of a project, leaving me with questions like:

Upvotes: 0

Views: 1011

Answers (2)

Ang
Ang

Reputation: 111

I think you are confusing the name "feature branch" with the actual feature of your app.

A feature branch is used only when someone wants to develop some new feature and wants his/her codebase to be insulated from everyone else's changes. He/she creates a feature branch, works on it for a couple of days, and merges it back to master once the feature is completed (at which point the feature branch is usually deleted). The "master branch" contains all features of the app. In fact, all branches contain a copy of all code of the app. Branching is just an isolation mechanism, so people don't step on each other's toe.

In your case, if you are working on a MVP, the whole thing should go to your master branch.

Upvotes: 0

ashmaroli
ashmaroli

Reputation: 5434

By default, a git repository starts with an active master branch. When you run git status you'll get a message that includes Initial Commit

The very first commit can include a single file at minimum to the entire viable codebase. But its better to start small and then expand with small meaningful commits.

e.g: Let the very first file add be simply a README.md containing basic info about the project. Add the file to the index with git add and commit with message Initial Commit or whatever you want.

If its a Ruby project, the next commit can establish a lib/ directory and foundation for its contents. The third commit can introduce some shell scripts that aid during development, etc.

A branch comes to the picture, much later, when working on a particular micro-feature. You can add all sorts of commits to this branch, or delete unnecessary ones and finally merge to the main master when work on the feature is complete. This ensures that the history of your master branch is a lot cleaner.

Upvotes: 1

Related Questions