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.
Once you start fighting with Maven, it’ll never return to the rosy days when your relationship was young. Fortunately, at least one Maven “Get out of Jail Free” card exists in Gradle, which still understands the Maven stuff you already have, but it’s language rather than plug-in based, implemented as a Groovy domain specific language, making it more composable than Maven.
I tend to prefer composable tools. They tend to have a steeper learning curve but deliver more power and scalability over time, which is why I’m a huge Emacs fan, and why Martin’s post on InternalReprogrammability struck a chord. Contextual tools are fantastic for the proper use; I use IntelliJ for Java coding, but Emacs for pretty much everything else, and I tend to seek out composable tools when there’s an option.
Support for #Groovy based POMs shipping in #Maven 3.3.1
Learning GIT branching, the interactive way
Jenkins tutorial http://t.co/g6DfIrhcMT
— Lars Vogel (@vogella) January 30, 2015
How to Write a [good] #Git Commit Message http://t.co/a6kfArlLdG
— Markus Eisele (@myfear) August 31, 2014
No comments:
Post a Comment