git switch
/ git branch
#
Let's finalised this topic by creating a new branch inside of our repository and creating a file inside it:
1 2 3 4 5 6 |
|
We used the -c
flag on the switch
sub-command because the branch doesn't exist yet, and -c
tells the sub-command to create it. We get a confirmation that we've switched to the new branch.
I followed switch
with status
and was told something interesting: On branch goodbye
.
So, we created a new branch and we switched to it. Perfect!
Let's create a new file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
I've used cat
with a heredoc
(look it up!) to create a new file and populate it with some content. Once this was complete, I used cat
to confirm the file was correct. Finally, a git status
shows us that the file is "untracked".
Let's look at something important now:
1 2 3 4 5 6 7 |
|
Our hello.txt
file is still there, even though we created a new branch? The answer is simple: we created a new branch off of the master
, so the new branch contains everything that *parent" branch has. Let's delete it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Now we have an interesting "working tree" (the state of the current tree of files before they go onto the staging area.):
- We're deleting the
hello.txt
file - We're creating the
goodbye.txt
file, but we haven't tracked it yet
Because the hello.txt
file is tracked, deleting it shows as a change and not an untracked file. This is simply because hello.txt
is already present inside of the repository as we created it earlier in the master
branch.
Let's stage our change and new file:
1 2 3 4 5 6 7 8 |
|
I used the git add .
command to add everything that Git had detected in the "working tree", to the staging area. Our status
confirms this.
We have a new file
and the have a deleted
action taking place. Let's commit this staging area, but this time using an inline commit message:
1 2 3 4 5 6 7 8 9 |
|
I used git commit -am
to commit the staging area to the repository.
The -a
flag means, "Add everything in the staging area to this commit". Without it, you would have to do git commit -m "your message" <filename>
for each and every change in the staging area. That can be a lot of work if you're making a lot of changes.
The -m
flag is used to provide the commit message.
Following this command we can we get 2 files changed, 1 insertion(+), 1 deletion(-)
- because we deleted hello.txt
and created goodbye.txt
, so two things changed.
Also note our commit hash and branch changed: goodbye 90e3273
.
Now check this out:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
So now our goodbye
branch has the goodbye.txt
file in it, but not the hello.txt
file; and the master
branch has the hello.txt
file but not the goodbye.txt
file.
use the git branch -l
to list your branches:
1 2 3 |
|
The *
is the current selected branch.
Now what about our log? That must have changed, right?
1 2 3 4 5 6 |
|
But we added a new commit?! Except it was added to another branch:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
I switch
-ed to the goodbye
branch (note the lack of -c
) and then used git log
and now we can see two commit entries: the one this branch "inherited" from the master
branch, and the new one we created earlier.