CODEWITHSUNDEEP
gitgithub
Christoffer Reijer
Christoffer Reijer

Reputation: 1995

Best practice for structuring git branches

Ok, so I am starting to get really confused about my mess of git branches. Some background: I have my main, official repo at simplare/stoffi-web and my personal fork over at ephracis/stoffi-web. I usually do a feature branch, work on it, do a pull request back to simplare and then merge it into my own fork.

I usually use both the command line and the app Github for Windows/Mac. I clone and commit in the apps, while I do stuff like rebase and handle submodules in the command line.

First question: is this good practice or should I merge the feature branch into my personal fork before doing a PR?

Next, I have gotten into a bit of a mess. I get this message:

$ git merge simplare/master
warning: refname 'simplare/master' is ambiguous.
Already up-to-date.

$ git branch -a
* master
  simplare/master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/simplare/master

Second question: how do I clean this up?

Third question: should simplare/master be a "normal" branch or a remote branch? I believe that's why I am getting the ambiguous warning, because I currently have both.

Upvotes: 0

Views: 74

Answers (2)

locoboy
locoboy

Reputation: 38900

Question 1:

The process should be:

  1. create a feature branch on origin
  2. make a PR into simplare with that feature branch
  3. once simplare merges your feature, pull down onto your origin master

Reason to not merge your feature branch into origin before making a PR into simplare is that your PR could get rejected and your origin will have the wrong code.

Question 2:

Just remove the local branch:

$ git branch -d simplare/master

Questions 3:

simplare should be a remote branch.

Upvotes: 1

Marcus Müller
Marcus Müller

Reputation: 36337

I usually do a feature branch, work on it, do a pull request back to simplare and then merge it into my own fork.

We have your problem right there: as long as everything is fast-forward merging, this works as well as pulling from simplare.

However, if someone else changes a file in the time between you send in your PR and you merge your own branch into your own main branch, you might be ending up with a conflict later on.

The mechanism should be as followed:

  1. On your own main branch (assuming that's master): git pull upstream master
  2. Creating a feature branch: git checkout -b my_new_feature_branch
  3. do your work; if something in simplare/master changes that you want to use, you cann pull simplare/master here.
  4. Pull request
  5. as soon as merged into simplare , delete your feature branch and git checkout master; git pull upstream master.

Upvotes: 3

Related Questions