

Git workflow for addons.mozilla.org - tathagatadg
http://blog.mozilla.com/webdev/2011/11/21/git-using-topic-branches-and-interactive-rebasing-effectively/

======
etherealG
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?

~~~
zmanji

      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.

~~~
etherealG
brilliant idea, thanks :)

------
yesimahuman
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.

~~~
metachris
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).

~~~
yesimahuman
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.

------
loganlinn

      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"

~~~
etherealG
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.

------
evmar
I believe the "fix" shell command is just

    
    
      git commit --amend

~~~
metachris
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.

