Source Control) lets you track your files over time. You’ve probably cooked up your own version control system without realising it had such a geeky name. Ever had a folder full of files like this? • index.html • index_01-07-2011.html • index_FINAL.html This shared folder/naming system may work for class projects or one-time papers. But software projects with multiple developers?
a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos. A good VCS does the following: • Backup and restore - Files are saved as you edit them. Need a files from Feb 23, 2011? No problem. • Synchronisation - Lets people share files and stay up-to-date with the latest version. • Short-term undo - Monkeying around with a file and messed it up? Throw away your changes and go back to the “last known good” version. • Long-term undo - Sometimes things go wrong. Suppose you made a change 2 months ago and it had a bug. Jump back to the old version and see the change on that day. • Track changes - As files are updated, you can leave a message on why a file was updated. This is stored in the VCS, not on the file. Useful to see how a file evolves over time. • Track Ownership - Every change is tagged with the name of the person who made it. Helpful for pointing the finger giving credit. • Sandboxing - Make changes in an isolated area. Test and work out the kinks before checking in. • Branching/Merging - A larger sandbox. Branch a copy of your code in to a separate area and modify it in isolation (tracking changes separately). Later, merge these changes back in to the common area.
database storing the files and history. • Server - Computer storing the repo. • Client - Computer connecting to the repo. • Working Copy/Working Set - Your local directory of files, where you make your changes. • Trunk/Main/Master - The primary location for code in the repo. Think of code as a family tree - The trunk is the main line. Basic Actions • Add - Put a file in to the repo for the first time. • Revision - What version a file is on (v1, v2, v3) • Head - The latest version of the repo. • Checkout - Download a file from the repo. • Checkin - Upload a file to the repo (if it has changed). • Message - A short description of changes made. • Changelog/History - A list of changes made to a file since it was created. • Update - Synchronise your files with the latest from the repo. • Revert - Throw away your local changes and reload the latest version from the repo. Advanced Actions • Branch - Create a separate copy of a file/folder/project for private use. • Diff/Change/Delta - Find the difference between two files. • Merge/Patch - Apply the changes from one file to another to bring it up-to-date. • Conflict - When pending changes to a file contradict each other. • Resolve - Fixing the changes that contradict each other. • Locking - Taking control of a file so nobody else can edit it until you unlock it.
we get a new revision (r1, r2, r3, etc.). Diffs are the changes you made while editing: imagine you can “peel” them off and apply them to a file. Branches let us copy code into a separate folder so we can monkey with it separately. You may have to check out, edit and check in. Made a mistake? Revert to the previous version and start again (or stop).
“Rice” feature from our experimental branch into the mainline. How would we do this? Diff r6 and r7 and apply that to the main line? Wrong! We only want to apply the changes that happened in the branch!. That means we diff r5 and r6, and apply that to the main trunk. Conflicts can arise when changes appear that don’t gel: Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog). At this point it’s a race: if Joe checks in first, that’s the change that goes through (and Sue can’t make her change). When changes overlap and contradict like this, the VCS may report a conflict and not let you check in — it’s up to you to check in a newer version that resolves this dilemma. Tags are just branches that you agree not to edit; they are around for posterity, so you can see exactly what your version 1.0 release contained.
months ago has updates scheduled in that will take 2 weeks to complete. The original website build is all stored within version control and this is where the website is deployed from. Work begins on the updates and the developer is following the correct procedures and checking in changes frequently. Day 4 in to the updates, an urgent amend is requested to the current live website which needs to be actioned immediately. Problem All the updates that have been carried out for 4 days have been checked in to the repository. If the repository was deployed in its current state, all half finished work would be live.
of which are ideal or should ever be used as a way to update a project! 1. Rollback all your changes - Remove updates that were made over the last 4 days so that you have the project as it was before the updates were started. You can then make the urgent amends, deploy, then restart the work you have just deleted... 2. Log on to server - Connect directly to the production hosting for the project and carry out the updates live. Don’t do this. Ever. Apart from the risk of making a mistake and taking the website down, it also means any deployment systems you have will overwrite these changes in the future. 3. Wait... - This is rarely an option, but if possible, stall the updates required until you have completed all tasks you were already working on. An important point to make is that with a little planning and thinking ahead about the work you need to do, this problem can be bypassed completely!
work on. If the developer had created a new branch from the main trunk at the start of the updates there would have been no problem. The updates could have been completely isolated from any production code allowing for the urgent amend to be carried out and deployed. Once all updates had been carried out, this temporary branch can be merged back in to the main trunk ready to be deployed to the production server(s).
work. A ‘Production’ branch which always mirrors the current state of the LIVE application. Any updates are carried out on the ‘Master’ branch and when complete, merged on to the ‘Production’ branch where they can be deployed from. This approach works in a single developer environment, but if the team is larger it would mean several people could be working on the ‘Master’ branch all at the same time.
working off the ‘Master’ branch we now have a ‘Feature Branches’. These are created each time a new update is required to the application. This means we have a ‘Production’ branch safely tucked away and a ‘Master’ branch which is stable and can be used as a Continuous Integration (CI)/nightly build if required. The benefit here is we can have several update projects running simultaneously on their own isolated feature branch. For example: - • feature-branch-blog • feature-branch-twitter_integration • feaeture-branch-new_locale_russia Once each update project is complete, it can be merged in to ‘Master’ for testing on a staging environment.
us to separate staging from production as well as new features. The final problem is we now have to carry out bugfixes and set release numbers/build dates directly on to ‘Master’. This could be a problem if the bugfixing phase snowballs in to hours/days worth of amends. During this time, new features could be finished the next release. Solution As soon as the ‘Master’ branch is in a near production ready state, it should be branched off in to a Release Branch.
master is in a near production ready state, we should branch off to create a release branch. This can then be used to dot the i’s and cross the t’s of the release. By doing this it means the ‘master’ branch is freed up to receive the next round of updates. Once the release is completely ready, it can be merged in to ‘Production’ and also merged back in to ‘Master’ to make sure that future releases receive any bugfixes that have been carried out during the release process.
created a reliable, safe environment for a team to create and update an application without the worry of buggy/ half finished code being deployed to production. However.... There is still one small problem that could arise. We still have the issue where if an urgent amend is reported the only way it could be published to live is by going through the process of branching master, fixing the bug, merging back in to master and then waiting for the next release branch to be created...That could be days!
in a state where we can work on it, but we should never work directly to that branch. To fix a bug, you should create a hotfix branch from ‘Production’. On this temporary hotfix branch you can fix the bug in an isolated environment without interfering with anyone else. Once the bug has been squashed, you should merge the branch back in to ‘Production’ AND ALSO in to the latest release branch if one exists, otherwise directly in to ‘Master’. This is to safeguard that the bugfix is included in any future releases that happen.
waa
akit37
0gm
_kensh
iwatatomoya
sh_fk2
hacobu
kevinrobot34
stakaya
skanehira
zozotech
you
kuromelon257
jmmastey
lara
sergeychernyshev
carmenintech
tanoku
bluesmoon
lynnandtonic
tammyeverts
malarkey
mongodb
skipperchong
trishagee
