How developer teams should work with TOGETHER ?
I’m working in a Fashion Company and i’m on CTO seat. We have 4 developer and 4 designer and we are growing faster than light. But there is a problem when you 2 or more. How we will develop together ?
The most general way is to work on ftp, as you know. Open ftp, choose file, work on file, and close it. But there is an error ? How to revert it ? Oh my god! If you read and understand clearly above text, there is no need to panic. Because you have a stable system to develop systems. Not forget, first part is setup enviroment, not developing.
On our company, we are working with Git, and follow GitFlow way. What is git ? And What is GitFlow ?
Git is a distributed revision control system with an emphasis on speed,data integrity and support for distributed,non-linear workflows.And developed by Linux Torvalds. There is a lot of Git Server. You can also have your own server, but i think there is no need for that. On our company we are using BitBucket, but you can also choose; “GitHub”, “GitLab” and etc.
The Gitflow Workflow defines a strict branching model designed around the project release. On general way, there is two main branch, called “Develop” and “Master” (you can increase that main branchs, like “Staging” or “Bugs” etc). Every developing start with branch, under of “develop” branch. After that, theese sub-branches merges with “develop”, and push to git server. When everything is okey, “develop” merge to “Master”.
In example, there is two developer, called “John” and “Lary”. For first step, they shoud clone repo to local.
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
John and Lary is working seperate features and both of them finished their develop and need to push git server.
git checkout -b some-feature develop
Both of them add commits to the feature branch in the usual fashion: edit, stage, commit:
git add <some-file> git commit
After John check his codes and decide to push first he check “develop” branch on git server to whether there is any change or not.
git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature
The first command makes sure the develop branch is up to date before trying to merge in the feature. Note that features should never be merged directly into master.
While John is still working on his feature, Lary starts to prepare the first official release of the project. Like feature development, he uses a new branch to encapsulate the release preparations. This step is also where the release’s version number is established:
git checkout -b release-0.1 develop
This branch is a place to clean up the release, test everything, update the documentation, and do any other kind of preparation for the upcoming release. It’s like a feature branch dedicated to polishing the release.
As soon as Lary creates this branch and pushes it to the central repository, the release is feature-frozen. Any functionality that isn’t already in develop is postponed until the next release cycle.
Once the release is ready to ship, Lary merges it into master and develop, then deletes the release branch. It’s important to merge back into develop because critical updates may have been added to the release branch and they need to be accessible to new features. Again, if Lary’s organization stresses code review, this would be an ideal place for a pull request.
git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1
Release branches act as a buffer between feature development (develop) and public releases (master). Whenever you merge something into master, you should tag the commit for easy reference:
git tag -a 0.1 -m “Initial public release” master git push — tags
Git comes with several hooks, which are scripts that execute whenever a particular event occurs within a repository. It’s possible to configure a hook to automatically build a public release whenever you push the master branch to the central repository or push a tag.
There is a bug!
After shipping the release, Lary goes back to developing features for the next release with John. That is, until an end-user opens a ticket complaining about a bug in the current release. To address the bug, Lary (or John) creates a maintenance branch off of master, fixes the issue with as many commits as necessary, then merges it directly back into master.
git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push
Like release branches, maintenance branches contain important updates that need to be included in develop, so Lary needs to perform that merge as well. Then, he’s free to delete the branch:
git checkout develop git merge issue-#001 git push git branch -d issue-#001
That’s ALL! There is your new enviroment is ready. Start and code clearly.