4

I am just now starting to use version control and my head is spinning! I am trying to wrap my head around branches, checkout, merging and rebasing. I'm sure these are stupid questions but would really appreciate some help.

My projects are PHP. I am using Aptana studio for my IDE, Bitbucket and SourceTree for Git GUI.

So I think I might have a rough idea on how this is supposed to work now. Please tell me where I am wrong.

Say I want to add a new feature. I have a master branch. In Aptana I can right click a file → Go to team, and then create a new branch. I can name that branch feature a1bc. I make my changes.

Once I am done with this feature and all the changes I click Team → Commit, then Team → Merge branch → master. This merges my changes back into the master repo.

Is this roughly how I would go about doing feature adds, etc.? Also what do I do if I have 100+ features as time goes on? Do I keep all those feature branches or delete them after they are merged back in?

nwellnhof
  • 32,319
  • 7
  • 89
  • 113
ipengineer
  • 3,107
  • 7
  • 33
  • 37
  • There's pretty much an infinite ways on how to do this. If I had any say in things, I'd follow [the git-flow model](http://nvie.com/posts/a-successful-git-branching-model/). Mostly because it's documented, and comes with [high-level tooling](https://github.com/nvie/gitflow). – millimoose Mar 16 '12 at 23:16

1 Answers1

7

You need to decide if you merge back in master as a fast-forward merge or not:

git merges

Since branches are made to isolate a work (see "When should you branch"), you can regularly incorporate your feature branch into master, while continuing the development of said feature on the feature branch.
In that scenario, a merge --no-ff is advisable (and, considering Aptana defaults, might better be done in command-line).

However, if you made a branch to isolate a short-live development, you can incorporate back your feature branch in master through a fast-forward merge (in order to "blend" completely the two branches).
If master had some commits while you were developing feature, you will need to rebase feature on top of master first, then merge feature in master (this will be fast-forward).

For more, see:

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • VonC, So after I merge those feature branches back into the development branch do I delete the feature branch? If not I end up with a HUGE list of feature branches. Or is there a way to hide them from the list so they are not showing anymore? – ipengineer Mar 17 '12 at 15:09
  • @ipengineer: for shrot-lived `feature` branch, you clean their history (squashing a few commits, reordering them), then rebase said `feature` branch on top of `master`, and finally merging it fast-forward, making the (cleaned) history of that `feature` branch part of the one of `master`. So in that case, you don't really delete it (in that you keep the commits), you just, by deleting the `feature` branch, deleting the pointer to said branch. – VonC Mar 17 '12 at 16:59
  • @ipengineer However, for long-lived `feature` branch, where you merge significant commits back to `master`, then yes, you can delete also `feature` branch, which deletes the pointer but also "forget" all the intermediate commits. – VonC Mar 17 '12 at 17:29
  • One of the clearest explanation of a source control best practice I've seen, good work! – Micael Bergeron Jun 28 '12 at 17:14