4 Add bullet point
source | link

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve your code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.
  • You are certain to be working on the latest codebase and detect possible conflicting code changes early on.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve your code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve your code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.
  • You are certain to be working on the latest codebase and detect possible conflicting code changes early on.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"
3 Mistake
source | link

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve myyour code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve my code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve your code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"
2 Minor spelling mistakes
source | link

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • IYou can check-in daily to preserve my code on the server
  • IYou don't have to worry about breaking the build by checkinchecking-in.
  • IYou can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • mergeMerging from main has to be done manually (or scripted)
  • itIt takes a more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature
  • Merge often from the mainline to this new branch

This way,

  • I can check-in daily to preserve my code on the server
  • I don't have to worry about breaking the build by checkin-in.
  • I can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • merge from main has to be done manually (or scripted)
  • it takes a more "administration"

Personally, I update my local versions daily.

In the scenario you describe, I would go the extra mile by

  • Creating a branch for the new, lengthy feature.
  • Merge often from the mainline to this new branch.

This way,

  • You can check-in daily to preserve my code on the server
  • You don't have to worry about breaking the build by checking-in.
  • You can use the repository to undo some work or diff when necessary with earlier check-ins.

The drawbacks as I see them are

  • Merging from main has to be done manually (or scripted)
  • It takes more "administration"
1
source | link