Git workflow for addons.mozilla.org | Hacker News Reader

Git workflow for addons.mozilla.org

blog.mozilla.com

54 pointstathagatadg11 comments

I like some of this, but I worry about rebasing that often after pushing. I understand the benefit of keeping the history cleaner, but it also means if any features are worked on by multiple people it would become impossible to use git's best feature of auto merging things.

What do you do when feature work is long standing and worked on by multiple people?

  What do you do when feature work is long standing and     worked on by multiple people?

In this case there should be a topic branch for the big feature and all development comes off that branch. You can simply replace master with the topic branch and topic branch with your personal branch and this model will work.

brilliant idea, thanks :)

If you incorporate this with good deploy scripts, it becomes rather convenient to test topic branches in different environments. No more dev/stage/prod branches, just branch off master, test and deploy the topic branch to an environment, and merge it back in to master when it's ready to live in production. I believe this is what Github does internally.

Yes, but I think dev/stage/prod isn't going away anytime soon because you usually have dependencies to other parts of the system (for instance test and staging database, various subsystems, etc).

Yea, that's hard. I think if you have good config files and deploy scripts that make sure environment specific settings stay active in their environment, you can get a lot of mileage with this approach.

  sync = "!f() { echo Syncing $1 with master && git checkout master && git pull && git checkout $1 && git rebase master; }; f"

I believe this is equivalent to (from topic branch)

  sync = "git pull --rebase origin master"

even better, "git pull --rebase" on it's own. the origin and master can both be custom per branch and work as defaults if not specified.

I believe the "fix" shell command is just

  git commit --amend

It can lead to a similar result but is not the same. git commit --amend adds all staged changes to the last commit. fixup is a rebase of multiple commits into a single one, with the fixup preset.

We (I work on addons.mozilla.org, too) try to keep the commits separate so it's easier to review. For example, if you get a review, and then have to make a few changes and get a followup review, it's easier for someone to be able to see just the new changes. (They can also view all changes, by using the compare view.) Then, before pushing to master, everything is combined.

Reply on news.ycombinator.com