git

Git has become a fundamental part of our developers' daily routine that it’s hard to remember our lives without it. And yet, most of us use a limited set of commands and options. Today, I want to focus on two commands most developers probably use every day and look at the defaults behind them. git push After git commit, git push is probably the second most used command.

For once, I’m wondering a bit if this post can be helpful to somebody else. I believe my context is pretty specific. Anyway, just in case it might be the case, here it is. My Jet Train project makes use of GTFS. GTFS stands for General Transit Feed Specification. It models public transportation schedules and their associated geographic information. GTFS is based on two kinds of data, static data, and dynamic data. Static data may change but do so rarely, e.g.

Most tutorials about Git history rewriting state that history should never ever be rewritten. Like all principles, it depends mostly on the exact context. The principle should probably be updated like this: Public Git history should not be rewritten The reason is that once the Git history has been pushed, it has been made public: other developers might have started working on top of it. Then, and only then, is rewriting the history an issue.

I manage my Jekyll blog in a Git repo. My publication process uses 2 branches: master contains all production content, and feature/newposts has the new blog posts, ready to get published, one commit per post. To publish an existing post: I check the to-be-published post in the feature/newposts branch. Then, get the associated commit. And cherry pick it in the master branch. Finally, I push.

I started working with Git some years ago, and to be honest, it was not easy to pick up. It’s a huge beast, and there are several ways that can help to tame it. On the web, most articles focus on creating command shortcuts. In general, this goes like: instead of writing git pull --rebase, let’s create a shortcut to type gpr.

There are two main use-cases for creating Git shortcuts: the command is used very often, and the shortcut will save a few keystrokes every type, and the command is used very seldom, and it’s hard to remember all correct options.

Since its inception, the attitude of GitHub toward repositories was to allow unlimited public repositories, while make private ones paying. Whether it’s a consequence of Microsoft’s acquisition or not, this stance changed recently: GitHub announced private repositories were also made free, for up to 3 contributors. There was a lot of celebration on the Web, but not from my side. This move looks more like a (desperate?) move to keep developers on GitHub.

I admit the title is a bit provocative. Of course, you need to push your changes. I should probably have renamed it Don’t just git push, or Don’t simply git push. But I’m sucker for clickbait titles. My point is, you should never ever type: git push This begets the question, why? Answering this question is the subjet of this post.

I use Git a lot, in my daily job as well as for this blog. When using it, I often rebase locally before pushing, to have a clean and readable history. A sample workflow For my blog, the branching model looks like the following: o---o---o---o master \ \---o---o feature/newposts master As expected, this branch is the production site. feature/newposts The branch is dedicated for new posts. There’s one post per commit.

I’m not Git expert and I regularly learn things in Git that changes my view of the tool. When I was showed git rebase -i, I stopped over-thinking about my commits. When I discovered git reflog, I became more confident in rebasing. But I think one of the most important command I was taught was git rebase --onto. IMHO, the documentation has room for improvement regarding the result of option.

When one thinks about hosting one’s Git repository online, one’s first choice is just Github, no questions asked. It’s so successful that it has become the de facto standard of Git solutions in the cloud. It’s so well-entrenched that developers are advised to use it as their portfolio. At first glance, Github has it all: public repositories, group collaboration, metrics, page hosting, on-premise install option, etc.