CODEWITHSUNDEEP
gitgit-branch
Utkarsh Srivastav
Utkarsh Srivastav

Reputation: 3227

Git branch vs Git fork

I have a general doubt. Suppose there is a git repo with master branch as development branch and you want to make some changes without effecting master branch and then you want to merge it later. What is the better approach?

  1. Create new branch in same repo and then merge it to master.
  2. Create new repo by forking and then merge it to master.

Upvotes: 2

Views: 5241

Answers (4)

Ganesa Vijayakumar
Ganesa Vijayakumar

Reputation: 2602

Forks can be a really good pattern for ‘public’ collaboration and experimentation, but when the intended use case is many people working toward a unified goal, branching tends to be a better fit

Hence

Choose option #1) branch - if you are working together in a team and developing software.

Choose option #2) fork - if you are going to contribute to any open-source projects.

Upvotes: 1

ARUN KUMAR
ARUN KUMAR

Reputation: 46

I would suggest the below strategic.

  1. Master -->Production deployed one and source of all:

  2. develop -->Always in-sync with Master

    • feature/Branch.
      • Multiple developer branches with base of feature/Branch.
        • Raise PR to feature/Branch.
      • Once done a feature developments & testing on the feature/Branch, create PR to develop branch for UAT/SIT testings.
    • BugFix/Branch.

  3. develop/Fork-->This branch should always in-sync with develop. You can enable this by mark the "Enable force sync" on Bitbucket Server.

    • production bugfix/Branch.
      • Once bug fix was done Raise PR to develop/Fork branch.
      • deploy develop/Fork branch into UAT/SIT.
      • Then raise PR to develop to merge bugfix changes.

Upvotes: 0

liamnickell
liamnickell

Reputation: 166

If you know for sure that you will end up merging with the master branch eventually and/or your change is relatively small (bug fixes, new features), then definitely make a new branch. Only make a fork if you are going to make vast changes that could potentially become a new project in itself. That's the rule of thumb that I follow (as it follows the basic project design meta of git), so I hope that helps.

Upvotes: 5

L. Sturtevant
L. Sturtevant

Reputation: 106

I would strongly suggest to create a new branch in the same repository. You do your work in this new branch until the new feature is complete. When it's finally complete, merge it back into master. This follows the design of git.

There really is no forking in it. There are only clones of the original. The more clones you create, the more complicated things become and the more work you have to do with pull requests to get the changes back into the original repository.

Upvotes: 3

Related Questions