Learning Git. Need to know if I am on the right track

Question

Before I started using Git as my SCM, I would "throughly" test the code for stability then I'd just copy the working directory and rename it to something like (date)project_name. Then if I messed up somewhere and couldn't dig myself out I would just start from the last stable directory. Then I heard about Git.

I want to know if I'm using Git correctly so far. This is what I've been doing:

1. write some code...

2. git add . to add all the changed files to the stage

3. git status to check if those changed files are ready to be committed

4. git commit to commit the latest changes and write a commit message

5. repeat

So far this is all I've been doing. For simple backup purposes and for the ability to revert back to a "previous stability" is this enough knowledge of Git? If not, what else should I know?

Answer 1

If all you want to do is be able to reset to an old commit when something goes wrong, then yes, that's it. Although you can combine all the git steps into one with:

git commit -a

(which commits all changed tracked files)

---

I would look into branching and tagging if you have time, but they're not strictly required for what you're doing, they just tend to make life easier

Answer 2

I use gitk --all to visualize my revision history and uncommitted changes over all branches, and I use git commit -am "commit message" to add and commit in one command.

I would also recommend using branches liberally. I do web development, so I'll have the master branch reflect the status of the code on the server, and I'll create a new branch every time I'm working on a big feature. That way, if I have an emergency bug fix, I can easily checkout the master branch, commit and upload the fix, and merge it back into the feature-in-progress.

Answer 3

And for a handy way to preview the changes before adding them,

git diff

Answer 4

Yes, you're doing it right :) Before commiting, it's sometimes a good idea to run the following command:

git difftool

This will let you to go through all your code changes in your favorite diff tool (for example Beyond Compare, KDiff3 etc.). Just press enter to open the tool, make sure everything is OK and close the program. Then hit enter again to automatically diff the next changed file.

If you're using Windows, here's a good tutorial on how to set up your favorite diff (and merge) tool.

Answer 5

As others have mentioned, I highly recommend getting comfortable with branches. My workflow is typically:

Starting form the master* branch:

• git checkout -b awesome-new-killer-feature create a new branch (-b) and have it checked out.

• write some code ...

• git add ., git status, git commit commit small changes, repeat step 2

OH no! My friend just reported a serious bug! He lost data!!!!!

• git checkout master go back to the master branch

• git checkout -b bugfix-serious-data-loss create new branch for hotfix

• fix bugs, git add, git status, git commit, rinse, repeat until bug is fixed

• git checkout master go back to master branch

• git merge --no-ff bugfix-serious-data-loss merge bug fix back onto master

OK, now I can get back to working on my awesome-new-killer-feature:

• git checkout awesome-new-killer-feature resume working on what I was working on

• git rebase master merge back changes to master onto working code so we get the benefit of the bugfix. Not to mention this reduces the probability of merge conflicts later on when we need to merge this branch back to master

• write code, git add, git status, git commit, rinse, repeat until feature is complete

• git checkout master, git merge --no-ff awesome-new-killer-feature merge the branch back onto master

Now sit back and type gitk to see a nice historical view of what you've been doing.

Optional:

• git branch -D bugfix-serious-data-loss awesome-new-killer-feature delete unused branches. I like to keep my repo clean

The power of git comes not from being able to checkpoint your work. It comes from how fast and cheap branching & merging is. Branching allows you to work on multiple ideas at the same time and/or experiment with throw-away ideas all without affecting your stable code. If the idea doesn't work simply delete the branch, if it works merge it back onto master.

*note: By convention most git users call their main/trunk branch "master".