2

I have used git a few times and it has always been a painful experience. However i noticed that bitbucket host private repos for free if less then 5 users and I liked the idea of my source code being secured away from my office.

So I have created a new private repo on bitbucket and because I'm the owner and the only developer and I own the repo I can just make changes locally and then commit and push to my repo (there are no forks) without the added complication of pull requests to the owners repo.

I also realized that I hadn't created a branch and there was no need to, I was just working on my local master branch and committing and pushing to my my master branch, and i could continue this cycle without doing anything else.

So really is there any problem using git like this without using branches.

Paul Taylor
  • 13,411
  • 42
  • 184
  • 351
  • No problem. It's like using SVN without tags or branches. It would be good to use the power of the tool, however, and learn how branches can help you – Brian Agnew Jun 03 '14 at 15:57
  • I come from SVN background, and in SVN I tag releases, and would occasionally use branches but very rarely, but it seems with git the idea is to use a new branch for every single issue which doesn't appeal. – Paul Taylor Jun 03 '14 at 16:05
  • 1
    It's important to realise that branching in git is far faster than in SVN. As such, you can use branching much more readily, and it results in a very different workflow between the two tools. – Brian Agnew Jun 03 '14 at 16:07
  • Git is OK, if you use git you are OK ;) – Arnaldo Ignacio Gaspar Véjar Jun 03 '14 at 16:27
  • Ithink its a valid question, there is alot of stuff talked about how great git branches are as if they are the way git must be used but as the discussion below shows this is not necessarily the case. – Paul Taylor Jun 04 '14 at 16:36

2 Answers2

2

First, you will always use a branch (here, by default, master)

Second, for a simple development workflow like yours, you don't need any additional branches.

But should you want to isolate a development effort in a new branch, that would be as easy as:

git checkout -b newBranch
git add .
git commit -m "New branch"
git push -u origin newBranch # for the first push only

Creating a new branch is just adding a pointer to the current commit: it is a 40 bytes in a file (.git/refs/heads/newBranch, with the SHA1 of the HEAD commit)

For more on branching:

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • My problem was I found that if I was working on three issues it didnt help me to create three separate branches and have to swap between them all the time, also had problems getting my branch changes into my master branch, and keeping my master branch synced with the master branch of the original repo that I forked from. – Paul Taylor Jun 03 '14 at 17:04
  • @PaulTaylor I understand. For the update part, I already explained it with the git rebase in my previous answer http://stackoverflow.com/a/3903835/6309 (that I mentioned in your previous question http://stackoverflow.com/q/24004110/6309 – VonC Jun 03 '14 at 19:22
  • @PaulTaylor as for making 1 or 3 branches, this is really about the original repo maintainer and how he or she will have to apply those PRs. If they can be applied independently one from another, those issues should be fixed in three separate branches and made as 3 PRs. If not, one branch is enough. – VonC Jun 03 '14 at 19:23
  • @PaulTaylor this is mostly a way to keep the impacted code base surface *small* in order to be able to easily spot regressions. For instance, a `git bisect` better be pointing at a small commit rather than one giant commit with a lot of fixes in it. – VonC Jun 03 '14 at 19:25
  • but within one branch (master) I can do multiple commits I dont need to do one giant commit – Paul Taylor Jun 04 '14 at 06:43
  • @PaulTaylor sure but 1/ if you want to do a PR from those commits, don't do them in a branch which can evolve in the original repo as well: isolate those in a separate branch. 2/ a PR is supposed to be applied all at once. If for any reason the main maintainer of the original repo wants to apply one and not the others, then separate branches and separate PRs are best. But absolutely, you can make multiple commits in one branch for one PR. I have done so in the past (here: https://github.com/hakimel/reveal.js/pull/640, 14 commits!) – VonC Jun 04 '14 at 06:51
  • okay I get it, using branches in that way give you the ultimate flexibility but at a cost of more complexity, administrative. For me I dont need that flexibility and I dont want the extra complexity. Very very rarely have I needed to regress a commit in SVN, but I can see useful for more complex projects with many developers. – Paul Taylor Jun 04 '14 at 08:51
  • @PaulTaylor I agree. Sorry for the "put on hold" status (I voted to reopen): this is certainly a question that can benefit from "specific expertise" (namely mine). – VonC Jun 04 '14 at 08:56
  • @PaulTaylor note: I have found the recent presentation (May 2014) from Tower quite useful: http://fr.slideshare.net/gittower/understanding-branchingmerging-learngit. Of course, regarding the nitty-gritty of branch administration, nothing beats http://pcottle.github.io/learnGitBranching/. – VonC Jun 04 '14 at 21:02
-2

It is absolutely fine - just use fork instead of cloning. Branching has the terrible side effect of changing your file system underneath your feet - this is a weakness in the design of git that will no doubt bring great wealth to the person who fixes it.

aaaaa
  • 1
  • 1
    "Branching has the terrible side effect of changing your file system underneath your feet"—as opposed to all other software that never modifies the filesystem? How exactly do you justify calling this a "weakness in the design of git"? – ChrisGPT was on strike Apr 15 '22 at 22:06