Disclaimer: This article is developed presuming that reader is well accustomed with types ,commands, purpose and usage of version control.There are plethora of concepts involved in git so understanding all is not a necessity but as per daily needs I will try to make a few clear in this space.
Git , a distributed version control system helps developers in their day to day work by saving the work they do,collaborating with co developers so and so forth. But there are a few practices which helps in better usage of git which are as follows:
Always working on private / feature branches:
It is always a good practice to checkout relevant private branches rather than working on master or feature branch directly because working on different branches for different purposes will serve the need exceptionally well by maintaining different versions of code development which in turn will avoid the fuss or mess eventually.
Avoiding unnecessary commits:
Committing code just to pause present code changes will actually make the git log huge with commits so instead of unnecessary commits one can choose stashing i.e temporarily saving work (git stash is the command) and for a few changes amending the previous commit rather than creating a new one will make git log much precise.
history with amending commits history with new commits
This concept of amending will serve good until there is no push to remote repo because if amending commit is done after push local tracking branch will not be in sync with remote repo and there will be issues while pushing . So creating new commit after push of previous commits is advisable.
“Pull” vs “Fetch followed by rebase”:
The most commonly used command to get latest changes from latest repo is “git pull” but this will eventually make the git history / log look weird with all non linear graphical representations of commits involved and there by making it cumbersome to understand , the reason is that git pull is a combination of git fetch followed by git merge (which creates a third commit from two commits involved in merge) so better way is to fetch the changes and then rebase your branch on top of local tracking branch i.e applying a series of commits on top of latest commit of local tracking branch by doing so history appears linear and therefore log makes it easy to understand.
History After merge After rebase
Reset: Hard , soft and mixed:
There is a lot of hue and cry whenever there is a usage of “git reset” command , so better understanding it will help in reverting the unwanted changes.
1. Hard reset will make the HEAD point to a particular commit by removing all the changes from the working tree (sounds harsh , isn’t it?)so extra caution is needed while using this command.
2. Soft reset does the same as hard reset but the difference is that changes are not lost from the working tree but they will be marked as “changes to be committed” (sounds better,isn’t it?).
3. Mixed reset as per name it is a mixing and matching of both hard and soft reset in a way that it will even remove files from index i.e staging area so user will have to redo “git add” for all those changes and this is the default reset mechanism if no options are provided to “git reset”.
Using tools over commands:
There are tools available like gitk ,gui, mergetool etc. using them will make the job easy by avoiding confusion of the changes to commit , rebasing mechanism ,branches cut etc. so better choice is to choose these tools over commands.
Ignoring and considering files:
Maintaining a well furnished .gitignore file always comes handy while adding to index or committing changes. So putting all log ,temp etc files/folders in ignoring part of git requires a special mention though it may sound trivial.
Foot notes : Git Documentation