GIT Cloning or Checkout? to work on the feature branch

Question

I am new to GIT, We have GIT repository with feature branch. I want to take the feature branch and do some changes. But I confused between Cloning and Checkout. Please help. I should not do it on feature branch directly? I must have a local branch of it even for minor changes?

Were you instructed to work directly on the feature branch, or to branch off from it? As for cloning, that's something different, and you may have already done it. — Tim Biegeleisen, Nov 28 '17 at 10:33
cloning the branch Vs checkout the branch without create a new one. Please suggest? — jaban, Nov 28 '17 at 11:12
You don't really clone a branch, you clone an entire repository. I can't give you a formal answer because it is not clear where you are. — Tim Biegeleisen, Nov 28 '17 at 11:18
Thanks Tim. Please advise what this does actually? git clone -b feature/ — jaban, Nov 28 '17 at 12:53
I've never actually used that, though I can tell you that most of the time just cloning the entire repository is good enough. — Tim Biegeleisen, Nov 28 '17 at 12:58

score 0 · Answer 1 · answered Nov 28 '17 at 11:54

In order to work on a remote feature branch on your local machine, you must create a local branch to work from that tracks that remote branch.

Assuming you've already cloned your repository and have a local master branch;

git fetch
git checkout -b feature_branch origin/feature_branch

You now have a local copy of the feature branch to work on - committing and pushing changes will then update the remote feature branch.

score 0 · Answer 2 · answered Nov 28 '17 at 16:19

You really should read through a good book on Git, otherwise you will be in for a world of headaches.

Let's define some terms first.

A commit is a complete snapshot of some source tree. Along with this snapshot, a commit contains a bit of what we call metadata: information about the commit itself, such as who made it, and when. One other key piece of metadata stored with each commit is the identity—the hash ID—of its parent commit, which is its immediately preceding commit.

Each commit is uniquely identified by its hash ID, which is a big ugly name like 89ea799ffcc5c8a0547d3c9075eb979256ee95b8 that no one could ever possibly remember or predict.¹ So Git remembers these for you, in a way we'll get to in a moment. Remember that each commit records a parent, too, or sometimes more than one parent, so 89ea799ff... might have 3505ddecb... as its parent (or one of several).

A repository is, at its heart, a collection of commits. Along with this collection of commits, the repository has some names—branch and tag names, for instance. Each branch or tag name, in Git, simply holds one (1) of the unique hash IDs.²

A clone is a new repository based on an existing repository.

In a typical clone, you copy all the commits (and all their corresponding other Git objects) from the source repository. Then you have your Git, in your repository, rename all of their branch names so that they are no longer branch names at all, but rather, are remote-tracking names. A remote-tracking name is an awful lot like a branch name, but with two differences:

It's in your repository but its point is to track their branch—a branch name in the other Git. You therefore can't use it as your branch.
And, it's therefore automatically updated when you git fetch and git push to get new things from them, or give to them any new commits that you made.

Once you have a repository of your own, you will also have, in that repository, one index and one work-tree.³ You can use these to build your own new commits. Making a new commit makes your current branch name point to the new commit. The new commit's parent commit is whatever was the current commit, before you made the new one. The new commit's snapshot is whatever is in the index at the time you run git commit.

The git checkout command is kind of complicated—it has too many things it can do—but its main purpose is to set up your index and work-tree so that you are "on" one particular branch. The branch you are on, such as master or develop or feature, determines which commit in the repository is the current commit. This is the commit whose hash is stored under that branch's name.

If you ask to check out a branch name like master or feature, and you don't have that branch yet, your Git will check your remote-tracking names. If there's exactly one that looks the same, your Git will create a new branch name for your repository, using your saved remote-tracking name's saved hash as the initial hash for your branch. Thus, git checkout feature, in a new clone, will select origin/feature as the correct commit hash, create feature with that hash, and then get "on" that branch. The git status command—use it often!—will now say on branch feature.

Whenever you make a new commit, Git packages up whatever is in the index right now and uses that for the new snapshot for the new commit. This means that the index's main function is to hold the content for the next commit to make. Thus, the index starts out with the contents of some existing commit. This content is also found in your work-tree, which is where you can actually do your own work.

Having made some change(s) to your work-tree, you must copy the changes back into your index, otherwise they won't go into a new commit. To copy a revised file from your work-tree into your index, you simply git add the file. This updates the index copy from the work-tree, and now that version will be in the next commit. Repeat this for every file that you change. Note that if you change the file again after git add-ing it, the index still holds the version you git add-ed, not the one that's in the work-tree. You'll need to git add it again to copy the new version into place.

When everything is ready to go, and you run git commit, Git does the following (in a way that looks like it's all one atomic transaction):

Snapshot the index.
Collect your name, email address, and the time, to use as the author and committer data for the new commit.
Collect a commit message. (This may use your favorite editor, but you have to tell Git which one is your favorite.)
Use the current commit's hash ID as the parent of the new commit. Git will find this current commit's hash ID in the usual way, by reading the contents of the branch name.
Make a new commit. This new commit, being new, gets a new, unique hash ID.
Write the new commit's hash ID into the current branch's name.

Note that now that the new commit is the current commit, the branch name points to the new commit. Git will find the old commit by looking at the current commit's parent. Meanwhile, the index now matches the current commit, because the new commit—which is now current—was made from the index. Whether the index matches the work-tree is up to you.

¹Although they seem to be random, every hash ID is computed from the commit's contents. If you have two identical hash IDs, you have one single commit, or other Git object, that you have listed twice. If you have two different hash IDs, you have two different objects. Every Git in the universe will compute the same hash ID for the same object, but—because the computation uses a cryptographic hash—it's almost impossible to figure out how to lie about hash IDs. But only almost.

²Note that, while object hash IDs are unique, you can have multiple names that store the same single hash ID. For instance, it's pretty common to make a new tag based on the current commit, and if you do that, the new tag names the same commit as the current branch name. (This glosses over the distinction between a lightweight tag and an annotated tag, but never mind that for now.)

³A so-called bare repository has no work-tree at all, so that you can't do any work in it. The purpose of such a thing is to act as a place to clone from and push to.

In Git since version 2.5 (but with some big bug fixes in 2.6), you can add more work-trees to your regular, non-bare repository. Each added work-tree comes with its own index.

GIT Cloning or Checkout? to work on the feature branch

2 Answers2