Currently the branching process looks like this:
master > work-in-progress > new-feature-branch
I feel this complicates things as it's too easy to branch from master rather than the current work-in-progress (I've made this mistake myself) and creates more scope for conflicts. To simplify things, I've pulled the work-in-progress branch back to master and will retire it soon. This means the branching process looks like this:
master > new-feature-branch
This means we're only one pull back to master at any time. It should also make problems with conflicts easier to resolve without having to pull back through multiple branches.
Moving forwards, I will start to work on individual new features in their own branch rather than operating directly on master. This was fine when I was the only developer, but only causes merge issues when I change a file in master related to a feature a contributor is working on. By restricting myself to the same rules as other contributors, we should have an easier time with collaboration.
Simplifying Git Branches
-
Nystul
- Posts: 1501
- Joined: Mon Mar 23, 2015 8:31 am
Re: Simplifying Git Branches
nice! will make things easier for sure!
-
Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Simplifying Git Branches
By the way, small fixes and features are perfectly OK to pull straight to master. Just anything with a large time commit or lots of complexity should be sequestered to its own branch first.
-
Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Simplifying Git Branches
I've just bumped master to version 1.4.56 and fixed a minor bug. When you guys get a chance, please merge my latest master into your fork's own master and working branches. This ensures when you send me back pull requests they should merge without any problems. You can also delete your work-in-progress and just leave master and working branches.
Moving forwards, I'm going to confine my updates to their own branch also. This means that master will remain relatively stable and only change when there are small, direct fixes or one of the large feature branches are merged back down. This will be a nice change from the the old work-in-progress branch which was changing almost daily.
Something we all need to coordinate are changes to the core, as this can potentially result in conflicts when two developers modify the same core files. It might be best to send core changes on their own, rather than as part of the larger update. That way we all get a chance to pull that change at the time without any other files being impacted.
All good fun! I'm certainly learning more about git every day.
Moving forwards, I'm going to confine my updates to their own branch also. This means that master will remain relatively stable and only change when there are small, direct fixes or one of the large feature branches are merged back down. This will be a nice change from the the old work-in-progress branch which was changing almost daily.
Something we all need to coordinate are changes to the core, as this can potentially result in conflicts when two developers modify the same core files. It might be best to send core changes on their own, rather than as part of the larger update. That way we all get a chance to pull that change at the time without any other files being impacted.
All good fun! I'm certainly learning more about git every day.
-
Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Simplifying Git Branches
I've just fixed a bug Lypyl spotted with my Unity 5.3 compatibility update. This fix is in DFTFU master from version 1.4.57.
Please pull from master to your fork and working branches to get the update.
Please pull from master to your fork and working branches to get the update.