Menu
Which one takes more disk space? How do you track bug fixes(we are using Jira)? How do you know which branch or repository has the bug fix? there must be other advantages/disadvantages to repository vs branch?
612
In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes.
You should branch whenever you cannot pursue and record two development efforts in one branch. (without having an horribly complicated history to maintain). A branch can be useful even if you are the only one working on the source code, or if you are many.
You should create a new branch when you're doing development work that is somewhat experimental in nature. So in your scenario definitely create a new branch and not a folder within master. If you created your sandbox work as a directory in the master, it's going to reside there until you remove it using git.
Branches allow you to develop features, fix bugs, or safely experiment with new ideas in a contained area of your repository. You always create a branch from an existing branch. Typically, you might create a new branch from the default branch of your repository.
Your question doesn't make a whole lot of sense. Repositories always contain at least one branch, and you can't have a branch without a repository. So of course, a branch is smaller than a repository. The two aren't really comparable things.
So, let's talk for a moment about what a Git repository actually contains. There are a few main things:
work tree - this is the current state of all your files, the ones you're working on. This can take up a decent amount of space.
objects - these are the internal way git stores things - blobs to represent the contents of files, trees to represent directory structure, commits to represent snapshots of the work tree. This is the other thing that really takes space.
refs - short for references: branches or tags. These are very, very lightweight - they're just pointers to particular commits. They do take up a little space, but it's so little that you should think of them as completely free. Tags are fixed references; they point to one commit forever, and are used for things like marking versions. Branches are movable references; with one checked out, it advances forward as you commit. They're what you'll use to represent lines of development - a stable branch, a branch for a particular bugfix or feature, you name it.
There are other things inside the .git directory besides objects and refs, but don't concern yourself much with them now.
How do you track bug fixes(we are using Jira)? How do you know which branch or repository has the bug fix?
This is kind of up to you. Generally people end up embedding some information in their commit messages to indicate that they address some particular bug/issue. You should probably have a defined workflow, where you make your bugfixes on their own branches (or perhaps a maintenance branch on top of a previous release), and merge them into your current development branch, thereby sharing the bugfixes with the future version. You should be able to say something like "the master and maintenance branches always have all the bug fixes" - though if you want to check, you can do something like git log --grep='bug 1234', assuming you've put that string in your commit message!
In general, there's no need to have multiple clones of the same project's repository. You'll probably have a central one, and each developer will have their own - but when a developer publishes their work, they'll be putting it in the central one, and that's where everything important should be.
71
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
