joejag/dotfiles: Every dev should have some dotfiles, these are mine

joejag/dotfiles: Every dev should have some dotfiles, these are mine: "Every dev should have some dotfiles, these are mine"



'via Blog this'

Everyday Git Aliases

Everyday Git Aliases: "Git gives you as much flexibility in how you construct your VCS workflow as it does for the commands you use on your local repo. In your gitconfig file you can add alises for your favourite commands, in this article I'll talk about mine. You can see my gitconfig on github."



'via Blog this'

What we learned from Google: code reviews aren’t just for catching bugs

http://blog.fullstory.com/2016/04/code-reviews-arent-just-for-catching-bugs/

A big chunk of the FullStory engineering team formerly worked at Google, where there is a famously strong emphasis on code quality. Perhaps the most important foundational tenet at the big G is a practice called code reviews, or, more precisely, “pre-commit” code reviews. We continue the practice at FullStory and hold it as sacrosanct.

Although much has been written about the benefits of code reviews, it isn’t yet a ubiquitous practice in the world of software development. But it should be, particularly for large engineering teams or teams with a flat management structure, e.g. no project managers or supervisors.

Contained herein are both the big, obvious engineering reasons you should adopt code reviews, as well as the more nuanced – but equally important – benefits to your customers and your own company culture.

How do code reviews work at FullStory?

While working on a new feature, Dave (for example) will cut a branch from the current version of our master product and work exclusively on that branch, a process with which I’m sure most of the coding world is intimately familiar. But before he can reintegrate the changes into master, Pratik or another qualified engineer must review his work and give him the stamp of approval: LGTM (looks good to me).

If Pratik has an issue with the way Dave has designed or coded the work, they’ll have a discussion (potentially with a long volley of back-and-forth reasoning) until they reach an agreement. Or, if Pratik has no issues, he can LGTM the work right away.

Git & Scrum: Workflows that work - O'Reilly Media

Workflows that work - O'Reilly Media:


I love working with teams of people to hash out a plan of action—the more sticky notes and whiteboards the better. Throughout the process, there may be a bit of arguing, and some compromises made, but eventually you get to a point where people can agree on a basic process. Everyone gets back to their desks, clear about the direction they need to go in and suddenly, one by one, people start asking, "But how do I start?" The more cues you can give your team to get working, the more they can focus on the hard bits. Version control should never be the hard part.

By the end of this chapter, you will be able to create step-by-step documentation covering:

• Basic workflow
• 
  
• 
  
• Integration branches
• 
  
• 
  
• Release schedules
• 
  
• 
  
• Post-launch hotfixes

This chapter is essentially a set of abstracted case studies on how I have effectively used Git while working in teams. You will notice my strong preference for Agile methodologies, in particular Scrum, in this chapter.

Git/GitHub: Kindly Closing Pull Requests

Kindly Closing Pull Requests:



Getting your first pull request from an outside contributor on GitHub is an exciting experience. Someone cared enough about the problem you were solving to check it out themselves, change something, and contribute that change back to your project. When your project has a relatively small number of high-quality, desirable incoming pull requests it is easy to happily merge them.

Where things can become more difficult is when your project becomes more notable and the quality, desirability, or number of pull requests you receive causes difficulties. Now the positive feeling you had about the time people spent can be reversed; you don't want to reject someone's work when they have already spent the time to get it included.

Let's discuss some common types of pull requests that can be closed and how to do so in a way that encourages positive behavior in your community (rather than discouraging participation).

Maven, Git, Jenkins software build tool links

http://www.slideshare.net/tarkasteve/understanding-git-voxxed-vienna-2016

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:

1. Parameters for better logging
2. Log actual changes in a file
3. Only Log changes for some specific lines in file
4. Log changes not yet merged to the parent branch
5. Extract a file from another branch
6. Some notes on rebasing
7. Remember the branch structure after a local merge
8. Fix your previous commit, instead of making a new commit
9. Three stages in git, and how to move between them
10. Revert a commit, softly
11. See diff-erence for the entire project (not just one file at a time) in a 3rd party diff tool
12. Ignore the white space
13. Only “add” some changes from a file
14. Discover and zap those old branches
15. Stash only some files
16. Good commit messages
17. Git Auto-completion
18. Create aliases for your most frequently used commands
19. 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.