Git Guide
Problem description
For the company that I work we tried quite a few code versioning tools before finalizing Git. We tried our hands on CVS, SVN and Perforce with less than satisfactory results. Even now we have multiple models for handling Git versioning. Some of us use Gerrit and others are happy with the usual Github Fork and Pull Request model.
Suggested Git model
We use Github enterprise version which is an in-house hosted service similar to public Github. For our products we have a platform repository and each teammate has a fork of the repository and work on their fork.
Our main working branch is develop and released code is merged in master. For more information you can read git branching model by Vincent Driessen.
Some commands
Clone - git clone [email protected]:myname/product.git. Here I am assuming you have already forked the platform repository and is available in your Github space.
Add remote - git remote add upstream [email protected]:myname/product.git. It’s a common convention to call your fork ‘origin’ and the platform repo as ‘upstream’. You can call it something else if you so desire but conventions make everyone’s life a tad bit easier so I would recommend sticking with them.
Create feature branch - git checkout -b ft-my-changes It’s a good idea to create a feature branch for each change you work on. This makes the pull request process manageable.
Pull latest changes - git pull --rebase upstream develop. While the pull would still works without the “rebase” switch it results in a lot of unnecsssary merge commits if you pull changes frequently.
Check changed files - git status. Once you start modifying your code you may want to know what are the changes made. This command is a handy way to find out what files are changes, what are added and which of these are staged for committing.
Check changes in files - git diff myfile.js. This command would show you the changes in a file. If you don’t provide a filename then it shows the diff for all changed files. If you have staged your changes (see below) you can still find out the changes by using git diff --cached.
Stash changes - git stash save MEANINGFUL_MESSAGE. While pulling changes you would face the issue of what to do with the local changes. Git provides functionality to stash the changes in a temporary store which can be reapplied later.
Apply stashed changes - git stash apply OR git stash pop. You can use any of these commands to apply the stashed changes back. If you use git stash apply, remember to clean up the stash storage by using git stash drop.
Stage changes - git add <list of files>. Just using git add . would add all changed/added files to stage for commit but I won’t recommend it as with time you would end up having some files that you may not want to check-in. For example, I modify some development files to optimize my development flow.
Commit changes - git commit. While you can add a single line commit using a -m "message" switch you shouldn’t do it. My recommendation is to put a change identifier (JIRA ticket etc) and a short message describing the change, leave a line empty and add multiple lines of change description.
Modify last commit - git commit --amend. You would frequently require to modify the changes you had just committed. Use this command to do that.
Push changes to remote - git push origin ft-my-changes. You should push the changes to your repository once you are done. You can do that halfway in your development cycle too. Just remember to amend your existing commit and do a force push - git push origin +ft-my-changes. Once you have done this you can go to the upstream repo and create a Pull Request for review and merge.
Final words
While there are many more git commands that you must know to be a called an expert at this versioning tool but I believe these are enough to survive on a day to day basis. If you want to learn more I recommend reading Git SCM book.