CODEWITHSUNDEEP
gitgithubbitbucket
ngplayground
ngplayground

Reputation: 21667

Git Version Control and Branching

This isn't a code question, more of a 'best practices' question.

I'm using GitHub and BitBucket, when you have the master that will be your live working code.

To build upon or fix bugs, is it best to create a branch?

When that branch is ready to merge would it be best to merge and then delete that branch?

If you merge, how do you keep note in the master of what branch that master was pushed from?

Thanks in advance

Upvotes: 1

Views: 79

Answers (3)

Ignorant
Ignorant

Reputation: 2691

IMO:

To build upon or fix bugs, is it best to create a branch?

Yes, create a branch for each bugfix, upgrade or modification. Examples: master_bugfixing, mybranch_new_feature and so on.

edit: why I think it's a good idea to create a branch - quotes from Visualized Git practices for team: branch, merge, rebase -

  • You are about to make a major or disruptive change
  • You are about to make some changes that might not be used
  • You want to experiment on something that you are not sure it will work
  • When you are told to branch out, others might have something they need to do in master

When that branch is ready to merge would it be best to merge and then delete that branch?

I always delete unused branches, i.e. branches already merged.

If you merge, how do you keep note in the master of what branch that master was pushed from?

You could add a message during merge with git merge -m <msg>.

A hint for a branching model: A successful Git branching model

Upvotes: 1

Pedro Nascimento
Pedro Nascimento

Reputation: 13926

You could follow either Github Flow or git flow. I use a mix between both, but both are great depending on how you work.

For Github Flow, you would do:

  • Keep master always deployable;
  • Create a new branch to fix your bug with a descriptive name;
  • Only work on that branch;
  • Open a Pull Request with your changes;
  • Merge it to master.

For git flow, you would do something like:

  • Keep master mirroring your production environment;
  • Have a develop branch for non-deployed but ready things;
  • Tag your release, provided you have your changes to be released in develop:
    • git checkout -b release-1.2 develop
    • git checkout master
    • git merge --no-ff release-1.2
    • git tag -a 1.2

Then deploy master.

For git flow, when you are working on a hotfix, you would commit your fixes on a separate branch before tagging the new release, and merge changes back:

  • git checkout -b hotfix-1.2.1 master;
  • Commit your fix;
  • git checkout master
  • git merge --no-ff hotfix-1.2.1
  • git tag -a 1.2.1
  • git checkout develop
  • git merge --no-ff hotfix-1.2.1

You would also deploy master.

Upvotes: 2

nawazlj
nawazlj

Reputation: 821

To build upon or fix bugs, is it best to create a branch?

yes, it's the best practice to create a separate branch in order to build or fix your bugs.

When that branch is ready to merge would it be best to merge and then delete that branch?

It depends your type of project, however there's no problem in deleting branches that have been merged in. All the commits are still available in the history.

If you merge, how do you keep note in the master of what branch that master was pushed from?

Again commits history is saved in Git, so we can keep track of which branch is mereged with Master branch.

Hope you got enough clarification on your queries.

For more information, refer git-scm

Thank you.

Upvotes: 1

Related Questions