Tag Info

New answers tagged

3

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 ...


0

There are two main reasons to use branches in a VCS: To isolate unreleased features from each other and from released code. This is mainly what git flow is all about. To share unfinished code with other developers without impacting the whole team. This is exactly your use-case, where you can read "other developers" as "myself sitting behind different ...


0

This is perfectly acceptible for me. In fact I've probably done this since I started using version control as I found it the most convenient way.. Other options like dropbox etc work but then you still have to wait for the sync and it does lead to conflicts sometimes which are a mess. I've even known people emailing themselves the temporary work, even ...


0

The thing about pull requests is that it makes known that there are changes that someone wants to bring into the project. If the owner/maintainer wants to cherry pick parts of the pull request, they can do that from that pull request. And just because there is a pull request does not mean that the maintainer is not allowed, or incapable, of doing a rebase. ...


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: ...


0

You can do git checkout your_branch git fetch # get the latest git rebase master Rebase will replay your changes on top of the latest master. You will need to resolve any conflicts. Conflicts occur when the same line(s) in the same file are edited by both the latest master and the feature branch.


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). ...


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.


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 ...


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 ...


28

So that you have a clear and concise git history that clearly and easily documents the changes done and the reasons why. For example a typical 'unsquashed' git log for me might look like the following: 7hgf8978g9... Added new slideshow feature, JIRA # 848394839 85493g2458... Fixed slideshow display issue in ie gh354354gh... wip, done for the week ...


8

Because often the person pulling a PR cares about the net effect of the commits "added feature X", not about the "base templates, bugfix function X, add function Y, fixed typos in comments, adjusted data scaling parameters, hashmap performs better than list"... level of detail If you think that your 16 commits are best represented by 2 commits rather than 1 ...



Top 50 recent answers are included