Learning Git. Need to know if I am on the right track
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:
write some code…
git add .to add all the changed files to the stage
git statusto check if those changed files are ready to be committed
git committo commit the latest changes and write a commit message
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?
5 Solutions collect form web for “Learning Git. Need to know if I am on the right track”
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
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-featurecreate a new branch (-b) and have it checked out.
write some code …
git add .,
git commitcommit small changes, repeat step 2
OH no! My friend just reported a serious bug! He lost data!!!!!
git checkout mastergo back to the master branch
git checkout -b bugfix-serious-data-losscreate new branch for hotfix
git commit, rinse, repeat until bug is fixed
git checkout mastergo back to master branch
git merge --no-ff bugfix-serious-data-lossmerge bug fix back onto master
OK, now I can get back to working on my awesome-new-killer-feature:
git checkout awesome-new-killer-featureresume working on what I was working on
git rebase mastermerge 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
git commit, rinse, repeat until feature is complete
git checkout master,
git merge --no-ff awesome-new-killer-featuremerge the branch back onto master
Now sit back and type
gitk to see a nice historical view of what you’ve been doing.
git branch -D bugfix-serious-data-loss awesome-new-killer-featuredelete 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”.
Yes, you’re doing it right 🙂 Before commiting, it’s sometimes a good idea to run the following command:
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.
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.
And for a handy way to preview the changes before adding them,