Week 2Day 4 - "Let's do this right, not fast"
Uh-Oh I Think I Made A Mistake
So now we are fairly well acquainted with adding files into the repository and performing commits.
In a short while we will learn about how to view the changes we have made and perform diffs against various objects.
Before we close out the week, we need to go back to the trenches one last time.
In the trenches...
"Rob, ya got a second?" asked Mike.
"Sure, what's up?" replied Rob from across the office.
"Gimme two secs to make this commit." The office went silent again whilst Rob's fingers darted across the keyboard.
"Ahh. Damn it!" shouted Rob.
Mike rose from his chair and walked over to Rob.
"What's up?"
"I just added a file into the staging area, but I don't want it there."
He shook his head, "Well not yet anyway."
Mike chuckled, "Sorry for interrupting dude."
"Nah, it's OK, I just need to know how to pull this file out of the index."
"Git reset," shouted a voice.
The stillness of the office was interrupted by a chair free wheeling across the floor.
The occupant of the chair was Klaus.
He seemed proud that he was finally getting to grips with things.
"You can use git reset to reset a file that's in the index."
He grabbed at the keyboard, "Here, lemme show you."
The git reset command is great at removing things from the index that you don't want to be there.
Of course, it can do a great many other things, but for now, let us concern ourselves with the scenario presented above.
We are working away, and have added a number of files into the index ready for committing, when we discover that we are actually not ready to commit them.
In the following example, we are going to add the file my_third_committed_file and then remove it from the index.
john@satsuki:~/coderepo$ git add my_third_committed_file
john@satsuki:~/coderepo$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: my_third_committed_file
#
john@satsuki:~/coderepo$
Notice how my_third_committed_file is now ready to be committed to repository.
The problem is we need to add something more to it before we do.
Remember that when we run the git add command, we are copying the file from our working copy to the index.
If we decide we no longer want that file in the repository, we can run the following.
john@satsuki:~/coderepo$ git reset my_third_committed_file
john@satsuki:~/coderepo$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# my_third_committed_file
nothing added to commit but untracked files present (use "git add" to track)
john@satsuki:~/coderepo$
We have discarded the file which was residing in the index.
This is very important to note.
We are not moving the file from the index back into our working directory, we are literally just deleting the file from the index.
Our working copy remains unaffected.
We could run the git reset command without appending a file.
If we did this, all the files in the index would have been discarded.
In the trenches...
"So, I think we are all agreed, I'll keep a version of the repository under Git version control.
Until everyone else feels comfortable with some of the more advanced features." John looked around the room for any disagreements but there were none.
"Agreed John," said Markus, "I'm pleased with how you guys are progressing, very pleased, but like John said, it's far better for us to take our time and to implement this correctly, than to rush it and to end up with something that we can't administrate and that we don't know how it works."
"So next week, I want you all to start playing with diffing and logs and don't forget we have an important release due too." John pushed his glasses further up his nose.
"The week after that we'll start looking at branching and by then we may be at the stage where we can implement our model."
Everyone nodded in agreement.
Knowledge - How do we change the commit message editor?
We spoke earlier about the configuration file and how it stores information about our Git instance.
Git can use any text editor you require, even a graphical one, though the need rarely arises.
As mentioned earlier, Git has a preference lever when talking about configuration.
First and foremost it will look in the repositories own 'config' file in the .git folder.
Then, it will look in the users ~/.gitconfig file.
Finally, Git will look in your distributions own global folder. If we wanted to change the editor that Git would use to modify commit messages, we can either modify the files directly, or run a command similar to the following; git config core.editor "nano"
If we want the changes to apply globally, meaning it would affect all repositories we administrate as this user, unless overridden by a repository setting, we would run the following; git config --global core.editor "nano"
It is worth noting that you can also use the $EDITOR environment variable to accomplish the same thing.
Many people use this in preference to the modifying the Git configuration simply because many other programs honour this setting.
Now we know how to add files into the repository.
The question is, what do we do if we need to remove a file, or even rename it.
Well, git has some commands to help with that.
git rm and git mv delete and move files respectively.
Usually when you want to remove files from the repository, or move them, this is how you will handle it, but what if you have already deleted a tracked file manually? Well, you have two options.
You could run git commit -a, but remember this will commit all changes to tracked files.
You could also run a git rm <filename> with the name of the file you have just deleted.
Git will then push that change into the staging area ready for commit.
The same applies to moving a file
However, it is worth noting something in the way that Git handles renames.
Git does not track renames explicitly.
This means that by running the git mv <source> <dest> command, you are essentially running a Linux mv command, followed by the git rm on the source file and git add on the destination file.
Running the git mv command is a shorthand way of doing just that.
It is worth playing with this to ensure that you understand what is happening.
As an exercise, inspect the repository after each command so that you understand at what point Git recognises your actions as a rename.
We have run through a few basic commands in Git.
If you are familiar with version control systems, then possibly the only real difference you will have noticed is that of the staging area.
It really is powerful, and allows you to organise and prepare your commits, so that they are both meaningful and coherent.
For Tamagoyaki Inc, their plan to implement version control was far too aggressive.
Most of the members of the team had never even used a version control system.
When deciding to implement version control, it is essential to ensure that you are doing it for the right reasons.
Version control is a tool to help you to keep things in order, but remember tools are nothing without process.
It is process that is key to the order.
|
