Hot answers tagged

147

Give them a toy. Git is hard. Especially if you've been doing source control in a different paradigm. I broke the build the first time I tried to work with git. It made me so paranoid that I didn't want to check in until everything was done. I was hiding versions in folders. Then I finally figured out what I needed to get past it: I needed a safe place to ...


74

One approach is feature flagging it. It can live in the code base but be disabled by configuration. Another option it to make a revert commit that reverts the feature merge so that it's not in develop any more. A new branch can be made which reverts the revert, and be left pending to merge later. If you're using Github pull requests, you can do this easily ...


32

The average dev doesn't need a lot of git's goodies. It's a distributed source control system but most teams will use it with a central canonical repo to push and pull from. The core commands that your team will need are: pull and merge changes from remote and handle resulting conflicts (potentially rebasing) commit and push commits to remote (or push to ...


30

He's mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn't merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you're continually merging from develop into the ...


29

I've simply committed unfinished (and messy) states of my code before (and pushed it) only for the purpose of pulling that in the other computer to continue the work. I am pretty sure this a bad practice. It's OK to commit messy unfinished work. Do your work in a topic branch. Commit early, and commit often. Read up on When to commit code? for some ...


28

We stumbled on this exact problem recently. We really like git flow, as it use a good level of semantic (using the same level that you use in team discussion : "I'll start feature A" more than "I'll create a branch, checkout it"), while git is very "implementation" level (which is good and useful also, but different). The problem we have is with git feature ...


28

Have them use a Git UI. If they have experience with TortoiseSVN, TortoiseGit (Windows only) works almost exactly the same. Otherwise, SourceTree (Windows+Mac) is wonderful - we have multiple non-developer QA who have been able to easily master complex tasks in Git thanks to SourceTree.


25

How could we have avoided this issue? From a process perspective, figure out: Who was the decision maker to start this work? Why did the decision to release this feature change? Missed expectations? Miscommunication? Inadequate business support? No customer involvement? More than likely there were drops in communication along the way. This is important ...


25

This answer tries to address how to get senior programmers interested in git, not about how to learn git the quickest way - for that, the excellent git book is great, or any amount of tutorials (=> Google). Good links to go with this answer are Git is a purely functional data structure or especially the short How git stores your data. I'm afraid I have a ...


24

Here is the workflow that I follow when I branch from a feature branch: Create feature-branch-B from feature-branch-A Work on feature-branch-B If more commits are added to feature-branch-A after branching, rebase feature-branch-B onto feature-branch-A Finish work on feature-branch-B and wait till feature-branch-A is merged into master. After feature-branch-...


23

I work in a team which uses git, where 40+ developers are working on multiple code repositories(100+) at any given point of time. We also started out with very few developers, growing the team size in a span of few years. In the beginning though with few people you can get away with knowing only a bare minimum of git. Over time you will improve your git fu, ...


23

You should certainly consider splitting the product into modules with interface team(s) bringing those constituent modules together into a product. This in turn would mean splitting the repositories to match the module partitioning and hierarchy. If it appears that you can't do this then the project will probably grind to a merge-induced halt considering ...


22

In my limited git experience I can say that sometimes it's faster to restart the feature branch over again if the master has gone too far from the detach point. Merging two branches without knowing the history behind the code (given that you've just joined the project) is really difficult, and I bet that even a developer who followed the project from the ...


21

Merging is a funny thing - the less frequently it's done the harder it will be, the harder it is, the more people will be afraid of it, the less frequently they will do it. Solution is either do not allow branches to deviate too much, or not to use branches. If people understand this, you will probably have not much problems with merge, if not - may be ...


19

Forget for a moment the issue with your management, and imagine you had the "automatic signup feature" already in your latest production release, deeply integrated into your codebase. Now you get the new requirement to add an "off-switch" for "automatic signup". How would you handle this in your Git workflow? I guess you would declare "disabling of ...


19

Refactoring work should go in a feature branch. The prefix "feature" is just a word to describe a discrete programming task, you could choose any word you like, any branch from development is either a "feature" branch or a "release" branch Adding a new prefix such as "refactoring" is problematic. As you will often do some refactoring when adding a feature, ...


18

If you absolutely want to keep this naming scheme, you might: Decide that you don't care about these warnings That is, if you're happy with the fact that: git checkout <ref> will check out refs/heads/<ref> over refs/tags/<ref> (see git-checkout) other commands will use refs/tags/<ref> over refs/heads/<ref> (see gitrevisions) ...


18

No. You should not merge your own pull requests. What's good for the goose is good for the gander. Merging your own pull requests sets a bad precedent for our junior dev. It also means that no one else is looking at your code. No matter how senior we may be, we all makes mistakes and write bad code from time to time. Teach your junior how code reviews work ...


16

The process the team I work with uses for this is as follows: Create a feature branch: git flow feature start module_1 The code is updated on the feature branch As changes are committed they are pushed to GitHub (or once at the end if preferred) When the feature is completed a pull request is opened in GitHub comparing develop and the feature branch ...


16

git-imerge is designed exactly for this purpose. It is a git tool which provides a method for incremental merging. By merging incrementally, you only need to deal with the collisions between two versions, never more. Furthermore, a far larger number of merges can be performed automatically as the individual changesets are smaller.


14

I would like to refer you to this blog entry by Joel Spolsky. The reason you're seeing for these junior developers picking it up quickly is very likely because they do not have a predetermined notion regarding how version control in general works, or at least not an as deeply ingrained mental model of it. As such they come in with a clean slate. Your more ...


13

QA should probably be testing twice. The first testing should be around the specific changes and done on the feature branch. This lets QA test around the specific changes and see that the particular change is complete as specified and behaves as expected. It also gives them an early preview for the second round of testing, which is what actually matters for ...


11

I don't see anything wrong with rebasing your feature branch onto develop to pick up the latest hot fixes. Actually, frequently rebasing your feature branch against develop can be helpful, since it lets you keep your branch "up to date," which makes merging much easier when you get to that stage.


11

There is no consensus, and that is the spirit of git. Git very intentionally does not impose any sort of structure. In that way, it is really more of a version control framework than a complete system. People use git as a base to build whichever kind of structure works best for them. For some teams that's a format-patch workflow, for some it's github ...


11

The issue might also lie in a too rigid separation of task between back-end and front-end development. If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a ...


11

Firstly, you can't tag branches, you can only tag commits. You should tag the commit you actually release. That's the point of version-tagging commits. If you have an issue with your software in some environment (production or otherwise) you can say with confidence that the issue was introduced by the commit that that release was derived from. (This is ...


11

The way I've always seen it done is to have a single code base capable of serving both pages/views/forms. ie. Its Feature flagged and deployed with two or more configs, or the 'does the user get A or B' method itself is part of the app. In this case you only have the one version of the code, so your source control doesn't come into play. This is far more ...


10

I found stackoverflow very helpful while I was first picking up Git terminology. Questions like these ones were really useful for me (mostly because of their conciseness) and I kept them open in tabs during the first couple of weeks I used it. Maybe print out a couple of the answers in bold? Especially the diagram on the first one. What are the differences ...


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