@jezeniel
Whenever you start working, always pull from the upstream branch and merge it back to your working branch.
This will avoid, doing a big merge of changes or conflicts at the end of your dev work.
$ git pull origin master # if untracked
$ git pull # if tracked
Whenever you start working, make it a habit to branch out of the source branch like "master".
This will give you freedom to always commit your changes. And avoid committing directly to the main branches.
$ git checkout -b <branchname> # create new branch
$ git checkout <branchname> # switch to branch
After you reach a certain milestone in development, always commit your changes.
This will make it easier to avoid losing a lot of work. You can just checkout your recent changes.
The downside here is you still need to balance the frequency, it will be harder to rollback if your commits are too granular.
It is also a good idea to consider squashing your commits before you merge request.
It is useful to write descriptive commit messages, you can generate changelogs from your commits, and if anything goes wrong you can easily find the offending commit.
Avoid using inline messages `git commit -m` all the time, take advantage of `git commit` so you can write a more detailed commit message.
This can work hand-in-hand when squashing commits.
"Fix style for login button"
"Add new feature x"
"Optimize database query when fetching stats"
Viewing the status and diff of your project will give you awareness of the currently changed, deleted, untracked files.
This is a good habit to have before adding and committing your changes.
$ git status
$ git diff
Use interactive or patch mode when staging files. This will give you opportunity to review and double check your changes before committing.
Avoid using catch all commands like `git add .`
or `git add -A`.
$ git add -p # patch
$ git add -i # interactive
It is always a good idea to review your pull request before requesting someone else in reviewing your code.
Check for possible typos, unnecessary imports, unused code etc. This can save your time and the reviewer's time.
Update your local branch with the latest origin branch, before making a pull request.
Don't forget to delete your branches locally, and on the repository after you are done with them.
Just to avoid clutter, and possibly clashing with existing branches if you don't cleanup often.
In software like gitlab you have an option to delete branch after merging.
$ git branch -d <branch-name> # local only
If you merged someone's code, delete the branch it was merged from.
Useful to make shortcuts of most common commands.
# .gitconfig
[alias]
st = status
co = checkout
ci = commit
br = branch
$ git st # git status
$ git co # git checkout
$ git br # git branch
$ git ci # git commit
You can use the `-p` flag not just in adding but also for checkout and stash.
$ git checkout -p
$ git stash -p
Be careful with, `git stash -p` on the same file. You will have to `git add` the affected file so you can pop it without losing your change, and just unstage it afterwards.