0

I am new to git (and GitHub) and saw that a lot of bugs (on GitHub) get fixed by cloning a repository and the clones only exist temporarily for the lifetime of the fix and get closed and deleted afterwards.

How does that technique apply for big projects where compiling times might take hours? One approach in Perforce for instance is to have a main branch and a seperate branch that coexists where individual bugfixes get integrated from. Is that a technique also used with git / GitHub? It doesn't seem wrong but I am not sure which other techniques and approaches exist which I didn't think of.

Daniel Stephens
  • 2,371
  • 8
  • 34
  • 86

2 Answers2

3

get fixed by cloning a repository and the clones only exist temporarily for the lifetime of the fix and get closed and deleted afterwards.

Closed and deleted because the PullRequest branch gets merge into the original repo (upstream) master branch.

Since those are source code with their history now merged, there is no readon to keep the fix branch around in the fork.

I fork my branch, compile my project, fix the bug, integrate it to the main branch and clone my branch for this bug

You don't need to "fork your branch": just create and checkout a local branch, push it to your repo, and you can make a pull request to master for others to review.
If you are the only one working on that repo, you don't even need all that: create the local branch, fix the bug and once you have tested it works, merge to master and push.

With only one clone, you can checkout multiple branches in different folders, with git worktree.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • But if I do this forking/closing for every bug, this would require a recompilation locally, no? – Daniel Stephens Jul 10 '18 at 05:09
  • @DanielStephens the recompilation can be done by a CI/CD tool like Travis-CI. Or on the local clone of the one fixing the bug. But GitHub itself only store the sources, without worrying about compilation. – VonC Jul 10 '18 at 05:20
  • Thanks for your answer! Yes, Github stores only the sources, but forking in Perforce for instance would mean a 2nd copy of the branch locally on your machine - so twice the amount of space locally. If I would apply the forking technique to Perforce that would mean n-bugs would mean n-times the amount of space of my actual branch locally – Daniel Stephens Jul 10 '18 at 05:24
  • If you're working within your own local repo, you won't duplicate space, merely update the current workspace. – VonC Jul 10 '18 at 05:38
1

When you create a public repo on Github, others can view/download it but they can't contribute to it. People typically fork when you're coping an open source repo. This gives you an isolated environment with privileges to write and make branches. You branch to fix a bug (typically). You can just fix on master but when working in a team this becomes problematic. You may need a series of commits to fix a problem, leaving master branch in a broken state. To avoid this bugs or features are fixed/built on branch of master until they're in a healthy state to be merged.

The internals of GIT don't create full copies of the project for each branch (they do for a fork). A branch only tracks the diff of lines that changed. If your code size is 1MB and you branch 5 times with no changes it'll still be 1MB. Linus Torvalds did some voodoo with graph theory to make this happen when he made GIT.

It's complicated to summarise the whole process. The github docs are pretty awesome for learning git concepts https://try.github.io/

Lex
  • 4,749
  • 3
  • 45
  • 66
  • Thanks for this great explanation! I understand why branching takes only the same amount of disk space on the server*. But I am talking about branching to your local machine. What if I want to fix 2 separate bugs? So I branch the master twice and download both branches to my local machine, correct? So locally I have two copies which take 5MB for the first one, and 5MB for the second branch, correct (+ 5MB maybe for the master if I keep this local too)? – Daniel Stephens Jul 11 '18 at 01:59
  • @DanielStephens well you wouldn't fork it twice (once for each bug), that wouldn't serve much purpose. You'd fork it once and branch as meany times as you'd need to. In your example with branch master/bug1/bug2 you'd still only use 5MB of space. Branches would also be made locally; When you're happy with it, want to share it or back it up you'd `git push` to remote (Github). If you forked master/bug1/bug2 you're right you'd end up with 15MB of space used, although possible isn't an ideal way of working. – Lex Jul 11 '18 at 02:24
  • Thanks! Your answer with your latest comment is what I was looking for. I also found `git-worktree` which seems to help me here. If I switch back and forth during the day between forks I can't recompile them all the time since it takes hours, so I have to keep the forks separate – Daniel Stephens Jul 11 '18 at 03:07