CODEWITHSUNDEEP
gitgit-branchgit-flow
kawingkelvin
kawingkelvin

Reputation: 3971

git branch and checkout does nothing?

I am a new to git workflow (used to a proprietary version control system at work). I followed some tutorial on how to make a branch locally, make changes there, all without affecting master. Here's what I did:

  1. git clone <url>
  2. git checkout -b change_readme
  3. make a random change to the Readme file.
  4. git checkout master

But the same change is seen in Readme now.

I thought I am back to master and there shouldn't be any change. Also, if I made a change in master, the same change is also there when I move back to the change_readme branch. It is as if I never did any branching.

Upvotes: 2

Views: 1083

Answers (3)

veben
veben

Reputation: 22332

Between steps 3) and 4), you did not add the change to the index (with git add command), and you did not commit the change locally (with git commit), so the change is not linked to a branch in particular.

You should follow theses steps:

  1. git clone <url>
  2. git checkout -b change_readme
  3. Make a random change to the Readme file.
  4. git add .
  5. git commit -m "Commit the change of Readme file"
  6. git checkout master

Use git push command, after step 5), if you want to push your change to the remote change_readme.

Upvotes: 3

torek
torek

Reputation: 489638

See veben's answer for a short sequence of commands to use.

To understand what's really going on, be aware that Git has a somewhat peculiar notion of how to do source code version control. In particular:

  • What matters to Git are commits. A commit has some metadata, such as who made it, when, and why (the author's log message), along with a full, complete snapshot of all files. Commits are identified by big ugly strings of letters and digits. These are called hash IDs, or sometimes SHA-1 IDs (Git currently uses Secure Hash Algorithm 1 to make them) or Object IDs (OIDs). People sometimes refer to them as the commit hash (when they're specifically for commits—Git uses this for other things too).

  • The files that are in commits are frozen, and compressed into a special Git-only form. (In fact, everything in a commit is frozen—you can't change it, you can only thaw it out and make a new and improved one and use that instead of the old one. That's what git commit --amend does, for instance.) Since they are in a Git-only form, you need a place to work.

  • Hence, Git provides you with a work-tree. Here, your files have their ordinary everyday form. You can use them, edit them, replace them, and so on. Git doesn't really use these files for much at all—it just provides them, extracted from a commit.

  • Git makes new commits from what Git calls, variously, the index, the staging area, or the cache, depending on who / what part of Git is doing the calling. The index is hard to see (you can see it—try git ls-files --stage, for instance—but usually it has way too much stuff in it to look at it this way). The files in the index are in the special Git-only form, ready to be committed: almost, but not quite, frozen.

The git add command, which you will need to use quite often, copies a file from the work-tree—the one that you've worked on, or newly created if that's the case—into the index. This replaces the previous copy, if there was one, or puts a new file into the index for the first time. It's now ready to be committed.

Many other Git commands also use or manipulate the index. The most obvious is git commit, which takes whatever's in the index right now and freezes it into a new commit. Less obvious is git reset, which—depending on options and flags—copies files from the commit to the index and maybe also to the work-tree. The git checkout command has a mode where it, too, copies files from a commit to the index and then to the work-tree, or from the index to the work-tree without first coming out of a commit.

When you use git status to see what's going on, git status compares the current (or HEAD) commit to the index. Whatever is different here is staged for commit. Then it compares the index to the work-tree. Whtaever is different here is not staged for commit. So if you have made some changes, and used git add to copy them into the index / staging-area, HEAD vs index will show staged changes. If you have not yet used git add, HEAD vs index will show nothing, but index-vs-work-tree will show unstaged changes.

The index is often a pain, and one might wish that Git were like Mercurial (which doesn't bother with an index), but it also lets you do some fancy tricks. It's important to be aware that there are three copies of every file: one in HEAD, one in the index, and one in the work-tree, instead of just the frozen HEAD copy and the editable work-tree copy.

Upvotes: 1

theophilus okoye
theophilus okoye

Reputation: 1

the when you commit changes to a branch they only exist in that branch, so if you switch to the change_readme branch those change will not exist

if you want to add the changes you have made in master to the branch you created, try:

git push master : change_readme

and if you want to push to a remote repository try:

git push master : change_readme

Upvotes: 0

Related Questions