19 Tips For Everyday Git Use
I’ve been using git full time for the past 4 years, and I wanted to share the most practical tips that I’ve learned along the way. Hopefully, it will be useful to somebody out there.
If you are completely new to git, I suggest reading Git Cheat Sheet first. This article is aimed at somebody who has been using git for three months or more.
Table of Contexts:
- Parameters for better logging
- Log actual changes in a file
- Only Log changes for some specific lines in file
- Log changes not yet merged to the parent branch
- Extract a file from another branch
- Some notes on rebasing
- Remember the branch structure after a local merge
- Fix your previous commit, instead of making a new commit
- Three stages in git, and how to move between them
- Revert a commit, softly
- See diff-erence for the entire project (not just one file at a time) in a 3rd party diff tool
- Ignore the white space
- Only “add” some changes from a file
- Discover and zap those old branches
- Stash only some files
- Good commit messages
- Git Auto-completion
- Create aliases for your most frequently used commands
- Quickly find a commit that broke your feature (EXTRA AWESOME)
GitHub Pull Requests
GitHub’s mission is to make it easier to work together than alone. Throughout the company’s history, they have worked toward this goal by providing an easy way to host Git repositories online and surrounding those repositories with a growing set of collaborative mechanisms that work in the browser and through Git itself.
Pull Requests may be the most important of these innovations. They have enabled increased open-source contributions, provided new ways for enterprise teams to work together, and offered a full-featured code review mechanism—all at the cost of a few Git commands and a simple web user interface. Let’s take a look at how pull requests work and how to use them in open-source and enterprise environments.
Neal Ford: Why Everyone (Eventually) Hates (or Leaves) Maven
Which is why every project eventually hates Maven. Maven is a classic contextual tool: it is opinionated, rigid, generic, and dogmatic, which is exactly what is needed at the beginning of a project. Before anything exists, it’s nice for something to impose a structure, and to make it trivial to add behavior via plug-ins and other pre-built niceties. But over time, the project becomes less generic and more like a real, messy project. Early on, when no one knows enough to have opinions about things like lifecycle, a rigid system is good. Over time, though, project complexity requires developers to spawn opinions, and tools like Maven don’t care.
