Once this is done that developer (the branch lead) force pushes to their fork/some_project branch then creates a pull request to merge into principal/some_project. This too may sometimes generate conflicts and these must be resolved. To acomplish this we designate a 'branch lead' their role is to locally merge updates from master into some_project using merge (not pull, rebase) in SmartGit. This is fine and all that's needed now is a way to merge in ongoing updates that appear in principal/master (for example urgent fixes or other projects that are delivered before some_project is finished). This way they get other developers' commits and may from time to time have to resolve the odd conflict.
#SMARTGIT HGFLOW FREE#
This way developers are free to pull/rebase locally and push to their forks - this is pretty much the standard fork workflow. The developers local branch some_project tracks the remote branch principal/some_project.ĭevelopers do their local work on branch some_project and push-to to their fork/some_project, from time to time they create pull requests, this is how each developer's work gets merged into principal/some_project. (We use smartgit and we also have a policy that remotes are named 'principal' and 'fork' rather than 'origin' and 'upstream' which just confuse new users).Įach developer also has a local branch named some_project. We have a principal repository and each developer has a fork of that.Ī branch is created principal/some_project, the same branch name is then created on each developers' fork, fork/some_project. This works well for us with a team of 12. This is the only time we touch master, ensuring that it is as clean as possible. Once the release branch is verified by QA in production, the release branch is merged back into master (and dev, just to be safe). That is the branch used in production, replacing last week's release branch. We are on a weekly release schedule, so every week, after QA has approved the dev branch, a release branch is made with the date in the name. Everyone keeps in sync by pulling on dev often. Once the feature is ready, it's merged locally back into dev and pushed up to the cloud (Bitbucket, Github, etc.). This is where git's cheap branching comes in handy. Developers don't have to work on the same branch, since each feature branch is scoped to only what that single developer is working on. Instead of having a branch per developer, we make feature, or ticket, branches from dev.įor every discreet feature (bug, enhancement, etc.), a new local branch is made from dev. There is a dev branch, taken initially from master, that all devs work off. Master is golden only the merge master touches it (more on this in a bit). The workflow we use is one of many branches. I can't really speak to the merits of the methods described in your post, but I can describe how we solved collaborative coding in the workflow we use at work. How do you handle such a collaboration in your workflows? But this means, that server dev needs to publish his branch in Bitbucket, which will make it impossible for him to rebase or change commits, that are already published.Īnother option is to wait, until server dev finishes his work, publishes branch with nice commits history and forgets about it, and only after that client dev starts to work in this branch, but this will cause time delays, which is even worse.
Logically would be for server dev to create a branch, and for client dev to create his own branch, based on server dev branch.
Server dev creates basic structure of HTML files and client dev needs to get this structure.
How these two should collaborate in a way, that commit history in master stays clean? In our case we almost always have two developers for one branch, since one developer is working on server-side (PHP), and another - client-side (HTML/CSS/JS).
#SMARTGIT HGFLOW CODE#
QA verifies functionality and approves (or disapproves) it, then I'm verifying code and if it is ok, I merge his work into master (by fast-forward or rebasing for better commits history).īut this scheme is good only in a case, when single developer works on a branch. Once he decides, that his code is ready, he creates a nice branch history (using rebase, amend, cherry-pick etc.) and pushes it to Bitbucket, where creates a pull request to master branch. Every dev must create his own branch and implement features/bugfixes in his own branch. Master branch is considered to contain stable code only. Reading documentation and articles I've found the following structure good for us: I'm a team leader in our web development company, and I'd like to implement Git workflow in our team.
0 kommentar(er)
