Git Strategy with Workbrain
- Steve Ahn
- Aug 22, 2017
- 2 min read
Migrating your Workbrain custom code to git? Here are some key considerations and best practices (according to me, anyways). Keep in mind that git/code management strategies can vary.
Decide if you'll host the repository on a remote server or keep the repository local? You can use GitHub to host your git repository, or you can store local git branches on a shared directory for your collaboratiors.
A remote repository like GitHub provides additional collaboration tools and controls over branches. You can require pull requests to merge code into a branch, and force adds a layer of control for your remote repositories.
Remote repositories can be more secure. Local git repositories rely on the developers to secure, back up, and store the repository correctly.
Remote repositories can be easier to configure with automated build tools (not covered)
Identify the terminology differences.
Checkout in SVN has a different meaning than checkout in git. Familiarize yourself with the git terminology.
Git is centered around merging entire branches. There is no locking of files.
Git commits track line-level deltas. The commit does always not represent the entire file.
Define your branch strategy. Workbrain implementations typically have at least three environments: DEV, QA, and Production.
Environment = branch strategy - Each environment is represented by a permanent branch. Merge between each branch as a method to promote code.
Merging can be dangerous between branches when there are a large number of collaborators. Any more than 2 developers and I would not recommend this approach.
Each environment can be cleanly built and deployed from each branch. Best when there is one release at a time.
Branch-release strategy - Each release has a feature branch, and branches are merged from master until the feature branch can be deployed as a release to each environment.
An environment does not have a concrete representation by a single branch. The environment is deployed by release feature, and if the release has moved through the dev-test cycle.
Best for large collaboration teams. Each feature branch can isolate changes for a release. Not necessary to work on a single release at a time. Each developer should have their own feature branch, and pull from master/other branches as necessary.
Adjusting from SVN to git takes an investment in time and resources, and the risk for lower breakfixes while the team acclimates to the new system. However, git is a superior collaborative tool for managing code. Features and breakfix/hotfixes are easier to branch and merge. It is also extremely easy to revert to a prior version of the code.
Comments