Tag Info

Hot answers tagged

6

From my experience, feature branches are strictly more general-purpose and flexible. The advantage is that feature branches allow for a developer to work on multiple branches concurrently - and even for multiple developers to be working on the same branch, if needed, without confusion ("Why is Joe writing commits on the Bob branch...?"). Using ...


3

These are coming in where other developers are pulling down changes from remote, into their local repo, before they push their changes back into remote (I think, clarification would be great if not). That's absolutely correct. I just wanted to check that it's expected to see these messages in the remote, It's perfectly normal. If they're very ...


2

I'm going to answer, "don't do this." The workflows are quite different, and you'll not have considered one and end up causing yourself, or worse your team, a lot of grief. Learn VSS, if nothing more than to make you appreciate other VCS more.


1

Do a zip-merge. This is a sequence of merges, that simulate what may have happened if you had merged earlier. The resulting dag will look like a zip. This is based on the assumption that the sum of the complexity of each small merge is lower than the complexity of a large merge. This will be so if there are a lot of conflicts. If I remember correctly ...


1

Rebase and resolve any conflicts. Then run your tests (you do have tests, right?) on the branch. If everything passes, you're good to merge.


1

Some facts: Git is a source control management system, not a deployment tool or configuration management tool There are many stable deployment tools out there: TAR, RPM, Fabric, etc. Ditto for configuration management tools: Puppet, Chef Released history is immutable (the alternative is just crazy) A product is in beta for several commits Conclusions: ...


1

Since git is (in my opinion, and maybe everyone else's) more complicated than SVN, answering this single question will do you more harm than good. Sounds like you didn't spend time on learning the fundamentals. I suggest you (and your entire team) read the great, well written tutorials by Atlassian (go to the 'getting started' section). I read them after ...


1

I agree with the sentiments expressed in other answers in this thread about showing a clear and concise history of features added and bugs fixed. I did however, want to address another aspect which your question eluded to but did not explicitly state. Part of the hangup you may have about some of git's methods of working is that git allows you to rewrite ...


1

You're dealing with multiple teams and multiple projects. Likely decades of work went into the codebase. The short answer is that your teams and projects have varying needs and varying dependencies. The monolithic repository approach reduces commits to "Everything is stable in this configuration!!!" (i.e. unrealistic, huge commits sourced from many teams). ...



Only top voted, non community-wiki answers of a minimum length are eligible