top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration

Creating a new branch in GIT

+2 votes

I would like to know what are the best practices when creating a new branch. For example. If I get a request to do update website title from XYZ to ABC; then should I create a branch named; "Update Title"? Or I should prefix this as suggested here ( Are there any official prefixes?

Also I am concerned about the following; Let us say I create the branch named "Update Title". Finish the change. Merge back with Master. I then get another request to change title from ABC to DEF. Can I create another branch "Update Title". Will not this be confusing?

posted Apr 21, 2014 by Abhay Kulkarni

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

+1 vote

In Git, a branch is merely a pointer to a commit. The crucial bit is "pointer" -- this means any commit might be pointed to by any number of branches at the same time, and that's why commits do not "belong" to any branch. Hence whatever meaning you put into a branch name is only in your head -- this does not affect commits reachable from that branch in any way. Moreover, once you merge a branch into another, and subsequently delete the merged branch, the commits made on it stay there forever while there's no more traces left of the deleted branch -- as if it had never existed.

So, do whatever you want with your branches. Giving your branches names like "Update Title" is not a common practice but for purely technical reason: in Git, a branch is represented by a file on a filesystem, and using branch names with "funny characters, spaces included" might, in some situations, cause problems. So I'd name your branch "update-title" -- that is, no title casing, no spaces.

Another popular approach is to put your bug tracker / ticketing system first: when you're given a task to update the site's title, open a bug for this first and get that bug's ID back, then simply encode the bug's
title into the branch name, like "bug-xxxxx". This will give you unique branch names. When you merge you branch back to the integration branch you mention the bug's ID in the commit message and then close the bug in the tracker.

Note that Git has certain means to attach "metadata" to your branches. Two of them that I know of are

  • git branch --edit-description which allows you to set a description of the purpose of that branch. This description is used by some other Git tools but you can print it back using the git config command:

    git config branch.bug-xxxxx.description

  • git notes allows you to attach a note to any commit. Notes are not pushed by default (and supposedly the shouldn't be, unless everyone in the team agrees to do that as they were supposed to be used locally).

answer Apr 21, 2014 by anonymous
Similar Questions
+1 vote

I have heard conflicting statements about the impact of branching in git. Let's say we have 100 feature branches that are all stored in a remote repo, would that affect performance (CPU/network) in a noticeable way ? How about 1000? 100,000 branches? In other words how does git scale with regards to number of branches?

+5 votes

basically, I've got clones of some expensive-to-build projects (node.js), and I have changes that I want to rebase/cherry-pick onto dev and stable branches.

I know I can push to a remote, then pull into my other, and keep the two on different branches so the builds don't get out of date. But, I think I'd like it if they all just shared the same objects, branches, etc...

Could I symlink together my .git{branches,config,hoks,logs,objects,packed-refs,refs} directories? Is this just going to kill me later?

+2 votes

How do I switch to a hash on a branch without creating moving to a new branch? Say I'm currently at the HEAD of master, and its hash is aaa. I want to stay on master, only switch to a previous hash... (say eee...)

I know I can use the HEAD~ or whatever, but I'd like to find out how to do it based only on a hash...

+1 vote

At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system.

I tried (on a dummy git archive)

git filter-branch --index-filter 'git rm --cached --ignore-unmatch bigfile' master branch1 branch2

That, however, does not leave a copy of bigfile on the file system.It isn't clear to me why not, though the description of the --tree-filteroption to filter-branch (I'm using the --index-filter option, but is is "similar") states:" (new files are auto-added, disappeared files are auto-removed ... )".
Is there a direct way to do what I want, with git? I've found similar requests;none of the responses point out that the above command actually deletes the file from the file system.

0 votes

When I update my branch from master it pulls down several files, including some sass files. When I compile, however, gulp alerts me that I am missing .scss files.

I tested this by creating a new fresh branch and running gulp sass. This time there were no errors and I saw the missing .scss had been brought in.

Would anyone know why, on update, I am only getting some of the files from master?

Contact Us
+91 9880187415
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Karnataka INDIA.