I have my feature branch which has exceeded around 30 or more commits. Meanwhile in development branch few other features have been pushed from other developers. Therefore, Everytime a new feature is published on development, I am asked to:
Rebase development branch onto my feature branch
Resolve conflicts if any
Continue developing in your feature branch
The problem
The second step is the chicken's neck here. On rebasing it gives me conflicts for every commit of that branch. This is really iterative and redundant. Note, I can't always rebase the development branch immediately since my own work in my branch remains in progress.
What I tried?
To squash and reduce my commits as much as possible (but this helps least, as most of the times there is nothing to squash)
To stash my on going changes, and rebase development and then unstash my changes. (but here, I get conflicts as well)
Using -preserve-merges with rebase. (but everyone here shouts that using this is totally discouraged)
So, what is the optimal approach in dealing with rebasing development onto feature branch with least conflicts when the feature branch itself has numerous commits. I am a fresher, and so a reply with a helpful explanation (or link) will be of much help to proceed.
The workflow is sound (rebase).
But the conflicts should not be resolved every time over and over again.
For that, you have git rerere: activate it (git config --global rerere.enabled true), resolve the conflict one last time (or do a manual re-training, or use contrib/rerere-train.sh), and your next rebase will resuse those conflict resolution at your next rebase.
I would suggest to keep your feature small (one or two days), and your feature branch will be small as well.
Another way would be to rebase not every time something got pushed to development branch but only sometimes, or just once before the merge.
Again you need to keep the feature small or you will have too many conflics all at once.
About your question, you cannot minimize the number of conflics in a rebase. If there are conflics you cannot avoid them.
But there is one way git can help you: I suggest you to enable rerere which stands for reuse recorded resolution. With this, git records how you resolve a conflict and the next time the conflict appears, the resolution is reapplied so that you find the conflict already resolved. This sould speed up your workflow.
You can enable rerere globally with
git config --global rerere.enabled true
Try to git merge from the development branch into the feature branch before you perform the git rebase. It will be more informative in the way.
Related
I now have several branches that have all been merged into the master branch:
I have yet to create a tag and officially release this edition.
So when is the best time to remove your merged branches? I noticed in TortoiseGit that when you merge the branch there is a check box for Delete Branch.
Thanks for your advice.
Depends on your workflow. But generally after merge.
A common workflow is:
merge to develop (if you have a build server, see that the build is ok)
delete local branch and the tracking remote
We have a Rails app with a PostgreSQL database. We use git for version control.
We're only two developers on the project, so we both have to do a little of everything, and when emergencies arise we often have to drop everything to address them.
We have a main branch (called staging just to be difficult 🌚) which we only use directly for quick fixes, minor copy changes, etc. For bigger features, we work on independent feature branches.
When I work on a feature that requires changes to the database, I naturally have to create migrations that alter the schema. Let's say I'm working on feature-emoji, and I create a migration 20150706101741_add_emoji_to_users.rb. I run rake db:migrate to get on with my work.
Later, I'm informed of some bug I need to address. I switch to staging to start work on it; however, now my app will misbehave because the db schema does not match what the app expects. So before doing git checkout staging, I have to remember to do rake db:rollback. And then later when I switch back to feature-emoji, I have to run rake db:migrate again.
This whole flow is sort of okay-ish when dealing with just two branches, but when the git rebases and git merges happen, it gets complicated.
Is there no better way to handle versioning of code and db in parallel? Or am I doomed to have to run annoying rake tasks every time I want to change branches?
There is no easy answer to this. You could perhaps set up something like a git hook to check for changes to schema.rb, and fail the checkout if any are present; but there are lots of edge cases to check for in such a setup.
Ultimately, the responsibility lies with the human developer to restore untracked parts of their environment — e.g. the database — to a clean state before switching branches.
We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.
We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.
The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information :
the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).
This is where I need your collective wisdom :
How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?
What are the best practices around linking versions and bug tracking ?
Answers
It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.
Also to have each clone block the original bug make it a good way to trace the history back to the original submission.
Although I have accepted the answer I still welcome your input.
Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.
As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).
I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).
So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.
If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.
I was looking for a similar feature in TFS, and while doing some investigation, I found that there is an enhancement request to manage "sightings" in Bugzilla:
"Bug 55970 - (bz-branch) Bugzilla needs to deal better with branches (implement sightings)":
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
There is also a proposed design:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
For information, we are going to implement something similar in TFS 2010, with a "Bug Parent" or "Bug Master" to hold the information about the bug itself (repro steps, severity, technical info, impacted components...), that can have child of type "Bug Child" or "Sighting" that will hold the information specific to a given branch (target milestone, priority, specific information for that branch...).
We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.
Who uses versions and how do they use them?
How are versions related to milestones in a project plan?
We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.
After a short while we have many versions. Jira does allow us to control the list in two ways
1. Archive versions (greyed out from pick list)
2. Merge versions (rolls several versions together into a new version - no undo)
We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.
I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?
If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?
i'm going to ask a large question on this topic later on today, but I know the basic answer already:
- Depends on how your team wants to track things.
Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.
I have created a custom field (string) to list to version(s) (as V.M.P.B) where a bug has been fixed.
I have created also another custom field (string) to list to version(s) affected by a bug.
Doing that you are able to perform quick-search on specific version.
I'm working at a company that does several releases to production every year and during the build up to each release we gather up a collection of 1 time sql install scripts like table creation and dataports.
The way things currently work is that after the release to production, we branch, tag then we delete all 1 time scripts from subversion.
This seems to get the job done but to me it never seemed like the proper way to solve the problem.
Could you imagine deleting all your sourcecode every release and then writing patches for production?
The downsides that I see is if you want to reference and old script you have to checkout a tag or branch from subversion.
Our SVN Repo currently looks something like this
svnrepo/mywebsite/src
svnrepo/mywebsite/database/storedprocs
svnrepo/mywebsite/database/installscripts
I was thinking that a more accurate way to model what we want to do in SVN is the following.
Use an svn:externals attribute to point to the latest version. Then after every release just point it to the latest.
svnrepo/mywebsite/trunk/src/
svnrepo/mywebsite/trunk/src/database/installscripts/
-> svnrepo/mywebsite/trunk/database/Release_3
svnrepo/mywebsite/trunk/database/Release_1
svnrepo/mywebsite/trunk/database/Release_2
svnrepo/mywebsite/trunk/database/Release_3
Using this model we no longer svn delete any sql scripts and enable a database developer to check out svnrepo/mywebsite/trunk/database/ and easily view all the database development that has occurred.
Any comments on my ideas, the current structure, or the best way to manage this situation?
Thanks
Synchronising database changes and code changes in subversion is hard
If you have the option of building the Database from scratch you can put the whole DDL into the repository along with the code, then you don’t need to worry about which changes go with which release.
Looking at your situation I don’t think you need to use externals (they can cause headaches). You also don’t need to delete everything. It is not too difficult to check out a branch (or you could just use a repository browser).
You could even put the old db releases into a separate tag when you release so they are all in one place, which the database people can have checked out. If you are doing releases once a year this won’t be hard.
This question may also help
When I first started using revision control systems like CVS and SVN, I didn't really understand the concepts of the "trunk", branching, merging and tagging. I'm now starting to understand these concepts, and really get the importance and power behind them.
So, I'm starting to do it properly. Or so I think... This is what I understand so far: The latest release/stable version of your code should sit in /trunk/ while beta versions or bleeding edge versions sit inside the /branches/ directory as different directories for each beta release, and then merged into the trunk when you release.
Is this too simplistic a view on things? What repository layouts do you guys recommend? If it makes a difference, I'm using Subversion.
See these two questions on SO for more information:
What does branch, tag and trunk really mean?
Subversion question
What I do and normally see as a standard is:
The trunk should contain your main line of development, your unstable version.
You should create release branches for your releases.
Something like:
/trunk (here your are developing version 2.0)
/branches/RB-1.0 (this is the release branch for 1.0)
/branches/RB-1.5
When you find a bug in 1.5, you fix it in the RB branch and then merge to the trunk.
I also recommend this book.
Eric has an excellent series of articles on Source Control use and organisational best practices.
Chapter 7 deals with branches (and yes, it recommends the /trunk/ and /branches/ directories you suggest).
I have used Perforce for a long time, and so my comments may be a little Perforce-centric, but the basic principles apply to any SCM software that has half decent branching.
I'm a very strong believer in using branched development practices. I have a "main" (aka "mainline") that represents the codebase from now to eternity. The aim is that this is, most of the time, stable and, if push came to shove, you could cut a release anytime that would reflect the current functionality of the system. Those pesky sales guys keep asking....
Developments happen in branches that are branched from MAIN (normally - occasionally you may want to branch from an existing dev branch). Integrate from MAIN to your dev branches as often as you can, to stop things diverging too much - or you can simply budget for a bigger integration period later. Only integrate your arse kicking new feature to MAIN when you are sure that it will go out in a forthcoming release.
Finally, you have a RELEASE line, which the option of different branches for different releases. There's some choices depending on the labelling capabilities of your SCM software,and how different major/minor revisions are likely to be. So you may opt, for example, for a release branch for every point release, or only for major rev number. Your mileage may vary.
Generally, branch from MAIN to release as late as possible. Bugfixes and last minute changes can either go straight into RELEASE for later integration to MAIN, or into MAIN for immediate integration back up. There's no hard and fast rule - do what works best. If, however, you have changes that may be submitted to MAIN (e.g. from a dev branch, or "little tweaks" by someone on MAIN), then do the former. It depends on how your team works, what your release cycles are etc.
E.g. I would have something like this:
//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...
A non-trivial project will probably have a number of DEV branches active at once. When a development has been integrated into MAIN so that it is now part of the core project, kill off the old DEV branch as soon as you can. Many engineers will treat a DEV branch as their own personal space, and reuse it for different features over time. Discourage this.
If, after release, you have to fix a bug, then do that in the corresponding release branch. If the bug has been previously fixed in MAIN, then integrate across, unless the code has changed so much in MAIN the fix is different.
What really differentiates the codelines is the policies you use to manage them. For example, what tests get run, who reviews pre/post a change, what action happens if a build breaks. Typically policies - and therefore overhead - are strongest in release branches, and weakest in DEV. There's an article here that goes through some scenarios, and links to other useful things.
Finally, I recommend going with a simple structure to start with, and only introduce extra dev & release ones as needed.
Hope that helps, and is not stating-the-bleedin'-obvious too much.