I'll answer this with an example for changes to a single file. Let's use server.conf just to show that this could be any file at all, not specific to searches. Here's our sample file:
server.conf:
[general]
sessionTimeout=1h
Dev1 clones the repo and wants to change the timeout to 8h. So he creates a branch so that the changes can be tracked separately from master. Edit is made and now our file reads:
[general]
sessionTimeout=8h
Before Dev1 checks his changes in, Dev2 comes along and wants to enable SSL. So, they clone master, make a branch, and now the file might look like this:
[general]
sessionTimeout=1h
[sslConfig]
enableSplunkdSSL = true
useClientSSLCompression = true
...
Dev1 commits their change, and pushes it up to the central repo, so now the new branch is visible to all. At this point, maybe you'd have someone else review the change, or do a quick smoke test on a lab server. Or, if you are already down that path, you'd do a full suite of automated tests. Whatever. Then when you are happy that things are not broken, you merge into master and then on your production server(s), you sync them with master, and restart as needed.
Dev2 comes along and is like, "somebody test my changes, I just enabled SSL". They commit the changes locally, then push them up to the server so that others can see and help test. Tests all looks good. When it's time for Dev2 to merge into master (but prior to syncing production to the new-new changes), this is what happens:
Git (automatically, because this is a core feature of revision control features and git in particular) will do a line-by-line merge of "changeset dev1" and "changeset dev2". This is a pretty straightforward case, and the end result will be exactly as you predict, like this:
[general]
sessionTimeout=8h
[sslConfig]
enableSplunkdSSL = true
useClientSSLCompression = true
If git cannot figure out the changes, you can then take a variety of actions. The onus is on the one merging to figure it out in the end, and they will be shown all the changes that have been made by multiple contributors.
There is a lot to read on this subject, which can make things confusing for folks new to source control systems. To simplify things, you could omit the branch step, and have everyone work in master, but this can make testing and merging more difficult. One of my favorite tips is to automate the "master sync" in production (have cron do a git pull && splunk restart during your maintenance window). This might sound scary at first--until you realize that you REALLY don't push to master until everything has already been thoroughly tested.
So, in order to take advantage of this automated deployment step, at least use two branches. On a small team, you could get away with a "test" and "master" branch. One or more folks work in test, and then the person who gets the short straw merges test into master.
To go back around to your initial question, file changes are compared line-by-line. Git will usually figure things out as if by magic. Many editors will allow you to show diffs visually for those times when you have to merge things manually.
... View more