5 ms·

Git workflow for addons.mozilla.org

54 points by tathagatadg 15y ago

etherealG 15y ago
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 15y ago
  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 15y ago
    brilliant idea, thanks :)
loganlinn 15y ago
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 15y ago
  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 15y ago
I believe the "fix" shell command is just git commit --amend
- metachris 15y ago
  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.
- gkoberger 15y ago
  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.
yesimahuman 15y ago
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 15y ago
  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 15y ago
    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.

54 points by tathagatadg 15y ago

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 15y ago
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 15y ago
  brilliant idea, thanks :)

loganlinn 15y ago

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 15y ago
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 15y ago

I believe the "fix" shell command is just git commit --amend

metachris 15y ago
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.
gkoberger 15y ago
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.

yesimahuman 15y ago

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 15y ago
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 15y ago
  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.