SSW Foursquare

Rules to Better Version Control (aka Source Control) - 34 Rules

If you still need help, visit Application Lifecycle Management and book in a consultant.

  1. Do you know the benefits of using source control?

    Source control is the backup of your code, as well as your tool for tracking changes over time.

    With source control, we can share project code and collaborate with other team members. Using it allows us to track changes, compare code, and even roll-back if required. Moreover, it keeps our code safe and that is the most important part.

    It also helps you to do root cause analysis by finding out who made the change. Then, you can chat with them and get aligned on what caused the problem and what is the best solution moving forward. Remember, the person who made the change might have important knowledge that you don't know!

    Don't just fix the problem, see who caused the problem and correct them. - Adam Cogan

    Using VS Code? There are 2 awesome extensions to see history:

    FileChanges
    Figure: Right-click a file and select Git | View History to see the changes in source control.

    CompareFileChanges
    Figure: We can select different changesets and compare the changes

    Changesets
    Figure: We can select different changesets and compare the changes. Blue = modified, Green = addition, Red = deletion

    Annotate
    Figure: Right click a file and select Git | Blame (Annotate) to view the history on a segment basis

    AnnotatedFile
    Figure: Use annotate to understand (or find the guy) to understand his thoughts before deleting/changing someone elses code

    AnnotateDetails
    Figure: Annotation is great, but it gets even better when clicking the commit code gives you its full details

  2. Do you know how to ensure your build succeeded?

    When checking code into TFS, a build should be triggered as per the rule Do you know the minimum builds to create on any branch?

    You should not just trigger a build and walk away however – make sure that build succeeded!

    The first way is from within Visual Studio.

    builds success good
    Figure: Good Example – Check your build has passed from Team Explorer | Builds

    The second is by always having the TFS Build Notification tool always running. Through it you can subscribe to any builds you are interested in, when they start, end and their status.

    builds success better
    Figure: Better Example – Check your build(s) are continually passing by having the TFS Build Notification tool always running - Start | All Programs | Visual Studio 2012 | Team Foundation Server Tools | Build Notifications

  3. Do you know how the Gated Checkin process works?

    Gated Checkins are great for verifying your project builds successfully before a checkin occurs, but the workflow and dialog messages can be difficult to follow. Sometimes it’s not clear what you need to do next as a developer.

    The process for a project with a Gated Checkin build is:

    1. The developer clicks Check In
    2. Changes are not checked in, but are shelved and a build is queued
    3. The developer is notified when a build succeeds and prompted to “Reconcile” their workspace

    Note: This relies on the Build Notifications tool running, which may not be the case. If it’s not running, the developer has to manually reconcile their workspace before they can effectively continue working.

    gated checkin 1
    Figure: The developer is notified if a gated check-in resulted in a commit

    If you don't have the Build Notifications tool running or you click Ignore, you will have to manually reconcile. There are a few ways to do this.

    You can click Check In again. This will fail, but any files you’re trying to check in will be reconciled as a result. You should definitely not do this if you’ve made additional changes since checking in.

    gated checkin 2
    Figure: Bad Example - Reconcile by clicking "Check In" again. This will fail, but any files you're trying to check in will be reconciled.

    Alternatively, you can open the queued build and choose Actions | Reconcile Workspace... to fix your workspace

    gated checkin 3
    Figure: OK Example – Open the Build and choose Actions | Reconcile Workspace...

    The best way is to click the link in the notification to open a specific build window with a Reconcile Workspace link included. Note: This notification will disappear if you close it or navigate away from the Pending Changes window in Team Explorer.

    gated checkin 4
    Figure: Good Example #1 – Click the link in the notification after clicking Check In

    gated checkin 5
    Figure: Good Example #2 – Click on the link in the notification to open the build, then click Reconcile Workspace when the build finishes

    Read our suggestion to Microsoft on how to improve the Gated Checkin workflow.

  4. Do you know which check-in policies to enable?

    Check-in policies are a great way to enforce code quality before it hits your source control repository. SSW recommends that the following check-in policies be enabled by default on your project:

    1. Changeset Comments Policy - To enforce that all check-in contain comments
    2. SSW Code Auditor - To enforce coding standards and best practices before check-in
    3. Work Items – To ensure check-ins are linked to a Work Item in TFS

    To enable these policies:

    1. Click Settings in the Team Explorer Home hub
    2. Click Source Control in the Team Project section (not Team Project Collection)
    3. Open the Check-in Policy tab
    4. Click Add... and select the check-in policies above. If you don’t have SSW Code Auditor installed, download it here.add

    checkin policies
    Figure: Choose check-in policies in TFS

  5. After work - Do you only check-in code when it has compiled and passed the unit tests?

    Too many people treat Source Control as a networked drive. Don't just check-in when the clock ticks past 5 or 6 o'clock. If code doesn't pass its unit tests or won't even compile put your code in a shelveset.

    LeaveAMessToOthers
    Figure: Put your dishes straight in the dishwasher otherwise you leave a mess for others (aka "Check-in" the right way otherwise you give other developers problems)

    Other recommendations have included using "//TODO" or commenting the code out. However, we recommend avoiding this practice as it increases the risk that the code is forgotten about.

    Note: Having gated check-ins will help prevent this from happening.

    Note: A useful tool is TFS Auto Shelve - Protect your code by guaranteeing your pending changes are always backed up to the TFS server.

  6. Before starting - Do you follow a Test Driven Process?

    Never allow a situation where a developer can check outcode and the code does not compile – or the unit tests are not all green. This is called “breaking the build” and the punishment in our office is 20 push-ups and fixing broken links for an hour!

    1. Check out
    2. Compile
    3. Develop
    4. Compile
    5. Check-In

    Figure: Bad example - wrong process

    BeforeCoding
    Figure: Before you start cooking prepare all your ingredients. Before you start coding, "Get Latest" the right way

    1. Get latest
    2. Compile
    3. Run Unit Tests
    4. If Tests pass then start developing
    5. Check out
    6. Develop
    7. Compile
    8. Run Unit Tests
    9. Get Latest (Always do a Get Latest before checking in as code you didn't change could break your code)
    10. Compile
    11. Run Unit Tests
    12. Check-In if all tests passed
    13. Wait for gated check-in (GC) to complete
    14. Reconcile your workspace if it was successful
    15. Check that Continuous Integration (CI) build was successful(If GC was skipped)

    Figure: Good example - right process****

    Note: You should have both a Gated-Check-in (GC) and a Continuous Integration (CI) build on every branch.

  7. Are you very clear your Source Control is not a backup repository?

    Note: If you did not finish working:

    • TFS put changes into shelveset
    • SVN put changes into sandbox / branches

    Note: Another way to do this is to enable gated check-in and prevent check-ins that do not have build and tests passed.

  8. Comment - Do you know the comment convention you should use?

    New, Bug or Refactor should be the prefix.

    Here are some examples:* New P112: Added a new control for DateOfBirth

    • Bug P113: Fixed validation to now allow US dates
    • Refactor: Moved the email regex from inline to a resource file
  9. Comments - Do you enforce comments with check-ins?

    Team Foundation Server is great, and one of its neat features is enforcing comments when checking in code. Without comments, some of the other built in features like History become redundant without comments.

    You should have good comments... if you are struggling use Excuses For Lazy Coders :)

    15 07 2014 10 21 04 AM
    Figure: Bad Example: No Comments against the check-ins we don’t know what changes were made in each revision

    15 07 2014 10 24 40 AM
    Figure: Good Example: Now we can pin point which revision a particular change has been made

    In Visual Studio 2013, to enforce this behaviour, you will need to:

    15 07 2014 10 41 30 AM
    Figure: Go to Team Explorer | Source Control

    15 07 2014 10 42 21 AM
    Figure: Then Check-in Policy | Add

    15 07 2014 10 42 43 AM
    Figure: Then select Changeset Comments Policy and OK

    15 07 2014 10 42 56 AM
    Figure: Now you have the Changeset Comments Policy applied to your Team Project

    Now the next time someone checks-in some code, they are forced to enter a comment.

  10. Do you avoid limiting source control to just code?

    You can spend valuable developer time on every part of a project. The bulk of time is normally spent on coding up .cs, .vb, .resx and .aspx files. However, you could potentially have the following happen if you do not include other files in source control:* lose work

    • lose old versions of work
    • have work overwritten

    In particular, you should make it as easy as possible to see who changed what and who deleted what and allow a simple rollback to previous versions of non-code files. Files you should put in source control include:* XSL files

    • Word documents
    • Excel Spreadsheets
    • Visio Diagrams
    • HTML files
    • Image files, Flash animations and psd files  (yes this takes room in your source control database - but we still want to be able to revert to an old version easily)

    Things you don't store are:* Video files eg. avi

    • Installers eg. .msi
  11. Do you configure your Team System Web Access to be accessible from outside the network?

    If you have Team System Web Access installed and you need to access it from wherever you are, you can configure a port to be forwarded to the server where Team System Web Access is installed, eg: tfs.your-domain.com:8090.

    Visual Studio Team System Web Access Power Tool
    Figure: Visual Studio Team System Web Access Power Tool

  12. Do you configure your TFS to be accessible from outside the network?

    • TFS SP1 This feature called "Extranet Support" was added way back in TFS 2005 SP1 as per Stuff in the pipe for Team Foundation Server
    • A domain name or IP address forwarded to TFS (eg: tfs.your-domain.com)
    • Port 8080 (this is port that TFS uses for source control)
    • Firewall/Router rule (ideally)

    Tip: You can solve this with TFS Extranet Support:

    Yes Port 8080 will work in most cases but not on the strictest networks, where only Port 80 is allowed.
    Then you have to use port forwarding via a firewall/router rule (recommended) to forward port 80 to the TFS port, while in this way, you would lose the TFS SharePoint Portal and Reporting Services.

    Rule to forward port 80 to the TFS port
    Figure: Rule to forward port 80 to the TFS port

  13. Do you enforce work item association with check-in?

    One of the big advantage of using TFS is end to end traceability, however this requires the developer to do one extra step to link their code (changeset) with requirements (work items). Code is the body of software, while user requirement is the spirit. Work Item association feature helps us to link the spirit and body of software together. This is especially useful when you trying to identify the impact of a bug in term of user requirements.

    WorkItemAss 1
    Figure: Bad Example: No work item is associated with changeset

    WorkItemAss 2
    Figure: Good Example: No work item is associated with changeset

    More Information In order to achieve this, developers need to choose the Work Item tab when check-in and "associate" code with a related work item.

    WorkItemAss 3
    Figure: Associate Work Item with Changeset

    As the project administrator, you can take one step further to enable "Work Item Check-in Policy" to enforce this rule in your team.

    WorkItemAss 4
    Figure: Always enable the “Work Items check-in policy”

  14. Do you have a DevOps Master?

    The best way of getting the most out of DevOps is to have a "DevOps Master". A DevOps Master is like a Scrum Master but is only interested in helping you get 100% from DevOps and it's perfectly fine for them to be part of the development team.

    It's important to note that a DevOps Master is not a management position. It's simply a role that encourages the team to use DevOps in the best way possible. With a specialist knowledge of DevOps, they're in the best position to know what should change and what could be done better.

    Some of the things they should focus on are:

    • Taking you beyond DevOps as just a source control system
    • Using DevOps to help you on a proper ALM road
    • Making sure that automated builds are created and managed properly by the developers
    • Managing the build servers if additional help is needed (builds themselves are the responsibility of the developers)
    • Checking the builds are fit for purpose, and that unit tests are included
    • Checking that deployment is working properly
    • Checking the right check-in policies are enabled and developers are leaving meaningful check-in or commit messages
    • Ensuring code analysis is enabled and getting stronger
    • Ensuring CodeAuditor is running
    • Cleaning up unused Workspaces (this removes old check-outs by default)
    • Making sure all patches are applied to the servers (they might not do the work, but they make sure it's being done)
    • If the team is using Version Control with Server Workspaces, sending out check-in warnings every week to people which have left over check-outs as per the Do you make small changes and check in early and often?

    These duties need to be taken care of on a regular basis, but most of all, the all members of the team should be encouraged to improve things themselves.

  15. Do you include original artworks in Source Control?

    This field should not be null (Remove me when you edit this field).

    Figure: Include your original artworks in Source (eg .PSDs in Source Control)
    We chose to exempt uncompressed video files as they tend to have large footprints and potentially cause delays in productivity. It is highly recommended that you have a separate backup procedure for these files.

  16. Do you know how to lay out your solution?

    Whenever we setup a new Team Project we implement a basic version control structure. We put "readme.txt" files in the folder structure explaining the different levels, and a solution file called [Client].[Product].sln?located at ?/[Client]/[Product]/DEV/ within version control.

    MessySolution
    Figure: Bad Example, how would anyone know how to sort this mess out?

    IdealSolution
    Figure: Good Example, The ideal solution.

    For more implementation details see:
    http://blog.hinshelwood.com/archive/2010/05/17/guidance-how-to-layout-you-files-for-an-ideal-solution.aspx

  17. Do you know how to refresh the Cube?

    The cube is by default refreshed every two hours, but what is you are about to go into a status meeting and you want up to date reports?

    You can refresh the cube manually using the web services, but only from the TFS server:

    WarehouseWebControlService
    Warehouse WebControl Service
    Read Refresh the TFS Warehouse manually for more detail.

  18. Do you know how to rollback changes in TFS?

    This field should not be null (Remove me when you edit this field).

    There are two ways to do this:1. If you haven’t checked in any files since you started modifying them then the process is simple:* Right click your solution and Undo Pending Changes Undo Pending changes

    1. If you aren’t so lucky and have made some commits along the way then the only option is to use the Rollback command.

      • To use this you will need to install Team Foundation Server Power Tools v1.2
      • Find the revision before you started checking code in using the History command Revision List

        Figure: The last revision before Tristan made changes was 5367
      • Open the Command Prompt in your current working directory and type “c:\Program Files\Microsoft Team Foundation Server Power Tools\tfpt.exe” rollback /changeset:5367 Rollback Changeset
      • Click Yes and the rollback will proceed

    It would be nice if there was a GUI for this tool so that I can just right click and select rollback. See Better Software Suggestion – TFS

  19. Do you know the best Project/Version conventions?

    Having a good folder structure in version control allows everyone to know where everything is without even having to look.

    /northwind /trunk /branches (or shelvesets) /experiemental-feature1 /releases (or tags) /1.0.0.356

    Figure: Bad example - SVN conventions are a dated and ignore releases, hotfixes and Service Packs

    Trunk is the old way, Main is the new way as per the branching guidance, and it is the way that Microsoft does things.

    BranchGuidance
    Figure: Good example - This makes a lot more sense

    More Information:

    GoodFormatForInfo
    Figure: A good format for all your Products/Projects makes it easy to know where things are and what they are for

  20. Do you know the best tool to migration from TFVC to Git?

    Git has become the defacto standard for version control systems. It's distributed and decentralized and promotes working disconnected as default. It also takes away the pain of branching and merging and has a built in code review system with pull requests. Everybody should be using Git, and if you're not, you should be migrating the Git using one of the below tools.

    • VisualStudio.com - Import Repository
    • Git-Tf
    • Git-Tfs (recommended)

    VisualStudio.com - Import Repository

    VisualStudio.com gives you the ability to import from a TFVC repository into a new Git repository.

    03 29 08

    Bad Example - Built in tool has several limitations

    If you don't care about source control history, then this inbuilt tool is the easiest to use. It has the limitations of:

    • 180 days of history
    • No branches

    TIP - Use this if you don't care about source control history

    Git -Tf

    Git-Tf is an open source command line tool that works cross platform and use the Java TFS SDK. This tool is useful for migration if you're not on a Windows environment. This tool is not maintained and has issues with migrating branches.

    To see how to use this to migrate see "Migrate an existing project from TFS to Git with changeset history intact" from Chris Kirby

    TIP - Use Git-Tf if you don't have a Windows environment

    Git-Tfs is an open source command line tool that uses the .NET TFS SDK to interface between Git and TFVC. It has the following advantages over the other tools:

    • Actively maintained
    • Good support for branches
    • Author mapping
    • Migrates all history

    Follow the migration guide to import from TFVC to Git and then proceed with the after migration steps. To help you do a smoother migration, you can refer to this tool.

  21. Do you know the right source control to use?

    SSW uses and recommends Microsoft Team Foundation Server (TFS) as a source code solution.

    TFSTeam Figure: Microsoft Visual Studio Team System Here are some of the reasons why:

    • Checkin policies
    • Integrated Work Items and Source control
    • Visual Studio IDE integration
    • Code Metrics
    • HTTP access via webservices
    • Integrated Build Server

    Reasons companies choose Visual SourceSafe (VSS)

    • No server required
    • No VPN required
    • They are ignorant about the potential corruption problems

    Figure: Bad Example, Visual SourceSafe (VSS) is a bad choice

    Reasons companies choose Subversion (SVN) -It's free -It's easy to use -No Build integration -No Work Item integration

    **Figure: Better example, Subversion (SVN) is an OK choice** **Figure: Better example, Subversion (SVN) is an OK choice **

    Reasons companies choose Team Foundation Server (TFS) -It's free (With MSDN) -It's easy to use -It's easy to install -High fidelity SQL data store -No VPN required -Does not require a server (basic configuration) -Has Build integration -Has Work Item integration -Has Test suite integration -Has reporting out of the box

    Figure: Better example, Subversion (SVN) is an OK choice

  22. Do you know to always create a test if you are fixing a bug?

    This field should not be null (Remove me when you edit this field).

    TestCase
    Test case
    Figure: You can easily fix this by associating tests with a Test Case which in turn "Tests" a bug

  23. Do you know to clean up your workspaces?

    Every Workspace that exists on the server is another set of code that TFS has to check for checkouts. Worse you may have files checked out in that workspace that you will never see.

    WorkspaceStatus
    The current workspace status
    Figure: John has not accessed many of these workspaces in years! Are they still current?
    Use the Workspace Sidekick in Team Foundation Sidekicks at the end of every month to make sure you have not forgotten anything.

  24. Do you know to delete workspaces older than 6 months and warn on 3?

    The more workspaces you have the more load the TFS server is under when users check in and out. TFS has to check all of the workspaces for other checkouts of the same files which can be intensive if you have a lot of workspaces.

    If a developer had code checked out to a workspace that they have not even looked at in months, what is the likelihood that they even remember what changes they were making?

    Why do workspaces build up?* Developers use multiple computers

    • Developers use volatile virtual computers
    • Developers reinstall their workstation
    • Developers get new workstations
    • Developers leave

    Developer checklist:* Check workspaces often to see what you don't need

    • Delete any workspaces you no longer need

    TFS Master Checklist:* Delete all workspaces that have not been edited in 6 months

    • Warn developers for workspaces that have not been accessed in 3 months

    LongtimeWorkspaces
    Longtime Workspaces
    Figure: Bad example - Rebecca has a workspace that has not been accessed in a while
    CurrentWorkspaces
    Current Workspaces
    Figure: Good example - All of Julian's workspaces are current

    1. Open VS 2010, File | Source Control | WorkSpaces, click the "Show remote workspaces": Manage Workspaces

      Figure: Manage Workspaces
    2. Keep press "Ctrl", select the workspaces which haven't been used for a long time.
    3. Click "Remove" button.
  25. Do you know to get Visual Studio to remind you to check in?

    When working on a task spanning multiple files, do not check-in only one or two of the files, this leads to the problem of partial check-ins where references to new classes or methods are unavailable because they are in the files that haven't been checked in. So either, check-in all the files you are working on or none at all if you aren't finished working on the task.

    1. Make Visual Studio remind you to check code in In Microsoft Visual Studio. NET sharing project code can be configured by ticking the two checkboxes on top, in Options (from the Tools menu) as shows below. VS.NET 2008 Source Settings

      Figure: Check-in files automatically the 2nd checkbox is very important so you get reminded to check-in your project when closing VS.NET. You know how frustrating it is when you want to fix an application and all the files are checked out by some one else!
      **What about VB6 applications ?** In Visual Basic 6 this is done by going through Tools -> Source Safe -> Options and setting it as shown in the diagram below. Source Safe VB6
      Figure: You can also check-in automatically in VB6
      **What about Access applications ?** We also use VSS for Access projects. Access 2000 had problems with MDBs (not ADPs) but Access 2003 works fine with both. The only thing you have to be careful of is that if a form is not checked out, it still lets you modify the form, but when you close the form, it rolls back to the VSS version and you lose all of your changes. Source Safe Access
      Figure: You can also check-in automatically in Access
      Source Safe Access Menu
      Figure: All the basic functions are easily accessible.
      Note: Using VSS in Microsoft Access has a few limitations, most significant of which is the inability to reattach to VSS projects. Once you have detached from a VSS project, you will need to create a new VSS project in order to place the Access application back into VSS.

    What about SQL Server Databases? We save the scripts of every SQL Server schema change in Source Control.

  26. Do you know to make using Check-in Policies easier (by adding a 'Recent' Query)?

    SelectARecentWorkItem
    Select A Recent Work Item
    Figure: When you use Check-in policies you often will need to select a work item that you selected recently

    Make this easy on yourself by adding a query 'Recent'1. Create a work item query that returns you the last changed work item Add a query

    Figure: Add a query just for your associated check ins
    2. Just copy the 'Tasks - My' query 3. Add the sort date of 'Changed Date' sorted by descending Sorted the query by 'Changed Date'
    Figure: The query should be sorted by 'Changed Date'
    4. Use that query on your check ins and you find the relevant work item easily
  27. Do you know to regularly do a Get Latest from TFS?

    It is important to regularly do a "Get Latest" to make sure you are using the most recent version of the code. In a team, if you go too long without doing a Get, you are more likely to encounter inconsistencies and will have to spend time merging your code.

    As part of your team process, you should make sure all developers are doing a Get Latest on a regular basis for each project they are working on. This is in line with Do you Follow a Test Drive Process? rule.

    Tip: To find out when you or another developer last did a Get from TFS, you can use the Workspace Sidekick in Team Foundation Sidekicks. If you're the TFS Master, you should do this every couple of weeks to make sure your team is regularly retrieving files from TFS.

    SidekicksWorkspaceLastGet
    Figure: This report shows the last time each user did a Get from TFS

  28. Do you know what to do after migrating from TFVC to Git?

    After you use the right tool to migrate from TFVC to Git, there's a few more things you need to do to clean things up for a new user joining the project. By default, if there is a TFVC repository, that will become the default in the UI.

    Unfortunately, you can't kill the TFVC repository and make Git the default one, so there's a few steps you need to follow.

    2017 04 05 10 02 58

    Figure: Bad Example - Can't delete the now deprecated TFVC repository

    Delete files from TFVC

    Go into the repository, delete any existing files. Add a new document saying "_Migrated_to_Git.md". This will stop people from getting the wrong code.

    2017 04 05 10 24 52 **Figure: Clean up TFVC so developers can't accidentally get the wrong source code


    **Note : All the source code is still there, it's just flagged as being deleted.

    Lock down TFVC

    In the TFVC repository, click Security

    2017 04 05 10 43 51 Figure: Configure the security of the TFVC repository ** Then deny check-ins to **Contributors , P roject Administrators and Project Collection Administrators . This should stop anyone from committing new code to the repository.

    Update the Dashboard

    Next step is to update the dashboard to let new developers know.

    2017 04 05 10 30 43

    Figure: Good example - Let new users know that the source control is now on Git

    Suggestions for the VSTS team

    1. Give us the ability to hide a repository
    2. Give us the ability to set a repository as the default for all users
    3. Give us the ability to delete a TFVC repository

    Having any of these suggestions will avoid the confusion on this screen

    2017 04 05 10 06 12

    Figure: Bad Exmaple - This is confusing for a new dev

  29. Do you need to migrate the history from VSS to TFS?

    • Normally, you don't need to check the history very often. If you do need sometimes, then get it from VSS.
    • Save much space for TFS. For example, we have a about 7G VSS history database, and we may only need a small bit of them every 3 months, so what's the point of coping about 7G file when we only need one line of code?

    But there are also some considerations that you may want to migrate the history:

    • If the history of source changes will be checked very often, so you can check the old history with the recent together via TFS.
    • You are going to decommission the old VSS completely. Say you don't want to keep the old VSS database, and then it will be necessary to keep the information somewhere.
    • If the project is very active, then it will be worthy to migrate the history because your developers may need them every day.

    If you are going to move the history, the links may help:

  30. Do you use shared check-outs?

    In conjunction with regular check-ins, files in source control should never be locked unless absolutely necessary. Use either 'Unchanged - Keep any existing lock' - or 'None - Allow shared checkout'.

    Only use 'Check Out - Prevent other users from checking out and checking in' when checking out binary files e.g. Word documents or third party compiled dll’s. (This will be the default this will be the selected option due to the inability for binary files to be merged on check in.)

    Check outSettingsForFiles
    Check-out settings for files
    Figure: Correct checkout settings at the file level - don't lock files
    Do not enforce single check-out at the project level - make sure the 'Enable multiple check-out' option is ticked under Team Project Settings, Source Control.
    Check outSettingsForTeamProjects
    check-out settings for team project
    Figure: Correct check-out settings at the team project level - enable multiple check-out's.

  31. Do you use the Windows Explorer Integration?

    1. Install the TFS Power Tools
    2. When you install this, make sure you do a 'Custom Install', and select the 'Shell Integration' option (this is off by default)

    TFS WE 01
    Use Windows Explorer
    Figure: Using Windows Explorer for your source control is a dream (great for designers too - who don't want to use VS.NET)
    Suggestion to the TFS Team: I didn't see blame annotate in the drop down - which is a bit odd.

    More reading from the prolific Brian Harry:http://blogs.msdn.com/bharry/archive/2008/11/08/oct-08-tfs-power-tools-are-available.aspx
    http://blogs.msdn.com/bharry/archive/2008/10/01/preview-of-the-next-tfs-power-tools-release.aspx

  32. TFS Master - Do you have a report to see who has not checked-in?

    Managers should regularly check to see if developers are committing their changes into source control. In TFS you can only get status by manually looking at each project or running "TFS status" command. A great tool is Attrice Team Foundation SideKicks which can display the status of all users and projects

    SideKicksStatus
    Figure: Use TFS Sidekicks and search for files older than 48 hours to find the naughty boys.

    Suggestion for TFS Sidekicks: Add a button to “Email all people their shame list”... showing their files that are still checked out (until then I do it manually).

  33. Do you work in small chunks & check in after completing each one?

    Frequently developers work on long or difficult features/bugs and leave code checked out for days or worse still, weeks.

    1. What happens if your laptop hard drive dies?
    2. What happens if you call in sick?
    3. How can you pair program if not sharing your changesets?

    Check InRegularly
    Figure: Eating one big meal every three days gives you a bellyache... (aka check in small portions regularly, one large check-in after a few days will give you a headache)

    That's why source code should be checked in regularly. We recommend a check-in:

    If the changes would break the build or are in a state that cannot be put into the main trunk, then this code should be put into a shelveset (sometimes referred to as 'sandbox') in source control. Another good reason to check-in regularly is that it makes it easier to merge your changes with other developers. If all developers check-in lots of changes in one go, you will spend a lot of your time resolving conflicts instead of doing work.

    Tip: How can you enforce regular check-ins? Monitor them using a report to see who has not checked in.

  34. Do you use Source Control tools?

    Source control tools are essential for software developers. They enable the tracking of changes made to a project's source code, facilitate collaboration among developers, and ensure the project's consistency.

    ✅ Advantages of Version Control Software

    • Project Consistency Assurance: Keeps a record of all changes made to a project's source code. This allows reverting to a previous version of the code in case of problems
    • Facilitating Collaboration: Allows developers to work simultaneously on the same project without the risk of conflict. They provide a centralized repository for storing and managing source code
    • Improving Productivity: Can enhance developers' productivity by automating tasks like creating branches and tracking changes, and by abstracting the use of the console for most common actions
    • Reducing Risks: Can help reduce risks associated with software development. They can assist in identifying and fixing bugs more quickly, and they can also help protect projects from data loss
    • Improving Code Quality: Can help improve code quality by encouraging developers to write cleaner and more maintainable code
    • Promoting Communication: Can help promote communication among developers. They provide a way for developers to share their changes and collaborate on projects

    ❌ Disadvantages of Version Control Software

    • Complexity: Version control software can be complex to learn and use. This can be a barrier for beginner developers
    • Cost: Commercial version control software can be expensive. However, many free open-source solutions are available
    • Performance: Version control software can negatively impact the performance of the systems they are used on. This is particularly true for large projects
    • Security: Version control software can be vulnerable to attacks. It is important to take security measures to protect the data stored in a version control repository

    🧐 Did you know?
    One of the earliest version control systems, named SCCS (Source Code Control System), was developed by Marc J. Rochkind at Bell Labs in 1972. At that time, the need to efficiently manage changes to source code was just beginning to emerge in the software industry.
    This system enabled the tracking of revisions for individual files, a significant innovation for its time. It's from these early initiatives that modern version control tools like Git and Mercurial have evolved, offering far more advanced features and collaborative code management capabilities.

    GitKraken

    GitKraken is a renowned suite of developer tools designed to enhance productivity in software development. It has been evolving for nearly a decade, reflecting a continuous commitment to improving the efficiency and effectiveness of developers and their teams. GitKraken began with desktop-centric and IDE-based tools, like the GitKraken Client and GitLens for Visual Studio Code, both of which have become integral to the workflows of tens of millions of developers worldwide​​.

    The company behind GitKraken, Axosoft, has been recognized for its significant contributions to the developer community. For instance, Eric Amodio, the Chief Technology Officer at GitKraken, was awarded the Microsoft MVP Award for Developer Technologies in 2023. This award highlights his exceptional contributions to the developer community, particularly through GitLens, a popular Git extension for Visual Studio Code created by Amodio in 2016. GitLens has become a crucial tool in the daily coding processes of millions of developers, with its installation numbers surpassing 23 million.

    ✅ Pros

    • Intuitive Interface: GitKraken's graphical user interface is visually appealing and easy to understand, simplifying interactions with Git​
    • Integration with Platforms: Smooth integration with GitHub, GitLab, and Bitbucket, enhancing workflow efficiency
    • Merge Conflict Editor: Built-in tool for resolving merge conflicts, showcasing conflicting segments side-by-side
    • Drag-and-Drop Functionality: Enables performing many Git operations easily with just drag-and-drop
    • Profile Management: Useful for managing multiple profiles, distinguishing between personal and professional work
    • Dark and Light Themes: Catering to various visual preferences
    • Extensive Documentation and Tutorials: Assists new users in quickly becoming proficient with the tool
    • Cross-Platform Compatibility: Available on Windows, MacOS, and Linux
    • Graphical Commit History: Offers a vivid representation of repository history, enhancing the understanding of project flow
    • Powerful Search Functionality: Makes finding commits, branches, and other elements straightforward

    ❌ Cons

    • Performance Issues with Large Repositories: Occasional slowdowns reported, particularly with substantial repositories
    • Freemium Model: Advanced features require a subscription, despite a free version being available
    • No Git Credential Manager (GCM) Support: Lacks GCM support, which can be a drawback for some users
    • Yearly Subscription Model: Compared to one-off payment models, GitKraken adopts a yearly subscription approach
    • Marketing Aggressiveness: Reports of excessive marketing emails after contacting support
    • App Stability Issues: There have been instances of the app crashing upon opening in past versions, though this may have been resolved in newer updates
    • UI Aesthetics vs. Performance Trade-Off: The attractive UI may come at the cost of slower performance compared to some alternatives
    • Limited Terminal and Workspaces Features: GitKraken's terminal and workspaces might not meet the needs of users requiring advanced features

    gitkraken
    Figure: branchs management in Git Kraken

    GitKraken emerges as a visually appealing, user-friendly Git client, making it an excellent choice for those new to Git or preferring a GUI over command-line operations. Its graphical interface, ease of use, and integration capabilities are significant strengths. However, its performance with large repositories, the freemium model, and some missing features like GCM support are noteworthy drawbacks. For developers and teams considering a GUI for Git, GitKraken presents a compelling option, especially if the project scale and the need for advanced features align with what GitKraken offers.

    Fork

    Fork is a Git client software designed to provide an efficient and user-friendly experience for handling version control tasks.
    Fork's development is primarily the effort of Dan and Tanya Pristupov. They started it as a side project but eventually moved to working on it full-time. Their focus has been on making Fork an increasingly robust and user-friendly tool, constantly improving and updating its features. The software is available for both Mac OS X and Windows, with a straightforward pricing model that offers free evaluation and a standard price for professional use.

    ✅ Pros

    • Light weight and Efficient: Fork's lightweight design enhances performance, particularly for small to medium-sized projects, reducing system resource usage
    • Simple User Interface: Its intuitive interface is tailored for ease, allowing users to navigate and perform version control tasks with minimal complexity
    • Integration with Various Development Environments: Fork supports integration with various development tools, fostering efficient workflows and collaboration
    • Cost-Effective: For individual developers, Fork is free and open-source. For enterprises or freelancers, it has a one-time cost of $50, making it a cost-effective solution
    • Regular Updates: Fork is frequently updated, ensuring that it stays current with the latest developments and user needs
    • Image Diff Viewer: A unique feature of Fork is its ability to show differences in image files, which is not commonly found in other Git clients
    • Merge Conflict Resolver: Fork includes tools to help resolve merge conflicts
    • Responsive and Intuitive: Users highlight Fork's responsiveness and intuitive design, making it a pleasure to use for routine Git operations
    • Efficient File Staging: Its ability to stage changes line-by-line efficiently and without resetting the file scroll view is praised, especially for feature-specific commits
    • Responsive and Intuitive: Users highlight Fork's responsiveness and intuitive design, making it a pleasure to use for routine Git operations
    • Aesthetic and Theme Support: The overall aesthetic and dark theme support of Fork are noted as positives, with a clean and polished UI that appeals to many users
    • Syntax Highlighting and Code Formatting: Fork supports syntax highlighting for various programming languages and offers code formatting, which enhances the readability and organization of code
    • Privacy-Focused: The ability to open several repositories in individual tabs for easy
    • Multiple Repositories in Tabs: Fork is considered a privacy-friendly tool, as it does not track users or use their personal data

    ❌ Cons

    • Limited Features: While efficient, Fork may not offer the breadth of features that some more advanced or established version control tools provide
    • Lack of Integration with Cloud Services: The absence of direct integration with major cloud services could hinder remote collaboration and backup options
    • Less Suitable for Large Projects: Given its design and feature set, Fork might not be the best fit for very large projects or enterprises with complex version control needs
    • Limited Community and Support: Being a smaller tool compared to giants like Git, the community and support resources available for Fork might be limited
    • Still Developing: Being relatively new, Fork may not be as feature-rich as some other established Git clients
    • No Linux Support: Currently, Fork is not compatible with Linux, which can be a limitation for developers who use multiple operating systems
    • Access Requirement for Git Projects: Fork requires granting access to your git projects, which might be a concern for some users
    • Learning Curve for Git Flow and Tagging: Some users feel that Git flow and tagging features are less intuitive compared to other clients like SourceTree
    • Potential Learning Curve: For users accustomed to more complex tools, adapting to Fork's simplicity could initially be challenging

    fork
    Figure: Staging in Fork

    Fork represents a balanced choice in the Git client market, particularly appealing to individual developers and small teams due to its simplicity, efficiency, and cost-effectiveness. However, for larger projects or users in need of advanced features and integrations, it might fall short. The continuous updates and dedicated development by its creators keep it a competitive and evolving tool in the software development landscape.

    SourceTree

    SourceTree is a sophisticated Git client designed to simplify how developers interact with their repositories. It has been a staple in the developer community for over a decade, constantly evolving to meet the changing demands of software development. Initially developed by Atlassian, the same company known for Jira and Bitbucket, SourceTree provides a user-friendly, graphical interface to Git, making complex workflows accessible even to those new to version control.

    Atlassian's commitment to the developer community is evident in the continuous updates and improvements to SourceTree. It integrates seamlessly with other Atlassian products like Jira and Bitbucket, providing a cohesive experience for teams already using these tools. The integration with these platforms allows for a streamlined workflow, reducing the need to switch between different applications. SourceTree's popularity is partly due to its free offering, making it accessible to individual developers and small teams.

    ✅ Pros

    • User-Friendly Interface: SourceTree's GUI is intuitive and straightforward, making Git more accessible to beginners
    • Atlassian Integration: Seamless integration with Jira and Bitbucket enhances collaborative workflows
    • Advanced Branching Model: It simplifies complex branching workflows, making it easier to manage multiple branches
    • Interactive Rebase Tool: Provides an efficient way to clean up commits before pushing them
    • Free to Use: SourceTree is free, a major advantage for individual developers and small teams
    • Visual Representation of Git Commands: Helps users understand the Git process and history more clearly
    • Pull Request Creation and Review: Enables easy creation and review of pull requests within the application
    • Support for Git Large File Storage (LFS): This is essential for teams working with large binary files
    • Extensive Documentation and Community Support: New users can easily find help and resources

    ❌ Cons

    • Performance with Large Repositories: Similar to GitKraken, SourceTree can slow down with very large repositories
    • Limited to Git and Mercurial: It does not support other version control systems
    • No Linux Support: Available only on Windows and MacOS, excluding Linux users
    • Occasional Stability Issues: Users have reported crashes and freezes, especially in older versions
    • Complex for Advanced Operations: While great for basic operations, it can be overwhelming for more complex Git tasks
    • Lacks some Integration Features: Compared to GitKraken, it may not integrate as smoothly with non-Atlassian platforms

    sourcetree
    Figure: Branchs management in SourceTree

    SourceTree stands out as a robust and user-friendly Git client, particularly beneficial for those already within the Atlassian ecosystem. Its intuitive interface and integration with Jira and Bitbucket make it an excellent choice for teams looking for a seamless development workflow. While it shines in user-friendliness and basic Git operations, its performance with large repositories and lack of support for Linux are limitations. SourceTree is a strong contender for teams and developers who prioritize ease of use and are primarily working within the Atlassian suite of tools.

We open source. Powered by GitHub